(RADIATOR) tunnel-password questions

Mike McCauley mikem at open.com.au
Sun Oct 2 19:02:23 CDT 2005 

Hello Laurent,


On Thursday 29 September 2005 20:16, PREVOSTO, Laurent wrote:
> Hi,
>
> I am not sure everything works perfectly, i have made a few tests with
> radiator 3.13 + patches
>
> The conf is the following :
>
> <Client DEFAULT>
> 	Secret secret
> </Client>
>
> <AuthBy INTERNAL>
> 	Identifier Always-Accept
> 	AuthResult ACCEPT
> </AuthBy>
>
> <Handler Realm="test">
> 	AuthBy Always-Accept
> 	AddToReply Tunnel-Password="1:password"
> </Handler>
>
> I plan to test what is the value of the returned Tunnel-Password if I put
> string or tagged-string for the Tunnel-Password attribute in the dictionary
> file and if is add or not ClearTextTunnelPassword in the Client clause.
>
> I do a radpwtest -trace 4 -s localhost -noacct -dictionary
> dictionary.with.no.tag -user lp at test -password test
>
> (I use a dictionary with no tag for radpwtst so I can see the very value of
> the attribute).
>

The key to understanding the opertion is that Radiator keeps Tunnel-Password 
in plaintext format internally and encrypts/decrypts it at the 'edges' when 
receiving replies  from a remote server and sending replies back to the 
client.

Therefore, Tunnel-Password in a user file or user database _must_ be in 
plaintext format. Indeed, it does not make sense to have Tunnel-Password in a 
user file alrteady encrypted, since the encryption depends on the RADIUS 
shared secret.


> There are 4 cases :
>
> 1. Tunnel-Password is string and tunnel password is NOT clear text
> 	Tunnel-Password =
> "<1><224><21><153><141><226>0<134>it<197>b<0<232><13><202><227><237>" I
> assume this is ok : there is a <1> byte tag and it is encrypted

OK.

>
> 2. Tunnel-Password is string and I put ClearTextTunnelPassword in the
> Client clause : Tunnel-Password = "1:password"
> I assume this is wrong : I was expecting something like <1>password

Expected.
If ClearTextTunnelPassword  is set then there is no encryption/tagging/special 
processing: the Tunnel-Password in the user database wil lbe sent literally 
and unchanged to the client.

>
> 3. Tunnel-Password is tagged-string and tunnel password is NOT clear text
> 	Tunnel-Password =
> "<0><1><161><139><0>Y<230><173><12><1>b_J><232><127>s<191><223>g" I assume
> this is wrong : the password is encrypted but I have the wrong tag

No, it will get encrypted again when sent to the client. Thats why you are 
seeing the wrong tag.

>
> 4. Tunnel-Password is tagged-string and I put ClearTextTunnelPassword in
> the Client : Tunnel-Password = "<1>password"
> I assume this is ok : there is the <1> byte tag and the password is clear
> text.

Expected.
As per 2 above.

>
> Am I missing something ?
> I could have been fooled by radpwtst output but this is quite unclear to
> me.
Yes, CAUTION: radpwtst always shows the wire version of Tunnel-Password, it 
does not show decrypted Tunnel-Passwords

>
> Could anybody explain to me what really happens, we have clients with all
> kinds of setups and I am sorta confused...
Hope that helps.

Cheers.

>
> Regards
>
> Laurent
>
> > -----Message d'origine-----
> > De : Mike McCauley [mailto:mikem at open.com.au]
> > Envoyé : samedi 24 septembre 2005 01:15
> > À : PREVOSTO, Laurent
> > Cc : radiator at open.com.au
> > Objet : Re: (RADIATOR) tunnel-password questions
> >
> > Hello Laurent,
> >
> > The answer to your questions depends on what version of Radiator you
> > have. We
> > made recent changes to rationalise the behaviour of encrypyted attributes
> > like Tunnel-Password when proxying.
> >
> > Now, when a proxy reply contains Tunnel-Password, the Tunnel-Password is
> > decrypted by AuthRADIUS using the shared secret for the hop to the proxy
> > (unless ClearTextTunnelPassword is set in the AuthRADIUS Host). It is
> > then kept in plaintext form until shortly before being replied to the
> > original client, when it is encrypted with the original clients shared
> > password (unless ClearTextTunnelPassword is set in the Client clause).
> >
> > That means that now you can do stuff to Tunnel-Password in AddToReply
> > etc. and
> > it should work.
> >
> > You can use ClearTextTunnelPassword in AuthBy RADIUS or in Client
> >
> > When encrypting Tunnel-Password and similar, you can use either tagged or
> > non-tagged strings. If there is no tag at the beginning of the password,
> > Radiator assumes the tag is 0:
> >
> > This is all quite different to earlier behaviour. It is available now in
> > the
> > latest Radiator patch set.
> >
> > Hope that helps.
> >
> > Cheers.
> >
> > On Thursday 22 September 2005 20:00, PREVOSTO, Laurent wrote:
> > > Hi,
> > > Bonjour,
> > >
> > >
> > > I have the following situation :
> > >
> > > Old crappy NAS <----> radiator proxy <----> old crappy SMC
> > >
> > > I have problems concerning the tunnel password reply-item so I'd like
> > > to verify a few things concerning the way radiator handles it :
> > >
> > > 1. if SMC sends back encrypted tunnel-password and I don't use
> > > PlainTextTunnelPassword, I have the following
> > > *** Received from SMC port 1812 ....
> > > Code:       Access-Accept
> > > Identifier: 2
> > > Authentic:  oc<202>Xx4<176><187><21><252>9<250><189><149><150><132>
> > > Attributes:
> > >         Proxy-State = OSC-Extended-Id=2
> > >         Class = "<128><141><128><128>"
> > >         Service-Type = Framed-User
> > >         Tunnel-Type = 1:L2TP
> > >         Tunnel-Medium-Type = 1:IP
> > >         Tunnel-Client-Endpoint = 1:xxxx
> > >         Tunnel-Server-Endpoint = 1:yyyy
> > >         Tunnel-Password =
> > > "<1><255><212><1>A<174><133><8><29>"28&<202>>[<200><3><165>"
> > >
> > > Tue Sep 20 18:18:03 2005: DEBUG: Received reply in AuthRADIUS for req 2
> > > from 192.168.162
> > > .120:1812
> > > Tue Sep 20 18:18:03 2005: DEBUG: Access accepted for zzzz at demo.fr
> > > Tue Sep 20 18:18:03 2005: DEBUG: Packet dump:
> > > *** Sending to NAS port 32839 ....
> > > Code:       Access-Accept
> > > Identifier: 228
> > > Authentic:  1234567890123456
> > > Attributes:
> > >         Class = "<128><141><128><128>"
> > >         Service-Type = Framed-User
> > >         Tunnel-Type = 1:L2TP
> > >         Tunnel-Medium-Type = 1:IP
> > >         Tunnel-Client-Endpoint = 1:xxxx
> > >         Tunnel-Server-Endpoint = 1:yyyy
> > >         Tunnel-Password = "<1><201><183><139>a<251><134>b
> > > <131>B<192><7><9>X<187><248>fa
> > > "
> > >
> > > So it looks like radiator decrypts then reencrypts Tunnel-Password.
> > > Moreover, I have to use the "string" type in the dictionary (as
> > > documented) and NOT tagged-string since it seems to mess things up.
> > > Am I right ?
> > >
> > > 2. if SMC sends back encrypted tunnel-password and I do use
> > > PlainTextTunnelPassword, I have the following
> > >
> > > *** Received from SMC port 1812 ....
> > > Code:       Access-Accept
> > > Identifier: 1
> > > Authentic:
> > > <244>_<149><215><251>;<175>O<250><194><165><30><173><31><240>#
> > > Attributes:
> > >         Proxy-State = OSC-Extended-Id=1
> > >         Class = "<128><141><128><128>"
> > >         Service-Type = Framed-User
> > >         Tunnel-Type = 1:L2TP
> > >         Tunnel-Medium-Type = 1:IP
> > >         Tunnel-Client-Endpoint = 1:xxxx
> > >         Tunnel-Server-Endpoint = 1:yyyy
> > >         Tunnel-Password =
> > > "<1><175>.<213>8<165><7><26><223><163><16><164>L<231><188>[<25
> > > 0>fM"
> > >
> > > Tue Sep 20 18:19:12 2005: DEBUG: Received reply in AuthRADIUS for req 1
> > > from 192.168.162
> > > .120:1812
> > > Tue Sep 20 18:19:12 2005: DEBUG: Access accepted for zzzz at demo.fr
> > > Tue Sep 20 18:19:12 2005: DEBUG: Packet dump:
> > > *** Sending to NAS port 32839 ....
> > > Code:       Access-Accept
> > > Identifier: 42
> > > Authentic:  1234567890123456
> > > Attributes:
> > >         Class = "<128><141><128><128>"
> > >         Service-Type = Framed-User
> > >         Tunnel-Type = 1:L2TP
> > >         Tunnel-Medium-Type = 1:IP
> > >         Tunnel-Client-Endpoint = 1:xxxx
> > >         Tunnel-Server-Endpoint = 1:yyyy
> > >         Tunnel-Password =
> > > "<1><175>.<213>8<165><7><26><223><163><16><164>L<231><188>[<25
> > > 0>fM"
> > >
> > > So it looks like if radiator receives an encrypted Tunnel-Password, he
> > > will send it encrypted (but unchanged) even if ClearTextTunnelPassword
> > > is set.
> > > Once again, am I right ?
> > > In that very case, is there a way radiator sends back the
> > > Tunnel-Password as clear text ?
> > >
> > >
> > > 3. mixing ClearTextTunnelPassword and Handler
> > > I can add ClearTextTunnelPassword in an <AuthBy Radius> clause and it
> > > works fine (if the Tunnel-Password is not received encrypted, as in 2.)
> > > But it looks like I can't put it in an <Handler> clause, so I can't do
> > > something like :
> > >
> > > <Handler Realm=/foo/>
> > > 	AuthBy Something
> > > 	ClearTextTunnelPassword
> > > 	AddToReply Tunnel-Password = 1:somepasswd
> > > </Handler>
> > >
> > > Plus writing :
> > > <AuthBy whatever>
> > > 	Identifier Something
> > > 	ClearTextTunnelPassword
> > > 	...
> > > </AuthBy>
> > > <Handler Realm=/foo/>
> > > 	AuthBy Something
> > > 	AddToReply Tunnel-Password = 1:somepasswd
> > > </Handler>
> > > Won't work either.
> > >
> > > This is quite frustrating... is there a way to do such a thing ?
> > >
> > >
> > > Regards,
> > >
> > > Laurent
> > >
> > >
> > >
> > > --
> > > Archive at http://www.open.com.au/archives/radiator/
> > > Announcements on radiator-announce at open.com.au
> > > To unsubscribe, email 'majordomo at open.com.au' with
> > > 'unsubscribe radiator' in the body of the message.
> >
> > --
> > Mike McCauley                               mikem at open.com.au
> > Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> > 9 Bulbul Place Currumbin Waters QLD 4223 Australia
> > http://www.open.com.au
> > Phone +61 7 5598-7474                       Fax   +61 7 5598-7070
> >
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> > TTLS, PEAP etc on Unix, Windows, MacOS etc.

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.

More information about the radiator mailing list