[RADIATOR] Question about regex matching realm in handlers
rosed at iit.edu
Thu Feb 11 12:42:03 CST 2016
Now that you assembled the pieces for me, it makes perfect sense. I
figured I had to be missing something.
On 2/11/2016 5:17 AM, Heikki Vatiainen wrote:
> 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, "tuser at 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>/
>> EAP-Message = <2><0><0><18><1>tuser at iit.edu
>> Message-Authenticator =
>> 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 username at 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
> <Handler TunnelledByPEAP=1, Realm=/^iit\.edu$/i>
> Identifier PEAP_INNER_IITdEDU
> AuthBy NTLM_MSCHAP_NoRealm
> <Handler TunnelledByPEAP=1>
> Identifier PEAP_INNER_No_Realm
> <AuthBy FILE>
> Filename /dev/null
> EAPType EAP-MSCHAP-V2
> 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.
More information about the radiator