On 10.2.2016 23.31, David Rose wrote:
> However, if I comment out the two "[TTLS|PEAP]_INNER_GENERIC" handlers
> and associated statements (i.e. no other changes to client config or
> anywhere else) and restart Radiator, "tu...@iit.edu" no longer matches
> the regex and the inner request is then caught by "NO_REALM". Here is
> the debug from a request where things stop working as expected (I think
> the key is that in the packet dump, the username is in the "EAP-Message"
> field and not the "User-Name" field):
Yes, you are correct. The key is the empty User-Name in the tunnelled
request. Here's the tunnelled request:
> Tue Feb 9 23:21:42 2016: DEBUG: TTLS Tunnelled Diameter Packet dump:
> Code: Access-Request
> Identifier: UNDEF
> Authentic: <143><164>i<235>]<132>Uf<206>Y<200><210><211><241><191>/
> Attributes:
> EAP-Message = <2><0><0><18><1>tu...@iit.edu
> Message-Authenticator =
> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> User-Name = ""
>
> Tue Feb 9 23:21:42 2016: DEBUG: Handling request with Handler
> 'Realm=/^$/', Identifier 'NO_REALM'
This is what happens: Your outer Handler's AuthBy has 'EAPAnonymous %0'.
This tells Radiator to add User-Name in the inner request with the value
that is the inner EAP identity.
When the inner EAP starts, the first request is the EAP Identity
response shown above. The identity (the username) is then extracted by
the AuthBy within the Handler that matches the inner request.
Because the innner request becomes known only after the first tunnelled
request has been processed, it's not available when the first tunnelled
request is dispatched to the Handlers. In other words, we have a chicken
and egg situation: the inner identity is needed before the request that
carries it is processed.
You could consider this:
<Handler TunnelledByPEAP=1, Realm=/(^iit\.edu$|^$)/i>
This should match usern...@iit.edu, username@, username and empty
username. Or then you could use simply just <Handler TunnelledByPEAP=1>
Since the outer username is used to route the RADIUS request to the
correct home organisation, for example with eduroam, what matters is
that the RADIUS request has the correct realm. The inner request's realm
can have the home realm but it could as well be empty since the inner
username is not used for RADIUS request routing.
If you want to force the inner realm to always be @iit.edu, you could do
this:
<Handler TunnelledByPEAP=1, Realm=/^iit\.edu$/i>
Identifier PEAP_INNER_IITdEDU
AuthBy NTLM_MSCHAP_NoRealm
</Handler>
<Handler TunnelledByPEAP=1>
Identifier PEAP_INNER_No_Realm
<AuthBy FILE>
Filename /dev/null
EAPType EAP-MSCHAP-V2
</AuthBy>
</Handler>
Even if the first request with the empty User-Name always matches the
second Handler, it will just extract the identity and challenge the
client to start EAP-MSCHAP-V2. The next request from the client will
match the correct Handler unless their identity (username) does not end
with @iit.edu. If this happens, they will fail the authentication.
However, it might be a good idea to allow the inner username to be
realmless and use Realm=/(^iit\.edu$|^$)/i with the first Handler.
You could think the second Handler as an anchor that bootstraps
EAP-MSCHAP-V2 and handles unknown realms.
We have planned solving the chicken egg problem by taking a look at the
inner request when the inner identity is not known yet. If the inner
EAP-Message contains the identity, then it could be used for the first
message when EAPAnonymous %0 is configured. However, this is not in
Radiator or Radiator patches yet.
I hope the above clarifies how EAPAnonymous %0 works currently and why
you will see empty User-Name with it.
Thanks,
Heikki
--
Heikki Vatiainen <h...@open.com.au>
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, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
