Re: [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, "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:
   

This should match usern...@iit.edu, username@, username and empty 
username. Or then you could use simply just 

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:


 Identifier PEAP_INNER_IITdEDU
 AuthBy NTLM_MSCHAP_NoRealm


 Identifier PEAP_INNER_No_Realm
 
 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.

Thanks,
Heikki

-- 
Heikki Vatiainen 

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

Re: [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, "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:
>
>
> This should match usern...@iit.edu, username@, username and empty 
> username. Or then you could use simply just 
>
> 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:
>
> 
>  Identifier PEAP_INNER_IITdEDU
>  AuthBy NTLM_MSCHAP_NoRealm
> 
> 
>  Identifier PEAP_INNER_No_Realm
>  
>  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.
>
> Thanks,
> Heikki
>

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator