(RADIATOR) tunnel-password questions
Mike McCauley
mikem at open.com.au
Fri Sep 23 18:14:50 CDT 2005
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.
More information about the radiator
mailing list