ttls/gtc + perl

Alan DeKok aland at deployingradius.com
Sat Jan 9 11:54:20 CET 2010


Alexander Clouter wrote:
> 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.

  Because you manage the State attribute...


> 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

  You need to set the reply code, which isn't currently possible with
the Perl module.

> 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.  

  I'm not sure what you mean by that... for non-EAP sessions, make sure
the previous config is used.  For EAP, use the EAP config.

> It's as if the fake-request stuff does not support RLM_MODULE_HANDLED?  

  It does.  But when the EAP module returns "handled", it also sets the
reply code.

> 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?).

  Yes.  The EAP module generates && tracks its own State.  Don't add
another one, or it will get confused.

> 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?

  What doesn't that mean?

>  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?

  Probably not.

  Alan DeKok.



More information about the Freeradius-Devel mailing list