(RADIATOR) tunnel-password questions
PREVOSTO, Laurent
Laurent.PREVOSTO at neufcegetel.fr
Tue Oct 4 05:04:44 CDT 2005
Actually, we're dealing with all kind of NASes : some accept tagged attribute, some not, some accept encrypted tunnel password, some not :-(
And I'm trying to figure out what the best setup is :
- should I put Tunnel-Password as string or tagged-string in the dictionary ? (I use 3.13 + patches)
- if I need to manually add a tagged Tunnel-Password, should I AddToReply \001password or 1:password (which I prefer)
Regards
Laurent
> -----Message d'origine-----
> De : Patrik Forsberg [mailto:patrik.forsberg at dataphone.net]
> Envoyé : mardi 4 octobre 2005 05:34
> À : Mike McCauley; PREVOSTO, Laurent
> Cc : radiator at open.com.au
> Objet : RE: (RADIATOR) tunnel-password questions
>
> 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