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

[karthik kumar]

Thanks Phil and Alan for your inputs.

I got it working by, *not* following
https://wiki.freeradius.org/guide/multiOTP-HOWTO instead in the file

*/etc/raddb/mods-enabled/mschap*

*mschap {*
*    ntlm_auth = "/usr/bin/multiotp %{User-Name} %{User-Password}
-request-nt-key -src=%{Packet-Src-IP-Address}
-chap-challenge=%{CHAP-Challenge} -chap-password=%{CHAP-Password}
-ms-chap-challenge=%{MS-CHAP-Challenge}
-ms-chap-response=%{MS-CHAP-Response}
-ms-chap2-response=%{MS-CHAP2-Response}"*
*  .....*
*}*

My guess/theory is this https://wiki.freeradius.org/guide/multiOTP-HOWTO
says to update the policy and *Auth-Type == multiotp/**multiotpmschap *which
will never run mschap during authenticate

output with NO multiotp configured.. I found somewhere mschap plugin is
creating the variable  MS-CHAP-Challenge (may be from EAP-Message)

*(13) mschap: Creating challenge hash with username: karthik*
*(13) mschap: Client is using MS-CHAPv2*
*(13) mschap: Adding MS-CHAPv2 MPPE keys*


but it finally there is MS-CHAP-Challenge

*(6) eap_mschapv2: # Executing group from file
/etc/raddb/sites-enabled/default*
*(6) eap_mschapv2:   authenticate {*
*(6) mschap: Creating challenge hash with username: kumar*
*(6) mschap: Client is using MS-CHAPv2*
*(6) mschap: Executing: /usr/bin/multiotp %{User-Name} %{User-Password}
-request-nt-key -src=%{Packet-Src-IP-Address}
-chap-challenge=%{CHAP-Challenge} -chap-password=%{CHAP-Password}
-ms-chap-challenge=%{MS-CHAP-Challenge}
-ms-chap-response=%{MS-CHAP-Response}
-ms-chap2-response=%{MS-CHAP2-Response}:*
*(6) mschap: EXPAND %{User-Name}*
*(6) mschap:    --> kumar*
*(6) mschap: EXPAND %{User-Password}*
*(6) mschap:    -->*
*(6) mschap: EXPAND -src=%{Packet-Src-IP-Address}*
*(6) mschap:    --> -src=127.0.0.1*
*(6) mschap: EXPAND -chap-challenge=%{CHAP-Challenge}*
*(6) mschap:    --> -chap-challenge=*
*(6) mschap: EXPAND -chap-password=%{CHAP-Password}*
*(6) mschap:    --> -chap-password=*
*(6) mschap: EXPAND -ms-chap-challenge=%{MS-CHAP-Challenge}*
*(6) mschap:    --> -ms-chap-challenge=0xba877ea85ac1d74ab0daa496b4cfb55c*
*(6) mschap: EXPAND -ms-chap-response=%{MS-CHAP-Response}*
*(6) mschap:    --> -ms-chap-response=*
*(6) mschap: EXPAND -ms-chap2-response=%{MS-CHAP2-Response}*
*(6) mschap:    -->
-ms-chap2-response=0x02758b70955a1e940db1a14e946ca53eaaf000000000000000007f1121d3a2f97727df83b1cb92e150b69b95f0d6b28c6138*





thanks

On Fri, Mar 16, 2018 at 10:03 PM, Alan DeKok <aland at deployingradius.com>
wrote:

> 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.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
>