(RADIATOR) tunnel-password questions
Mike McCauley
mikem at open.com.au
Mon Oct 3 17:01:08 CDT 2005
Hello Laurent,
On Tuesday 04 October 2005 03:46, PREVOSTO, Laurent wrote:
> > 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...
Sorry, I made the wrong explanation.
Curious.
Tests here show that if you have
AddToReply Tunnel-Password=1:password
in the AuthBy and
ClearTextTunnelPassword
in the Client, you get:
*** Received from 127.0.0.1 port 1645 ....
Code: Access-Accept
Identifier: 90
Authentic: <251><212><158>R<149><172>e<142>x<240><163><133><226>><152><155>
Attributes:
Tunnel-Password = "1:password"
and if you have:
AddToReply Tunnel-Password=\001password
you get
*** Received from 127.0.0.1 port 1645 ....
Code: Access-Accept
Identifier: 226
Authentic: 7<162><130><132>n<215>><173><147>>z<185>l<6>u<224>
Attributes:
Tunnel-Password = "<1>password"
showing that when ClearTextTunnelPassword is set, the Tunnel-Password contains
the literal string. Caution, AddToReply will not recognise <n> as an escape
code for character n.
>
> > > 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.
--
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