Re: Question about EAP-TTLS session resumption
stefan.pae...@diamond.ac.uk wrote: We're trying to put together an EAP-TTLS authentication solution with another open-source authentication server (Jasig CAS). We've found that only the first authentication process succeeds, but everything else after fails. In order for us to pinpoint whether this is a problem in the CAS software or the JRadius implementation of the EAP-TTLS Radius authenticator, I'd just like to confirm with the Radius experts on the list that I have some things right. Well, TTLS session resumption works with wpa_supplicant, Windows, Macs, etc. As far as I understand RFC5281 (the EAP-TTLS RFC) in general and Section 15.3 (session resumption) more in particular, the EAP-TTLS session should only be resumed if the client was successfully authenticated with the server. So am I correct in saying that if an EAP-TTLS session was established and a username and password were passed through the tunnel that were not successfully authenticated (i.e. the password was incorrect), the session cannot be resumed and should start again, i.e. a new tunnel session should be negotiated and the authentication request retried? Yes. What we've seen is that the radiusd -X output shows a full EAP-TTLS session negotiation the first time, but then only a resumption (or at least that's what FreeRADIUS assumes, based on the debug output) of the session to continue. FreeRADIUS then sees the EAP handler fail. It sees more than that. There's no point in reading only *one* message out of many. The reason the other debug messages exist is because they're *useful*. Should that session (i.e. 'request 7 ID 9') have been renegotiated and restarted because the user-password combination of 'bob' and 'test' is invalid? The debug log *doesn't* show session resumption. If it did, it would have text about session resumption. -- begin of debug output -- Which shows that the inner-tunnel configuration is incapable of authenticating a user bob with password test. This has nothing to do with session resumption. Your inner-tunnel configuration is wrong. You haven't configured a known good password for the user. So how is the server supposed to check that bob/test is a valid user/password? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Question about EAP-TTLS session resumption
Alan, The user 'bob' does not exist, so FreeRADIUS does the correct thing (i.e. rejecting the user). This has not been in doubt at all. However, when you go to the bottom of the output, where the request for user 'steve' (who is a valid user, and for whom a correct password was supplied) is sent, the request fails. The session for 'steve' is partial and stops prematurely, which leads me to believe that the EAP-TTLS client (the JRadius EAPTTLSAuthenticator bean) is not complying with the RFC, i.e. restart the EAP session, negotiate a fresh tunnel, and then attempt to authenticate the valid user 'steve' with the given password. Based on the debug output, it appears that the client simply re-uses the existing tunnel, which, according to the RFC and your confirmation, is not correct. So thanks for confirming that part of the theory. :-) To prove that, I've just had a bit more of a play-around with the Java webapp, and when we restart it between authentication requests, the correct process is followed, i.e. establish an EAP session, negotiate a tunnel, attempt authentication, and every session is complete. I'll have a word with David over at Coova about the bean in question. Regards Stefan -Original Message- From: freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 29 April 2013 14:08 To: FreeRadius users mailing list Subject: Re: Question about EAP-TTLS session resumption stefan.pae...@diamond.ac.uk wrote: We're trying to put together an EAP-TTLS authentication solution with another open-source authentication server (Jasig CAS). We've found that only the first authentication process succeeds, but everything else after fails. In order for us to pinpoint whether this is a problem in the CAS software or the JRadius implementation of the EAP-TTLS Radius authenticator, I'd just like to confirm with the Radius experts on the list that I have some things right. Well, TTLS session resumption works with wpa_supplicant, Windows, Macs, etc. As far as I understand RFC5281 (the EAP-TTLS RFC) in general and Section 15.3 (session resumption) more in particular, the EAP-TTLS session should only be resumed if the client was successfully authenticated with the server. So am I correct in saying that if an EAP-TTLS session was established and a username and password were passed through the tunnel that were not successfully authenticated (i.e. the password was incorrect), the session cannot be resumed and should start again, i.e. a new tunnel session should be negotiated and the authentication request retried? Yes. What we've seen is that the radiusd -X output shows a full EAP-TTLS session negotiation the first time, but then only a resumption (or at least that's what FreeRADIUS assumes, based on the debug output) of the session to continue. FreeRADIUS then sees the EAP handler fail. It sees more than that. There's no point in reading only *one* message out of many. The reason the other debug messages exist is because they're *useful*. Should that session (i.e. 'request 7 ID 9') have been renegotiated and restarted because the user-password combination of 'bob' and 'test' is invalid? The debug log *doesn't* show session resumption. If it did, it would have text about session resumption. -- begin of debug output -- Which shows that the inner-tunnel configuration is incapable of authenticating a user bob with password test. This has nothing to do with session resumption. Your inner-tunnel configuration is wrong. You haven't configured a known good password for the user. So how is the server supposed to check that bob/test is a valid user/password? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about EAP-TTLS session resumption
stefan.pae...@diamond.ac.uk wrote: However, when you go to the bottom of the output, where the request for user 'steve' (who is a valid user, and for whom a correct password was supplied) is sent, the request fails. The session for 'steve' is partial and stops prematurely, which leads me to believe that the EAP-TTLS client (the JRadius EAPTTLSAuthenticator bean) is not complying with the RFC, i.e. restart the EAP session, negotiate a fresh tunnel, and then attempt to authenticate the valid user 'steve' with the given password. Except it's not a request for steve: User-Name = steve EAP-Message = 0x020801626f62 The EAP-Message says that the EAP Identity is for user bob. The EAP client you're using is broken. Fix that before you try anything else. Based on the debug output, it appears that the client simply re-uses the existing tunnel, which, according to the RFC and your confirmation, is not correct. So thanks for confirming that part of the theory. :-) Likely, yes. To prove that, I've just had a bit more of a play-around with the Java webapp, and when we restart it between authentication requests, the correct process is followed, i.e. establish an EAP session, negotiate a tunnel, attempt authentication, and every session is complete. I'll have a word with David over at Coova about the bean in question. Sounds like a plan. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Question about EAP-TTLS session resumption
Thanks again for the confirmation, Alan. :-) Stefan -Original Message- From: freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 29 April 2013 15:35 To: FreeRadius users mailing list Subject: Re: Question about EAP-TTLS session resumption stefan.pae...@diamond.ac.uk wrote: However, when you go to the bottom of the output, where the request for user 'steve' (who is a valid user, and for whom a correct password was supplied) is sent, the request fails. The session for 'steve' is partial and stops prematurely, which leads me to believe that the EAP-TTLS client (the JRadius EAPTTLSAuthenticator bean) is not complying with the RFC, i.e. restart the EAP session, negotiate a fresh tunnel, and then attempt to authenticate the valid user 'steve' with the given password. Except it's not a request for steve: User-Name = steve EAP-Message = 0x020801626f62 The EAP-Message says that the EAP Identity is for user bob. The EAP client you're using is broken. Fix that before you try anything else. Based on the debug output, it appears that the client simply re-uses the existing tunnel, which, according to the RFC and your confirmation, is not correct. So thanks for confirming that part of the theory. :-) Likely, yes. To prove that, I've just had a bit more of a play-around with the Java webapp, and when we restart it between authentication requests, the correct process is followed, i.e. establish an EAP session, negotiate a tunnel, attempt authentication, and every session is complete. I'll have a word with David over at Coova about the bean in question. Sounds like a plan. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about EAP-TTLS session resumption
The user 'bob' does not exist, so FreeRADIUS does the correct thing (i.e. rejecting the user). This has not been in doubt at all. Instantiate a new EAPTTLSAuthenticator() for each authentication session and you should be fine. The Authenticator class is there to maintain a context through a single authentication session, generally. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
