Re: [RADIATOR] Question about regex matching realm in handlers
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
Re: [RADIATOR] Question about regex matching realm in handlers
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
[RADIATOR] Question about regex matching realm in handlers
Not sure if this is normal behavior or not as I am a bit new to Radiator, however it seems odd to me. Maybe someone can explain it or point out what I might be doing wrong? Configuring a Radiator server (tried with both 4.15 & 4.16) to provide authentication for wireless, and most things have gone well. However I have come across something that doesn't seem quite right. If I only have handlers for the inner authentication that have a regex to match realms, Radiator doesn't seem to parse the request packet properly. If I include "generic" inner authentication handlers (which don't get used), then the handlers with the regex work just fine. Here is my working configuration: Foreground LogStdout DbDir /etc/radiator LogDir . DictionaryFile %D/dictionary Trace 4 AuthPort 1812 AcctPort 1813 include %D/clients.cfg DisabledRuntimeChecks CVE-2014-0160 Identifier NTLM_MSCHAP_NoRealm UsernameMatchesWithoutRealm EAPType MSCHAP-V2 Identifier FILE_OuterRequests Filename %D/dot1x_anon EAPType TTLS PEAP EAPAnonymous %0 EAPTLS_CAFile %D/certificates/cacert.pem EAPTLS_CertificateFile %D/certificates/cert-srv.pem EAPTLS_CertificateType PEM EAPTLS_PrivateKeyFile %D/certificates/cert-srv.pem EAPTLS_PrivateKeyPassword whatever EAPTLS_PEAPVersion 0 EAPTTLS_NoAckRequired AutoMPPEKeys EAPTLS_Ciphers DEFAULT:!EXPORT:!LOW:!RC4 Identifier TTLS_INNER_IITdEDU AuthBy NTLM_MSCHAP_NoRealm Identifier PEAP_INNER_IITdEDU AuthBy NTLM_MSCHAP_NoRealm Identifier TTLS_INNER_GENERIC AuthBy NTLM_MSCHAP_NoRealm Identifier PEAP_INNER_GENERIC AuthBy NTLM_MSCHAP_NoRealm Identifier NO_REALM AccountingHandled StripFromReply Reply-Message AddToReply Reply-Message="Misconfigured client: empty realm!" Identifier EAP_OUTER_IITdEDU AuthBy FILE_OuterRequests This works as expected for "tu...@iit.edu" with the outer authentication being handled by the "EAP_OUTER_IITdEDU" and the inner authentication using "[TTLS|PEAP]_INNER_IITdEDU" correctly depending on client configuration. 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): Tue Feb 9 23:21:42 2016: DEBUG: Handling request with Handler 'Realm=/iit\.edu$/i', Identifier 'EAP_OUTER_IITdEDU' Tue Feb 9 23:21:42 2016: DEBUG: Deleting session for anonym...@iit.edu, 192.168.50.70, 14337 Tue Feb 9 23:21:42 2016: DEBUG: Handling with Radius::AuthFILE: FILE_OuterRequests Tue Feb 9 23:21:42 2016: DEBUG: Handling with EAP: code 2, 5, 63, 21 Tue Feb 9 23:21:42 2016: DEBUG: Response type 21 Tue Feb 9 23:21:42 2016: DEBUG: EAP TTLS data, 3, 5, 4 Tue Feb 9 23:21:42 2016: DEBUG: EAP TTLS inner authentication request for 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' Tue Feb 9 23:21:42 2016: DEBUG: Deleting session for , 192.168.50.70, Tue Feb 9 23:21:42 2016: INFO: Access rejected for : No AuthBy found Tue Feb 9 23:21:42 2016: DEBUG: Returned TTLS tunnelled Diameter Packet dump: Code: Access-Reject Identifier: UNDEF Authentic: <143><164>i<235>]<132>Uf<206>Y<200><210><211><241><191>/ Attributes: Reply-Message = "Misconfigured client: empty realm!" Tue Feb 9 23:21:42 2016: DEBUG: EAP Failure, elapsed time 0.135382 Tue Feb 9 23:21:42 2016: DEBUG: EAP result: 1, EAP TTLS inner authentication redispatched to a Handler Tue Feb 9 23:21:42 2016: DEBUG: AuthBy FILE result: REJECT, EAP TTLS inner authentication redispatched to a Handler Tue Feb 9 23:21:42 2016: INFO: Access rejected for anonym...@iit.edu: EAP TTLS inner authentication redispatched to a Handler Tue Feb 9 23:21:42 2016: DEBUG: Packet dump: *** Sending to 192.168.50.70 port 38670 Code: Access-Reject Identifier: 48 Authentic: <199><166><198><217>p55<139>9?<235>9<167><127><2><147> Attributes: EAP-Message = <4><5><0><4> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> Reply-Message = "Request Denied" Any help or insight would be appreciated. -- David Rose S
