ttls/gtc + perl

[Alexander Clouter]

Hi,

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

Cheers

Alexander Clouter <alex at 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 at 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 at 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 at 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.html

-- 
Alexander Clouter
.sigmonster says: Truth is hard to find and harder to obscure.