Hi, sorry for late reply.
> 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 ? I still believe that sending additional AUTH information in N(AUTHNULL) (as well as in N(NO_PPK_AUTH)) is a protocol hack. The proper way is to add a generic mechanism that would allow peers to announce authentication algorithms they support. Note that no negotiation is needed - it is sufficient to announce a list of auth methods, as it is currently takes place with hash functions. The N(NO_PPK_AUTH) is a bit different, since it is not a new authentication method, it is a modification of existing methods, so the hack in this case is forgivable :-) That said, I agree with Tero that if you allow AUTH_NULL, then announcing in addition any other (real) auth methods can be done on attacker's mercy only, as she can always remove them and downgrade IKE SA to AUTH_NULL. > 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) I believe such use cases do have a right to exist. Regards, Valery. > Paul and Vukasin _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
