peap/eap change in 3.0.x with inner_eap_module now required

[Stefan Winter]

Hi,

> I'm probably fairly unusual in having an eap instantiation (two
> even) that's not called "eap".

You're not alone.

My outer config has:

authorize {
        auth_log
        if ( RESTENA-Service-Type == "eduroam-lu" && User-Name =~
/restena.lu$/ ) {
                eap-staff
        }
        if ( RESTENA-Service-Type == "eduroam-lu" && User-Name !~
/restena.lu$/ ) {
                eap
        }

}


authenticate {
        Auth-Type eap-staff {
                eap-staff
        }
        eap
}

eap and eap-staff then have distinct virtual_server targets.

The inner virtual server for the non-default instance eap-staff then does:

authorize {
	...
        mschap
        eap-staff
        pap
	...
}

authenticate {
        Auth-Type PAP{
                pap
        }
        Auth-Type MSCHAP {
                mschap
        }
        Auth-Type eap-staff {
                eap-staff
        }
}

This works fine in 3.0.10.

After this conversation, I'm not entirely sure it will continue to. Do
you think it's worth testing this or is EverythingAlright(tm) with this one?

Greetings,

Stefan Winter

> 
>>> EAP modules here are called "outer-eap" and "inner-eap" (for my
>>> sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) )
>>
>>   What does the inner-tunnel "authenticate" section?   i.e. does it have:
>>
>> authenticate {
>> 	...
>> 	inner-eep
>> 	...
>> }
> 
> This. Well, default has
> 
>   authenticate {
>     outer-eap
>   }
> 
> and inner-innel has
> 
>   authenticate {
>     inner-eap
>   }
> 
> so basically the same as the default configration, except I've
> renamed the instances from eap to inner/outer-e.ap
> 
> outer-eap does PEAP, inner-eap does EAP-TLS.
> 
>>> Adding in the new "inner_eap_module" option to the outer PEAP
>>> section fixes it (inner_eap_module = "outer-eap") but I'm not sure
>>> why it needs to break in 3.0.x?
>>
>>   It doesn't need to break, of course.  But sanity checks are good.
> 
> Yeah, OK.
> 
>>   The problem was that the PEAP module was *hard-coded* to use
>>   "Auth-Type EAP".  Which worked fine for situation (2) above,
>>   but not so much for situation (1).
> 
> But it has always worked for (1) before - that's the default
> config (albeit with unchanged instance name I admit).
> 
> On Tue, Jan 19, 2016 at 02:26:57PM -0500, Alan DeKok wrote:
>> On Jan 19, 2016, at 2:16 PM, Alan DeKok <aland at deployingradius.com> wrote:
>>>  Hmm... If I configure the inner-tunnel virtual server as (1), I get:
>>
>>   No, my bad.  It works.
>>
>>   So my question again, is how the heck did it ever work when
>>   running inner-tunnel, Auth-Type EAP, and there's no "eap"
>>   module listed in "authenticate" ?
> 
> there is "outer-eap", just not "eap".
> 
>>   If it breaks peoples systems, I can relax the checks.  But I'd
>>   like to know just what the heck the system is actually doing.
> 
> TBH I've never quite got my head around why there is e.g.
> 
>   Auth-Type pap {
>     pap
>   }
> 
> for everything else, and just
> 
>   eap
> 
> for the eap module. I've always guessed that if the correct
> Auth-Type section is set then it uses that section, otherwise it
> just goes an calls all modules not in a named section in order (as
> in authorize) and hopes that something picks it up?
> 
> Guess I should go and read the code.... just haven't ever needed
> to check this as it's always just worked, albeit looked slightly
> odd :)
> 
> Thanks,
> 
> Matthew
> 
> 
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20160120/746a5550/attachment.sig>