[strongSwan-dev] New feature extending support for RFC 5998 EAP-only authentication
Thomas Strangert (Emblasoft)
thomas.strangert at emblasoft.com
Wed Apr 8 18:42:09 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?
It's hard to be man-in-the-middle and see actual ping-pong between a
server "out there" and a phone client/initiator firmware. I have tested
being either side and tried to provoke / trigger various cert scenarios
and my findings are that both phones and servers are somewhere between
"permissive" and "doesn’t care" when it comes to certs and RFC 5998.
> > 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.
The CA cert needed to trust the server could be stored in the phone but then
the phone manufacturer needs to be involved and phones possibly need to be
updated in a way that the phone manufacturer doesn't want to bother with.
(They would also get the blame from users if the phone becomes unusable
if no longer getting FW updates.) If CA info is kept on the SIM, then both
ends of the connection is under the operator's control, but with increased
admin/provisioning work for them. Hence: Everyone rather skip certs.
> > 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).
> In relation to EAP-AKA? Or as an alternative means to authenticate client and
It's mentioned in relation with IKEv2 handshaking in general and server
authentication in particular, whereas the sections about user authentication
mentions EAP-AKA (and nothing about user-specific certs as a means to
authenticate a user with).
> > 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.
Wow. Old stuff, didn't check that. My question was since the macro was first
used by you only recently and since you apparently could do without it up
With that, I guess the feature request of mine at some point will merge
into an official release. Thank you.
Wish you a Happy Easter!
More information about the Dev