We had to support the following deployment.
A large group of nodes is deployed with mutual authnull. This
offers passive attack protection on the network. At a later
stage, nodes are given their certificate for authentication.
The goal was to go from mutual authnull to mutual RSA. If either
node does not yet support authentication, both nodes use auth null.
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
When all nodes have gotten a cert, you can remove authnull so end up with:
5) authby=cert -> authby=cert
1 and 5 are existing known working deployments.
2-4 have a scenario where you have to pick an IKE_AUTH method. Depending
on the responder you got it right or wrong. If wrong, you have to
restart IKE_INIT to try the other method. We wanted to do this IKE_AUTH
in 1 roundtrip without a restart of IKE_INIT.
Note all these scenarions yield a symmetric authentication. It will be
either authnull or mutual "real" authentication (eg RSA or DigitalSignature)
So what we ended up doing is similar to the NO_PPK_AUTH trick. We added
sending a notify N(AUTHNULL) (40960 private use number) to the IKE_AUTH
exchange on the initiator which is a notify containing an AUTH payload
using authnull. So this becomes:
request --> IDi, [CERT+,]
[N(INITIAL_CONTACT),]
[N(AUTHNULL)] <----- New item
[[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
[IDr,]
AUTH,
[CP(CFG_REQUEST),]
[N(IPCOMP_SUPPORTED)+,]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, TSi, TSr,
[V+][N+]
The IKE_AUTH response is unmodified.
If the responder supports this payload, AND local policy can do
authentication, it will ignore this payload and use the regular AUTH
payload. If it only has a configuration for authnull, it will use the
N(AUTHNULL) as the received AUTH payload instead or the actual AUTH
payload. The responder will send back only a real AUTH payload. If the
initiator had N(AUTHNULL) but the responder can do regular authentication,
it will just send back an real authentication AUTH payload. If the
responder can only do authnull, it will send an authnull based AUTH
payload. The responder never sends a N(AUTHNULL) payload as we did
not need/want to support asymmetrical authentication where one part
is authnull and the other is not, as we either have a CA+EE cert for
ourselves AND the peer, or we only have authnull for everything.
See our test cases:
http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-03-authanon-anon/
http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-02-anon-authanon/
http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-01-authanon-authanon/
My questions are:
1) Is this useful enough to write up as RFC ?
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)
Paul and Vukasin
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
