[strongSwan-dev] New feature extending support for RFC 5998 EAP-only authentication

Tobias Brunner tobias at strongswan.org
Tue Apr 7 19:05:46 CEST 2020

Hi Thomas,

> I've noticed that many IKEv2/IPsec clients that rely on EAP-AKA authentication do not send the EAP_ONLY_AUTHENTICATION notification payload to the responder despite that RFC 5998 so requires in order to avoid the need to exchange certificates.

Many?  From different vendors?  Maybe they actually do expect that the
gateway authenticates with a certificate first (i.e. they don't really
want to use EAP-only authentication)?  What happens if the gateway
actually authenticates with a certificate, do the clients fail?

> In particular, I have seen this behaviour in commercially available mobile phones from major brands.

Did you contact them and ask why that's the case?  Do they consider it a
bug?  Or is this according to some incorrect 3GPP specification?

> Basically, the extended feature makes strongSwan act as if the phone client (initiator) had indeed sent an EAP_ONLY_AUTHENTICATION payload in its IKE_AUTH MID=01 Initiator Request message. 

I guess we can add something like that.  There already are similar
overrides.  However, I don't like the name of the option much (something
like use_eap_only_authentication_without_notify or perhaps simply
force_eap_only_authentication might be better).

> I included the MIT X11 license text in the patch (I agree to those conditions) but leave it to the strongSwan maintainers to judge if my contribution is non-trivial or not if/when merging my patch into master =o)

Yeah, I'd say it's rather trivial (in particular with some
simplifications) so the header is not required.  I've pushed an
alternative patch to the eap-only-auth branch.  Let me know if that's OK
for you.


More information about the Dev mailing list