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

[Thomas Strangert (Emblasoft)]

> 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.
> 
> 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?
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 
until then. 

> Regards,
> Tobias

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!