[RADIATOR] Question about regex matching realm in handlers

[David Rose]

Heikki,

Now that you assembled the pieces for me, it makes perfect sense. I
figured I had to be missing something.

Thank you!

David

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>/
>> Attributes:
>>          EAP-Message = <2><0><0><18><1>tuser at 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 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 
> 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
>