Paul Wouters writes: > >> 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 :)
I think it does. See below > > 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. Ok. > > 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) So how does they manage to send CERTREQ having hash in them matching your trust anchor, if they have not been configured with that trust anchor? If you have manually configured them to send CERTREQs with trust anchor hashes you do not trust, then I think that is configuration error and it must be fixed. I.e. if you see CERTREQ which has hash matching the trust anchor that signed your certificate, then you can quite safely assume that the other end do support certificates, and has the required trust anchor installed, so you can always use the certificate based authentication yourself. This will cause you to favor certificate based authentications over auth null if it is possible. If remote end sends empty CERTREQ, then fix the configuration in the other end so it will include the hashes of the trust anchors instead. It should be easier to do that, than to implement new protocol... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
