(RADIATOR) tunnel-password questions
Patrik Forsberg
patrik.forsberg at dataphone.net
Mon Oct 3 22:33:37 CDT 2005
This might me totally out of subject but I thought I'd give a comment atleast ;)
We used to have old crappy (now)Lucent Portmaster3 NASes and did L2TP with it.. in that configuration we needed both ClearTextPassword(I belive this is where this option got implemented aculy) and the password were to be sent without the 0:/1: and so on tag. PM3 just doesn't accept a tagged response.
As you say yourself that you're dealing with old crappy NASes this might be a hint. I could be totally wrong, ofcourse ;)
Regards,
Patrik
> -----Original Message-----
> From: owner-radiator at open.com.au
> [mailto:owner-radiator at open.com.au] On Behalf Of Mike McCauley
> Sent: den 4 oktober 2005 00:01
> To: PREVOSTO, Laurent
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) tunnel-password questions
>
> 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.
>
--
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