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

Tobias Brunner tobias at strongswan.org
Wed Apr 8 17:49:59 CEST 2020


Hi Thomas,

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

So these servers all do EAP-AKA without public key authentication of the
server even if the notify is not received?

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

You'd only need a PKI/certificate to authenticate the servers, not the
clients (they do have to trust the respective CA certs but those would
probably not be stored on the SIM cards).

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

I see.

> Having said that, I don't really see the reason why RFC 5998 is violated, it
> wouldn't "cost" anything to follow it.

Agreed.

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

In relation to EAP-AKA?  Or as an alternative means to authenticate
client and server?

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

OK, thanks for testing.

> Would it be possible to reconsider using that macro?
No, not really.  pkg-config 0.28 was released in January 2013, CentOS 7
in July 2014, so no idea why they would still ship 0.27.  And it's
really only needed when building from the repository (i.e. to generate
the configure script) not when building from a tarball, which can always
be created on a newer system in order to build on such older ones.

Regards,
Tobias


More information about the Dev mailing list