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

[Thomas Strangert (Emblasoft)]

Hi Tobias,

> 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?

I've seen this not only from different phone vendors and phone models, but 
also that different responder servers at different operators isn't interested in
certs - or even offering to send any certs to the initiator/phone side.
(Tested by flipping it and configuring strongSwan as the initiator.)

The way IKEv2/IPsec is used in "my business", EAP-AKA is a must and nobody
really cares about the certs. If anything those would only be a nuisance to 
administer and to provision to users (SIM cards). Nightmare if a cert chain 
would expire and people's SIM cards would stop working. 

The phone manufacturers that I've had contact with (and have configuration
questionnaires from) doesn't even bother to ask about cert configurations.

Having said that, I don't really see the reason why RFC 5998 is violated, it
wouldn't "cost" anything to follow it. As regards to 3GPP, they actually 
talk about certs and that those *should* be signed (and *could* be signed 
by a trusted 3rd party/commercial CA). 

> > 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.

I have tested your branch and it worked as expected, from the logfile: 
Apr  8 12:00:29.440 10[IKE] <test|1> ignore missing EAP_ONLY_AUTHENTICATION notify and use EAP-only authentication 
I don't have any particular opinion about the name of the option key, 
it's best you decide so it goes in line with similar override options. 

One thing though that I noticed now when I compiled the branch was 
that it doesn't compile on (a fully updated) CentOS 7.7 any longer.
(Your branch sits on top of v5.8.4 instead of v5.8.2 that I compiled my 
own branch with.) After a bit of investigation I found that CentOS 7 
only has pkgconfig-0.27 and 0.28 is needed for the macro 
"PKG_CHECK_VAR" you use in configure.ac since the commit for 
"charon-nm: Use better default directory for D-Bus policy file" 
cfed3a87ee2072c772b0a18b2aac865590d1df4e
Would it be possible to reconsider using that macro? It's only used 
in that one place. (I modified configure.ac to use the default value 
[dbusdatadir="${datarootdir}"] instead of having the macro there.)

> Regards,
> Tobias

Thank you!
Thomas