On Thu, 19 Jul 2018, Tero Kivinen wrote:
Paul Wouters writes:
So we have the following possibilities:
1) authby=authnull -> authby=authnull
2) authby=authnull,cert -> authby=authnull
3) authby=authnull,cert -> authby=authnull,cert (must yield real
authentication)
4) authby=authnull -> authby=authnull,cert
Actually all of those (including the last one) are just authnull
always. If you do not require authentication then Man in the middle
attacker can just modify the exchange so that authnull is only one
offered.
You can prefer authentication over unauthenticated. You could do
different things. But yes, this is a migration path that mostly
avoids some kind of flag day or a rollout where one non-updated
node prevents all the network from using authenticated communication.
1 and 5 are existing known working deployments.
And 2-4 are exactly same as 1 from security point of view.
No, a cert-cert connection is still proving there is no MITM :P
Note, that you can already do this in standardized ways by using
multiple authentications RFC 4739. I.e., initially do normal authnull
and include MULTIPLE_AUTH_SUPPORTED in IKE_SA_INIT response and 1st
IKE_AUTH request. If both included it, then you know they have
certificates, thus you can do 2nd round of authentication by adding
ANOTHER_AUTH_FOLLOWS too to the 1st IKE_AUTH request.
Then you do 2nd IKE_AUTH exchange which does the certificate based
authentication.
I guess we did not support that, but it is a fair point.
2) Are we correct with our assumption that you either end up on mutual
authnull or with mutual authentication, or do people believe there
is a use case for asymmetric authentication as well, in which case
the responder could also send AUTH plus N(AUTHNULL)
Actually doesn't that automatically already happen with authnull? I
mean authentication can be asymmetric, i.e., one end can use
pre-shared keys and another certificates, and I think authnull also
allows that, i.e., responder can use certificates to authenticate
himself and initiator can use authnull. At least Introduction section
lists all those asymmetric cases as uses cases for NULL auth.
That doesn't end up favouring authenticated over authnull. See above
disagreement that this matters :)
Are the certificates signed by known trust anchor, and is that trust
anchor already configured in all nodes initially?
No. Some nodes still have no certificates whatsoever, and some nodes
have been updated to have certificates.
On the other hand if you have not trust anchors installed and you need
to find that out during the handshake, you can use the fact whether
you get CERTREQs in the exchange to indicate that other end has proper
trust anchors installed, and if you do not get trust anchors mathing
your certificate from the other you use NULL auth, and if you do get
matching trust anchors and you have certificate, then you use
signatures.
Some implementations always send CERTREQs even if they only allow PSK,
in case the other end wants to use CERT based auth while this end
uses something else (eg psk or null)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
