[strongSwan] Android client - Use MSCHAPv2

[Aurélien Vallée]

Thanks a lot for your answer. I just found out a working (though not
perfect) solution.

We have the default Charon configuration, which basically loads all modules
Charon was built with. I spent hours tweaking charon's configuration to
have eap-dynamic prefer mschapv2, disable eap-md5, etc. With no result: the
server would still propose Eap-md5 to the client, the client would accept
it, and the server would fail.

I just found out that it is actually radius that chooses the default EAP
method. Everything works fine now that mschapv2 is the default radius EAP
method. Never hit that issue before because in all our other (Linux) is
clients we have access to the ipsec.conf directly, so we directly set
leftauth to eap-mschapv2 and the client will happily Nak everything else.

Still, I agree with you that only mschapv2 should be proposed by the
server. I just have to find out how to do that.. Charon does not seem to
have any incidence on what is proposed to the client. My understanding now
is radius is responsible for all of the possible EAP methods. Am I correct?

On Mon, Sep 14, 2020, 20:56 Tobias Brunner <tobias at strongswan.org> wrote:

> Hi,
>
> > The feature list explicitly states that the android client supports
> > EAP-MSCHAPv2, but I see no way to actually enforce that on the client,
> > and the authentication keeps failing because EAP-MD5 is used.
>
> The (AAA) server is the one initiating the EAP method, the client can't
> explicitly choose the method (it could reject the initiated method and
> send a list of supported ones, but the Android client has no option to
> explicitly reject one of the username/password methods).  So how is
> EAP-MD5 failing?  Why is the server initiating a method that then fails?
>  And why don't you just let the server initiate EAP-MSCHAPv2 if you want
> to use that?
>
> Regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200914/75d7b730/attachment.html>