(RADIATOR) tunnel-password questions

Thu Sep 29 05:16:21 CDT 2005

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).

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

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

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

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.

Am I missing something ?
I could have been fooled by radpwtst output but this is quite unclear to me.

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

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.

--
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.