eap-ttls with challenge-response

zolty zolty at dzikakuna.net
Wed Aug 10 13:51:17 UTC 2022


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.


More information about the Freeradius-Users mailing list