(RADIATOR) tunnel-password questions
PREVOSTO, Laurent
Laurent.PREVOSTO at neufcegetel.fr
Mon Oct 3 12:46:22 CDT 2005
> De : Mike McCauley [mailto:mikem at open.com.au]
> Envoyé : lundi 3 octobre 2005 02:02
> À : PREVOSTO, Laurent
> Cc : radiator at open.com.au
> Objet : Re: (RADIATOR) tunnel-password questions
>
> 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.
I don't get it : in my config file i have AddToReply Tunnel-Password=1:password : the value is not in encrypted form. So there is no way it should be encrypted "again".
When I say "tunnel password is not clear text", I mean : i did not put ClearTextTunnelPassword in the config file...
> > 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.
Not exactly : in 2. you say if ClearTextTunnelPassword is set, there is no processing concerning tag. But the "1:" is parsed since I get <1>password as a result and not <0>1:password
> > 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
That's what i expect :-)
Or my tests would mean nothing...
Regards
Laurent
>
> >
> > 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