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. Regards, Tobias
