Re: ttls/gtc + perl

8 Jan 2010

      Hi,

I'm guessing I'm on my own with this...*sigh*.

Cheers

Alexander Clouter <alex@digriz.org.uk> wrote:
...
I'm slapping together a OTP system to use with FreeRADIUS and for the 
EAP side of things I am using GTC to get the challenge to the user and 
the response back.
I first of all implemented everything nicely with just a straight 
forward non-EAP Access-Challenge approach; using rlm_perl to dish out a 
State attribute[1], the Reply-Message and of course to check the 
User-Password returned.  This works great for pam_radius_auth.
Then I moved onto the EAP side of things.  The state of play is:
TTLS -> GTC -> Perl
The relevant bits of my config looks like:
----
eap gtc-trial.eap {
       ....
gtc {
               challenge = "%{reply:Reply-Message}"
               auth_type = rfc2289
       }
ttls {
               default_eap_type = md5
               copy_request_to_tunnel = no
               use_tunneled_reply = yes
       }
....
}
--
authorize {
       ....
gtc-trial.perl
       gtc-trial.eap
}
authenticate {
       Auth-Type gtc-trial.eap {
               gtc-trial.eap
       }
       Auth-Type rfc2289 {
               gtc-trial.perl
       }
}
--
----
As you can see nothing exciting.  Now in the authorize section of the 
Perl module I wrote, when I send the Reply-Message challenge I return 
RLM_MODULE_HANDLED as the return code.  The problem is when I do this I 
get:
----
++[gtc-trial.perl] returns handled
} # server gtc-trial
[ttls] Got tunneled reply code 0
       Reply-Message = "otp-md5 489 ch4230"
[ttls] No tunneled reply was found for request 6 , and the request was 
not proxied: rejecting the user.
[gtc-trial.eap] Handler failed in EAP/ttls
rlm_eap_ttls: Freeing handler for user ac56@soas.ac.uk
[gtc-trial.eap] Failed in EAP select
++[gtc-trial.eap] returns invalid
Failed to authenticate the user.
} # server gtc-trial
Using Post-Auth-Type Reject
----
Changing it to RLM_MODULE_OK lets it pass through and everything starts 
to work, but it feels wrong; also as I would have to add difficult code 
paths for EAP and non-EAP connections.  
----
++[gtc-trial.perl] returns ok
[gtc-trial.eap] EAP packet type response id 1 length 6
[gtc-trial.eap] No EAP Start, assuming it's an on-going EAP conversation
++[gtc-trial.eap] returns updated
Found Auth-Type = gtc-trial.eap
+- entering group gtc-trial.eap {...}
[gtc-trial.eap] Request found, released from the list
[gtc-trial.eap] EAP NAK
[gtc-trial.eap] EAP-NAK asked for EAP-Type/gtc
[gtc-trial.eap] processing type gtc
[gtc]   expand: %{reply:Reply-Message} -> otp-md5 489 ch4230
++[gtc-trial.eap] returns handled
} # server gtc-trial
[ttls] Got tunneled reply code 11
       Reply-Message = "otp-md5 489 ch4230"
       EAP-Message = 0x01020017066f74702d6d64352034383920636834323330
       Message-Authenticator = 0x00000000000000000000000000000000
       State = 0x2ab1156b2bb3138a6ec7c66d7216040d
[ttls] Got tunneled Access-Challenge
++[gtc-trial.eap] returns handled
} # server gtc-trial
Sending Access-Challenge of id 57 to 77.75.106.34 port 1645
       EAP-Message = 0x010a003f158000000035170301003060c61e58df7bb793b8bb0ff121a83f4c2e6709089d2806be79ba5b38f1188e918e1a23a26a5361cd919357ebf957b3b6
       Message-Authenticator = 0x00000000000000000000000000000000
       State = 0x799072d07e9a671e00b9e884d1d4d75c
----
It's as if the fake-request stuff does not support RLM_MODULE_HANDLED?  
Of course I could be mis-understanding things completely and I should 
just stick with RLM_MODULE_OK...even for the non-EAP requests (however 
that *does* feel wrong).
On a separate note I found out the hard way then passing 'State' back as 
a Reply attribute causes the EAP state machine to find two State 
attributes flying around rather than just the one it generates (am I 
understanding this correctly?).
----
[gtc-trial.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
       EAP-Message = 0x020100060306
       FreeRADIUS-Proxied-To = 127.0.0.1
[ttls] Sending tunneled request
       EAP-Message = 0x020100060306
       FreeRADIUS-Proxied-To = 127.0.0.1
       User-Name = "ac56@soas.ac.uk"
       State = 0x72666332323839
       State = 0xa044d18fa045d5754a1bb165bbc5857d
[snipped]
[gtc-trial.eap] EAP packet type response id 1 length 6
[gtc-trial.eap] No EAP Start, assuming it's an on-going EAP conversation
++[gtc-trial.eap] returns updated
Found Auth-Type = gtc-trial.eap
+- entering group gtc-trial.eap {...}
[gtc-trial.eap] Either EAP-request timed out OR EAP-response to an unknown EAP-request
[gtc-trial.eap] Failed in handler
++[gtc-trial.eap] returns invalid
Failed to authenticate the user.
} # server gtc-trial
[ttls] Got tunneled reply code 3
[ttls] Got tunneled Access-Reject
[gtc-trial.eap] Handler failed in EAP/ttls
rlm_eap_ttls: Freeing handler for user ac56@soas.ac.uk
[gtc-trial.eap] Failed in EAP select
++[gtc-trial.eap] returns invalid
Failed to authenticate the user.
} # server gtc-trial
Using Post-Auth-Type Reject
----
If I am having to opt for a slightly different code path for my Perl 
module's authorize section (OK for EAP and HANDLED for non-EAP) is it 
safe to assume EAP is keeping everything in order?  I am just using the 
State attribute to indicate that the challenge has been issued to the 
user and to avoid validating 'trash'; for example in the case of when 
using the Challenge-Response functionality found in mod_auth_radius.  I 
see in ttls.c:process_reply() there are a number of probably relevant 
FIXME's on something that could be applicable?
If you need any more information or the actual code, then do ask.
Cheers
[1] similarly to how Harry J Walsh was doing things:
       http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg47425.h...
-- 
Alexander Clouter
.sigmonster says: Truth is hard to find and harder to obscure.