TTLS use_tunneled_reply and Mac OSX
Hi, I have noticed that when authenticating using TTLS/MSCHAPv2 that the outer-identity is used in the RADIUS reply packet even if the use_tunneled_reply is set to yes for TTLS in eap.conf Does anyone know the reason for this? Thanks Scott Armitage
Scott Armitage <S.P.Armitage@lboro.ac.uk> wrote:
I have noticed that when authenticating using TTLS/MSCHAPv2 that the outer-identity is used in the RADIUS reply packet even if the use_tunneled_reply is set to yes for TTLS in eap.conf
Does anyone know the reason for this?
TLS session resumption? Also TTLS/MSCHAPv2 is possibly for you actually TTLS/EAP-MSCHAPv2 which means you get in effect an inner-inner tunnel if I remember correctly. Have a nosey at: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg71026.h... Cheers -- Alexander Clouter .sigmonster says: Rubber bands have snappy endings!
On 20 Jul 2011, at 12:49, Alexander Clouter wrote:
Scott Armitage <S.P.Armitage@lboro.ac.uk> wrote:
I have noticed that when authenticating using TTLS/MSCHAPv2 that the outer-identity is used in the RADIUS reply packet even if the use_tunneled_reply is set to yes for TTLS in eap.conf
Does anyone know the reason for this?
TLS session resumption?
I am, but have tested with it off and get the same result.
Also TTLS/MSCHAPv2 is possibly for you actually TTLS/EAP-MSCHAPv2 which means you get in effect an inner-inner tunnel if I remember correctly.
Have a nosey at:
http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg71026.h...
Thanks, for the link. I could force the user-name in the reply, as suggested, with some rewriting of attributes. I was mostly just wondering why TTLS behaved in this way. Scott
On 20/07/11 11:26, Scott Armitage wrote:
Hi,
I have noticed that when authenticating using TTLS/MSCHAPv2 that the outer-identity is used in the RADIUS reply packet even if the use_tunneled_reply is set to yes for TTLS in eap.conf
That's not what we see: [ttls] Using saved attributes from the original Access-Accept User-Name = "xxx" ... Sending Access-Accept of id 8 to 192.168.51.229 port 57353 User-Name = "xxx" Can you show a debug?
Does anyone know the reason for this?
Are you using TLS session resumption?
On 20 Jul 2011, at 13:39, Phil Mayers wrote:
On 20/07/11 11:26, Scott Armitage wrote:
Hi,
I have noticed that when authenticating using TTLS/MSCHAPv2 that the outer-identity is used in the RADIUS reply packet even if the use_tunneled_reply is set to yes for TTLS in eap.conf
That's not what we see:
[ttls] Using saved attributes from the original Access-Accept User-Name = "xxx" ... Sending Access-Accept of id 8 to 192.168.51.229 port 57353 User-Name = "xxx"
Can you show a debug?
I've attached a full debug. I notice that if I do a PEAP authentication i see the following: [peap] Using saved attributes from the original Access-Accept Reply-Message = "Authenticated by Test ORPS" User-Name = "scott-test" compared with TTLS which has: [ttls] Using saved attributes from the original Access-Accept Reply-Message = "Authenticated by Test ORPS"
Does anyone know the reason for this?
Are you using TLS session resumption?
Yes, however I disabled TLS session resumption and tested again and got the same results. Thanks Scott
On 20/07/11 14:27, Scott Armitage wrote:
[ttls] Using saved attributes from the original Access-Accept Reply-Message = "Authenticated by Test ORPS"
Ok, looking at the debug the reason this is happening is that you are doing TTLS/MSCHAP, as opposed to TTLS/EAP-MSCHAP. [ttls] Got tunneled request User-Name = "scott-test@example.ac.uk" MS-CHAP-Challenge = 0xcab2e5bc6ccc5e4b382dfbabf81cdd6c MS-CHAP2-Response = 0x3f00546f8b7903000016283b4f647a91a9c20000000000000000db0d79340d9306bdb4cb590b8e4317c8d4afab58bd715d14 FreeRADIUS-Proxied-To = 127.0.0.1 The "eap" module is what copies the User-Name to the reply in Access-Accept, and since you're not running an EAP inner, this doesn't happen. I must admit, I didn't know you could even *do* TTLS w/ plain MSCHAP inner, because I had assumed it was subject to replay attacks (in MSCHAP, the NAS generates the MSCHAP challenge, but of course in TTLS, the client must do it). However, a glance at the source code suggests TTLS has support for "implicit" challenge generation based on the TTLS session, eliminating the replay attack. You'll need to set the User-Name in Access-Accept yourself for non-EAP inner methods (including TTLS/PAP). Alex has given one suggestion, but personally I like this in "inner-tunnel": post-auth { if (!reply:User-Name) { update reply { User-Name := "%{User-Name}" } } } ...and then this in the outer-server: post-auth { # ensure reply username contains user@domain for # routing of accounting traffic if (reply:User-Name !~ /.*@.+/) { update reply { User-Name := "%{reply:User-Name}@%{Stripped-User-Domain}" } } }
On 20 Jul 2011, at 15:40, Phil Mayers wrote:
On 20/07/11 14:27, Scott Armitage wrote:
[ttls] Using saved attributes from the original Access-Accept Reply-Message = "Authenticated by Test ORPS"
Ok, looking at the debug the reason this is happening is that you are doing TTLS/MSCHAP, as opposed to TTLS/EAP-MSCHAP.
Thanks Scott
participants (3)
-
Alexander Clouter -
Phil Mayers -
Scott Armitage