stefan.paetow@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.