Question about EAP-TTLS session resumption
Hi, 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. 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? 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. 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? -- begin of debug output -- Ready to process requests. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=2, length=53 User-Name = "bob" EAP-Message = 0x0200000801626f62 Message-Authenticator = 0xeec2f0280b8274f92fc902a15122729c # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 0 length 8 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] EAP Identity [eap] processing type tls [tls] Initiate [tls] Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 2 to 172.23.6.33 port 49802 EAP-Message = 0x010100061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xee0ac522ee0bd0bfaaf533badfdea46d Finished request 0. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=3, length=135 User-Name = "bob" State = 0xee0ac522ee0bd0bfaaf533badfdea46d EAP-Message = 0x020100481500160301003d010000390301517e66cc1774b02aba3b0067774c719d9a7c24c36fb94a5d97f862a59f866bd30000120039003800330032001600130035002f000a0100 Message-Authenticator = 0x93d337adcf53e180ece72e8e881f3022 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 1 length 72 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] (other): before/accept initialization [ttls] TLS_accept: before/accept initialization [ttls] <<< TLS 1.0 Handshake [length 003d], ClientHello [ttls] TLS_accept: SSLv3 read client hello A [ttls] >>> TLS 1.0 Handshake [length 002a], ServerHello [ttls] TLS_accept: SSLv3 write server hello A [ttls] >>> TLS 1.0 Handshake [length 085e], Certificate [ttls] TLS_accept: SSLv3 write certificate A [ttls] >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange [ttls] TLS_accept: SSLv3 write key exchange A [ttls] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [ttls] TLS_accept: SSLv3 write server done A [ttls] TLS_accept: SSLv3 flush data [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 3 to 172.23.6.33 port 49802 EAP-Message = 0x0102040015c000000aad160301002a020000260301517e66cc4dd7399c18c8e95722c093c30c18a2b3549d244021917a9abb3cf70c00003900160301085e0b00085a0008570003a6308203a23082028aa003020102020101300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479 EAP-Message = 0x301e170d3133303332383130343130335a170d3133303532373130343130335a307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100c2361ca9a23bfb2d48d6a3c5f76e83350f2a58e42587f9adc4de3612058d892aa23524ebdd297ca35a4f8c0611df6c3c5fefe1960457461c408837e5a510 EAP-Message = 0x34b1ae326dd147568ab1f1bff4fa5d40bcf87b28c9c030344a4cbe39a61ff41fe8cfdc10ef05ccc6aafeff7f0174dddb5eaa3b9c1fd69123d1ea0200dc979466ade9c041914e82e1797ad55d78246505f6afe90216d3ccb0dd528f3af0d3ac20cb3211bd6add5ac2c17aa4162059f955ecbefd1f15f9129b81189d265af1ec0079756a51cfed7d324ba21ef25f76331646759c0803ff0991f67146414b32c22dcc55403641c94e203e4cef260f1becdab151f573deaf0cc24f91fd48d2f5256beef50203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d0101050500038201010041663c32fe5eedd682 EAP-Message = 0xddc752319616593b579b11640c49c453da1185607efccb85c520e0b6ff8c5af5ee473eedce1dc2b34511697a799e7714d1a172ff7b28a795f98d318b22a8830949f603ea384648c5b5dc87d29aaf0837b35656dce70a09354480a66724153ab9fad79c4beef5f2e7cb2dbcd5bcecc6a09351cb60e7052d3c8e3d61d2bd731ebe2ffe45b961c1eaebe18d869dcd3a90c3330bcfa11426d5b69a100a67171af5c5f4c9a039a8633facfa708cdd222bdf9b3c5eca0ac2b9d2b2b6cd64c0e36e2a552c2599bd718a439eb451fca5061d049aa0b4da32261b5d42f03bb66414744b5dd5eb409203f382991f8c30ba7a39459570d75007dfeaaf0004ab308204 EAP-Message = 0xa73082038fa0030201020209 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xee0ac522ef08d0bfaaf533badfdea46d Finished request 1. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=4, length=69 User-Name = "bob" State = 0xee0ac522ef08d0bfaaf533badfdea46d EAP-Message = 0x020200061500 Message-Authenticator = 0x70dbb506dd3e90f77ccd778face63bce # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 2 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 4 to 172.23.6.33 port 49802 EAP-Message = 0x0103040015c000000aad0084f610431892d8fc300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3133303332383130343130335a170d3133303532373130343130335a308193310b3009060355040613024652310f300d0603550408130652616469757331123010 EAP-Message = 0x06035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100bbed8595e784e9c7c0df8907a92d8fbd387b3573c00086b0f36a983ef0f17a98a884b384f3f9b735c2ca53bf7752d09a75c86c4ae311ad013ed00a6f8e5059e49fbbc4d0bb89deff65a02ecb4bfe539b732f40c1f5eec0e948aceff8f4c127db4a0d094802ce5c831d5fdf EAP-Message = 0xc29ab0bdf654698c465becf471fa0e9ff5a4710ac2049b3b1e0c5c28130974a15d3196b2e9ed8045ecd85877bd2c5d5a2611960a7bf231b24a7df880684adcb83672ede7978ed87702fc5dea2481b7e57b2915a6e636095acd7ccf81fb63d9ad11a662e603e608e99ce8f8da2ad5580a4ff9e2fc04e17e48880e88469b2eeec32a799ea415402223b6963f0457fe9e078b7700ac850203010001a381fb3081f8301d0603551d0e041604149fb44e41b351c3814ceb1717bb8635456bb14c373081c80603551d230481c03081bd80149fb44e41b351c3814ceb1717bb8635456bb14c37a18199a48196308193310b3009060355040613024652310f300d EAP-Message = 0x060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747982090084f610431892d8fc300c0603551d13040530030101ff300d06092a864886f70d01010505000382010100998e6624f26413f190607c91e2c1980a631e7502118553724829370404c2a76be99df3f8fc002ab9d5058e545a4fba5d5141ee1289e23210e2a68046e2f84f251d8a2aac18bf7d480882dc7bab3b EAP-Message = 0x6e17558a9a641e99eb1dd950 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xee0ac522ec09d0bfaaf533badfdea46d Finished request 2. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=5, length=69 User-Name = "bob" State = 0xee0ac522ec09d0bfaaf533badfdea46d EAP-Message = 0x020300061500 Message-Authenticator = 0xc5b78f00d90d9000f380c6c4ffbf1e03 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 3 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 5 to 172.23.6.33 port 49802 EAP-Message = 0x010402cb158000000aadbf54dd4a547886f0e1b9c2de1016d7e2cffa5639e29b519987f01a974ea9f4808f63b48391965c13a0a7f93dbeb91696b8c1aee94ea74d7a347a3f54d5bf68bb967c97aeec64c7360224f361a18df585547ce3b547cf6d9955dcbc1a514d792259c0b25672a871f18a14a8a25abe32f12e42917dfac450cb0361478cec76ffb33bb2d0cae6b7edc1e1aa81620b64c586e4a1c09bf360c6b72b716122184825d718ac7c120d91160301020d0c0002090080b34ae22174e4eeae3fca75f04f4d925acf03a3263797fdd693c77f43551070859c00a5c1efc1c1ac0c50a3be2a6f3f8020a1642dbe282f5f528c6eab4e563c30609a EAP-Message = 0x63b1526ba290556dbd48c0f94578e2e90209ec08f006b2cee430c8daeb0f8940309fbbecaa2fb31fa3a9e6f0a518acdf08f2b49cdc25668b2753648e28730001020080543bbf88aa79bd53f6160d0d35a072f857b9c2972aab6332705af63a790d6403e9c49ff22b2dc49357404f932d07dd5f356f50278d7bbcf0626306b6ebaf3b31094b6f3969d60275c81928f76c7324e7432e60e507fc82f2047d9fd1116d0cc7492cd19e8af4e0dfad67e34f71c991ac2124e0ec5cc0bfc4d66d1105044afb3301002609ffc594fff901957db2d2aa85722cb988ef50d088331db2bd44fc8b42c435dbb8acfe4b7132f89ad2d6962ce4d15bf2b3f59f6089fd12 EAP-Message = 0xa0a20b93710c7261920e086b869d8830fd2b364478a99aad88e55943423ed0e9685288e1a6296eafc1e6ecbfd23814050ac1be7fb16f7a14e18cf093e42d6ef9c5e76b56f4c8dfbd1190faaf3612164971be6ed9afad7139baee74ad1fd919830e4dd47e5c39323f8c30ad328883d247faf64041a8fc47e6900b1fe4d32fe34bb1570021cd2eb41e84fd085c44c0c4fa850c993265052d2d736bf5b618ddfa80ef1d38a3fc4b7adf22e4cd87dc042e7b6532a38c7f3ff378502cba9ef44e929e31984e44cc10803a16030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xee0ac522ed0ed0bfaaf533badfdea46d Finished request 3. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=6, length=283 User-Name = "bob" State = 0xee0ac522ed0ed0bfaaf533badfdea46d EAP-Message = 0x020400dc150016030100861000008200807a3e5b1c5275fc1a5d9703a1869a10c97c0a5d952ef68856282db3247caa800e92f99db7e955628d4b8169744a4041bdeb9283fe6325b96111d66b23fbc6a9d08247e07848ee4b455e093eb0c42ddbb1471c7a7d767d000578d9a72d98f3f10a6867235b586db242befec8b05e9fc7f6290035a891c22ed8dcd63e7c281d0e2714030100010116030100403c4b17cf47865ca8145dadaa0ccaf7e4583434a078dfac613f87a2ab57bab4268a49102b25db060671325f131472762ba222400f2922d8b86a1c41b4929a6d77 Message-Authenticator = 0xab95b02d63cd2fce1e5d84f12d46df51 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 4 length 220 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange [ttls] TLS_accept: SSLv3 read client key exchange A [ttls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [ttls] <<< TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 read finished A [ttls] >>> TLS 1.0 ChangeCipherSpec [length 0001] [ttls] TLS_accept: SSLv3 write change cipher spec A [ttls] >>> TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 write finished A [ttls] TLS_accept: SSLv3 flush data [ttls] (other): SSL negotiation finished successfully SSL Connection Established [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 6 to 172.23.6.33 port 49802 EAP-Message = 0x0105004515800000003b1403010001011603010030bfce3580cef44ecb9c8167c8936362b0e3d27e143628bced69d63ee326962203b07bfdce8c5ff92be9a767135dfa174e Message-Authenticator = 0x00000000000000000000000000000000 State = 0xee0ac522ea0fd0bfaaf533badfdea46d Finished request 4. Going to the next request Waking up in 4.8 seconds. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=7, length=69 User-Name = "bob" State = 0xee0ac522ea0fd0bfaaf533badfdea46d EAP-Message = 0x020500061500 Message-Authenticator = 0xed6e7eafb52ef1f2d6420942208619b7 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 5 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake is finished [ttls] eaptls_verify returned 3 [ttls] eaptls_process returned 3 ++[eap] returns handled Sending Access-Challenge of id 7 to 172.23.6.33 port 49802 EAP-Message = 0x0106000a158000000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xee0ac522eb0cd0bfaaf533badfdea46d Finished request 5. Going to the next request Waking up in 4.8 seconds. rad_recv: Access-Request packet from host 172.23.6.33 port 49802, id=8, length=175 User-Name = "bob" State = 0xee0ac522eb0cd0bfaaf533badfdea46d EAP-Message = 0x02060070150017030100204bd552b4e34fa7ad1f304d79a10e0268d458c78c0ab0a4dfa7e5eba562ad977f170301004070b2bbfb2617b0c7e477b6bb36c0d1264019ac58b3994ee3b2a5567d091719ca07f880770713cc8b6813b2d08ab93c50f4a07d3e3a361a7fd95a8dba52d56ade Message-Authenticator = 0xcef7f32703068c422db34b44728943c9 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 6 length 112 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request User-Name = "bob" User-Password = "test" FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request User-Name = "bob" User-Password = "test" FreeRADIUS-Proxied-To = 127.0.0.1 server inner-tunnel { # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel +- entering group authorize {...} ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "bob", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[control] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user Failed to authenticate the user. } # server inner-tunnel [ttls] Got tunneled reply code 3 [ttls] Got tunneled Access-Reject [eap] Handler failed in EAP/ttls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> bob attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 6 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 6 Sending Access-Reject of id 8 to 172.23.6.33 port 49802 EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.8 seconds. Cleaning up request 0 ID 2 with timestamp +56 Cleaning up request 1 ID 3 with timestamp +56 Cleaning up request 2 ID 4 with timestamp +56 Cleaning up request 3 ID 5 with timestamp +56 Waking up in 0.1 seconds. Cleaning up request 4 ID 6 with timestamp +56 Cleaning up request 5 ID 7 with timestamp +56 Waking up in 1.0 seconds. Cleaning up request 6 ID 8 with timestamp +56 Ready to process requests. rad_recv: Access-Request packet from host 172.23.6.33 port 49808, id=9, length=55 User-Name = "steve" EAP-Message = 0x0200000801626f62 Message-Authenticator = 0xc73f5d44c09c2e24670ad724fb07ec95 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "steve", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 0 length 8 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated [files] users: Matched entry steve at line 76 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Identity does not match User-Name, setting from EAP Identity. [eap] Failed in handler ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> steve attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 7 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 7 Sending Access-Reject of id 9 to 172.23.6.33 port 49808 Waking up in 4.9 seconds. Cleaning up request 7 ID 9 with timestamp +78 Ready to process requests. -- end of debug -- Stefan Paetow -- 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
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.
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.uk@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk@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.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. - 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
stefan.paetow@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 = 0x0200000801626f62 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.
Thanks again for the confirmation, Alan. :-) Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac.uk@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.paetow@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 = 0x0200000801626f62 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
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.
participants (3)
-
Alan DeKok -
David Bird -
stefan.paetow＠diamond.ac.uk