multiotp with strongswan has no (ms)-chap-challenge

[Alan DeKok]

On Mar 16, 2018, at 3:51 PM, Phil Frost <phil at postmates.com> wrote:
> 
> On Fri, Mar 16, 2018 at 2:52 PM Alan DeKok <aland at deployingradius.com>
> wrote:
> 
>>  When I say *No amount of poking FreeRADIUS will magically create that
>> attribute  Only Strongswan can do that.*... I really mean it.  Please don't
>> respond with "but how do I configure FreeRADIUS..."  I already told you
>> that you need to configure the *client*.
>> 
> 
> Thank you for this eloquent statement of the obvious.

  Sometimes it's useful to re-iterate the steps to the end goal.

> Firstly, "straight" RADIUS exchanges attribute-value pairs. Those
> attribute-value pairs have things like usernames and passwords in them.
> freeradius checks them, obviously. I believe when you are using radtest,
> you are exercising this mode of operation.
> 
> But this is not how freeradius and strongswan work. In the case of IKEv2,

  RADIUS always contains attribute-value pairs...

> authentication in your case happens via EAP. In this mode of operation,
> IKEv2 and RADIUS are just transports for EAP. EAP-in-RADIUS is described in
> RFC 3579. It amounts to taking the EAP protocol, and stuffing it inside an
> EAP-Message attribute. You'll never see the chap challenge in a RADIUS
> attribute, because it's inside EAP, which is inside the EAP-Message
> attribute.

  Sort of...  CHAP-Challenge *is* a RADIUS attribute, which you do see in RADIUS packets.

  In your case, you're using EAP-MSCHAPv2.  Which ends up being transported over RADIUS, which contains EAP-Message, which on turn contains EAP, which contains sub-type EP-MSCHAPv2, which then contains the MS-CHAPv2 data.

  It's all a bit miraculous that it works...

> So if radtest works, but things fail when you try through strongswan, it
> may be that EAP is not working.

  That's why there are comments at the top of the "inner-tunnel" virtual server.

  And that's why the debug output is so voluminous and detailed.

> I'd suggest starting freeradius as "freeradius -X" or "radiusd -X", and you
> can then see the RADIUS attribute-value pairs as freeradius sees them. You
> must configure in strongswan's eap-radius plugin the option "eap_start =
> no". If you do not do this, strongswan will send an Access-Request
> containing the IKEv2 identity from the initiator, but no credentials and no
> EAP-Message to freeradius.

  That's a bad thing to do to users... it should NOT be possible to configure Strongswan to violate the RFCs in this way.

  Alan Dekok.