ttls/gtc + perl

[Alexander Clouter]

Hi,

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: No line available at 300 baud.