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
[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
