TTLS use_tunneled_reply and Mac OSX

[Phil Mayers]

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 at 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 at domain for
   # routing of accounting traffic
   if (reply:User-Name !~ /.*@.+/) {
     update reply {
       User-Name := "%{reply:User-Name}@%{Stripped-User-Domain}"
     }
   }
}