[RADIATOR] Question about regex matching realm in handlers

[Heikki Vatiainen]

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

-- 
Heikki Vatiainen <hvn at 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.