eap-ttls with challenge-response
Hi, I've got working 2 factor (challenge-response) authentication by rlm_perl module (https://github.com/LinOTP/linotp-auth-freeradius-perl). I'm trying to secure this communication within tunnel (EAP-TTLS), but it ends with a message: No tunneled reply was found for request. If I disable challenge-response while using EAP-TTLS it works like a charm - Auth-Type linotp2 ends with ok state, and sends Access-Accept through tunnel. I've got no idea why it's not working with Access-Challenge reply and I think I've already tried every possible setup. This is my ttls config: ttls { tls = "tls-common" default_eap_type = "gtc" copy_request_to_tunnel = yes use_tunneled_reply = no virtual_server = "inner-tunnel" include_length = yes require_client_cert = no } and debug output: (5) perl: &request:User-Password = $RAD_REQUEST{'User-Password'} -> 'password' (5) perl: &request:User-Name = $RAD_REQUEST{'User-Name'} -> 'username' (5) perl: &request:Framed-MTU = $RAD_REQUEST{'Framed-MTU'} -> '1200' (5) perl: ERROR: Failed to create pair - failed to parse time string "sie 10 2022 11:23:48 CEST" (5) perl: ERROR: &request:Event-Timestamp = $RAD_REQUEST{'Event-Timestamp'} -> 'sie 10 2022 11:23:48 CEST' (5) perl: &request:Framed-IP-Address = $RAD_REQUEST{'Framed-IP-Address'} -> 'some_IP' (5) perl: &request:Service-Type = $RAD_REQUEST{'Service-Type'} -> 'Framed-User' (5) perl: &request:NAS-Identifier = $RAD_REQUEST{'NAS-Identifier'} -> 'linotp' (5) perl: &request:FreeRADIUS-Proxied-To = $RAD_REQUEST{'FreeRADIUS-Proxied-To'} -> '127.0.0.1' (5) perl: &request:NAS-IP-Address = $RAD_REQUEST{'NAS-IP-Address'} -> 'some_IP' (5) perl: &reply:State = $RAD_REPLY{'State'} -> '81561830980360' (5) perl: &reply:Reply-Message = $RAD_REPLY{'Reply-Message'} -> 'Multiple challenges submitted.' (5) perl: &control:Response-Packet-Type = $RAD_CHECK{'Response-Packet-Type'} -> 'Access-Challenge' (5) perl: &control:Auth-Type = $RAD_CHECK{'Auth-Type'} -> 'linotp2' (5) [perl] = handled (5) } # Auth-Type linotp2 = handled (5) } # server inner-tunnel (5) Virtual server sending reply (5) State = 0x3831353631383330393830333630 (5) Reply-Message = "Multiple challenges submitted." (5) eap_ttls: No tunneled reply was found for request 5 , and the request was not proxied: rejecting the user. (5) eap: ERROR: Failed continuing EAP TTLS (21) session. EAP sub-module failed (5) eap: Sending EAP Failure (code 4) ID 5 length 4 (5) eap: Failed in EAP select (5) [eap] = invalid (5) } # authenticate = invalid (5) Failed to authenticate the user Thanks for any advice and tips. Przemek
On Aug 10, 2022, at 5:54 AM, zolty <zolty@dzikakuna.net> wrote:
I've got working 2 factor (challenge-response) authentication by rlm_perl module (https://github.com/LinOTP/linotp-auth-freeradius-perl). I'm trying to secure this communication within tunnel (EAP-TTLS), but it ends with a message: No tunneled reply was found for request.
I don't think any EAP-TTLS supplicant supports interactive challenge-response. Which means this will never work. Which supplicants do you expect to use? What goal are you trying to achieve? The "No tunneled reply" message is because the code expects to see certain internal structures set correctly. Just setting the reply Packet-Type doesn't work here. The "outer" challenge/response functionality does look for the reply Packet-Type, so that's why it works. So "fixing" this requires code changes. And even if you do the code changes, the supplicants are unlikely to support it. And even if the supplicants do support it, they are very likely to *not* prompt the user for challenge-response. And even if the supplicants did prompt the user, it is a HORRIBLE experience to get prompted for a challenge every time you connect to a hotspot. Which might be a many times a day, if not many times an hour. I really don't see any way where this would work, and be useful to anyone. Perhaps your use-case is different, but you'd have to explain why. Alan DeKok.
W dniu 10.08.2022 o 14:13, Alan DeKok pisze:
The "No tunneled reply" message is because the code expects to see certain internal structures set correctly. Just setting the reply Packet-Type doesn't work here. The "outer" challenge/response functionality does look for the reply Packet-Type, so that's why it works.
Maybe I'm missing something but if this rlm_perl module works with PAP authentication I assume that it sets proper reply Packet-Type on output (access-challange). Why eap_ttls doesn't get the same reply when module is used inside inner-tunnel? This is how it works without tunnel: (10) perl: ERROR: Failed to create pair - failed to parse time string "sie 10 2022 15:43:39 CEST" (10) perl: ERROR: &request:Event-Timestamp = $RAD_REQUEST{'Event-Timestamp'} -> 'sie 10 2022 15:43:39 CEST' (10) perl: &request:User-Name = $RAD_REQUEST{'User-Name'} -> 'username' (10) perl: &request:NAS-Identifier = $RAD_REQUEST{'NAS-Identifier'} -> 'linotp' (10) perl: &request:Framed-IP-Address = $RAD_REQUEST{'Framed-IP-Address'} -> 'some_IP' (10) perl: &request:NAS-IP-Address = $RAD_REQUEST{'NAS-IP-Address'} -> 'some_IP' (10) perl: &request:User-Password = $RAD_REQUEST{'User-Password'} -> 'password' (10) perl: &reply:State = $RAD_REPLY{'State'} -> '98179912019396' (10) perl: &reply:Reply-Message = $RAD_REPLY{'Reply-Message'} -> 'Multiple challenges submitted.' (10) perl: &control:Response-Packet-Type = $RAD_CHECK{'Response-Packet-Type'} -> 'Access-Challenge' (10) perl: &control:Auth-Type = $RAD_CHECK{'Auth-Type'} -> 'linotp2' (10) [perl] = handled (10) } # Auth-Type linotp2 = handled (10) Using Post-Auth-Type Challenge (10) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (10) Challenge { ... } # empty sub-section is ignored (10) Sent Access-Challenge Id 9 from some_IP:1812 to some_IP:51567 length 0 (10) State = 0x3938313739393132303139333936 (10) Reply-Message = "Multiple challenges submitted." (10) Finished request
I really don't see any way where this would work, and be useful to anyone. Perhaps your use-case is different, but you'd have to explain why.
I'm testing 2 factor authentication for VPN users. It is working when VPN is using PAP as authentication protocol. User first provides his credentials and then VPN client asks for verification code (OTP). What I was trying to achieve is to put this communicaton inside secure tunnel (EAP-TTLS/PAP) - to stop sending unencrypted user credetials over the network.
On Aug 10, 2022, at 9:51 AM, zolty <zolty@dzikakuna.net> wrote:
W dniu 10.08.2022 o 14:13, Alan DeKok pisze:
The "No tunneled reply" message is because the code expects to see certain internal structures set correctly. Just setting the reply Packet-Type doesn't work here. The "outer" challenge/response functionality does look for the reply Packet-Type, so that's why it works.
Maybe I'm missing something but if this rlm_perl module works with PAP authentication I assume that it sets proper reply Packet-Type on output (access-challange). Why eap_ttls doesn't get the same reply when module is used inside inner-tunnel?
See my explanation above. I already answered this question.
I'm testing 2 factor authentication for VPN users. It is working when VPN is using PAP as authentication protocol. User first provides his credentials and then VPN client asks for verification code (OTP).
As I said in my previous message, it is very unlikely to work.
What I was trying to achieve is to put this communicaton inside secure tunnel (EAP-TTLS/PAP) - to stop sending unencrypted user credetials over the network.
User credentials are not sent unencrypted over the network. Anyone who tells you that is lying to you. EAP-TTLS + PAP sends user credentials encrypted with TLS, just like when you use HTTPS to log into a web site. It's fine. Even in RADIUS, the passwords are not sent in clear text over the network. For a longer explanation, see: https://networkradius.com/articles/2022/04/11/is-pap-secure.html What you're trying to do won't work, and won't add any security. It's a waste of time and effort. Just use TTLS+PAP. It's fine. Alan DeKok.
participants (2)
-
Alan DeKok -
zolty