Michael Richardson writes: > Unless we can convince various people otherwise, the TA will all be > private enterprise/ISP CAs.
And for some reason those same private enterprise/ISP people are exactly those who say that we can't leak our CA certificates out, and thats why we can't have publicly available repository of our certificates or CAs, which of course lead to problem if you mandate sending that private information whoever ever wants to ask it... > > The reason sending hashes and not the root CA's is that it becomes very > > easy to determine which CA's a particulat client supports. I know that > > is elpful to troubleshooting, but it was deemed a security/privacy > > issue. > > We are not dealing with "clients", because this is not a remote access > scenario. Nor are these system visible in any way to the Internet. > "Physical" connectivity is required. (In quotes, because microwaves, > satellite systems and other layer-2 transmission media) > > This is an overlay network of ISP routers that use IPsec over IPv6 > **Link-Layer** addresses. The privacy considerations are significantly > different, while the need to do troubleshooting significantly higher. Ok, that clarifies some things. > Sending the *complete* trust chain solves the problem, and should > never cause a problem to any properly implemented daemon/certificate > chain validator. That might not solve anything even when you send the final TA. It does not really help when you get TA which has Subject name of "CN=Root", and Issuer name of "CN=Root". There is still no information where to go to find out who is the owner of the TA. If those are private TAs created by private enterprises/ISPs there is no guarantee that the TA itself has anything useful in it that allows you to identify who created it. This is especially true if the certificate hiearchy is created automatically by the vendor software without any actual user interaction. Yes, the TA might have something useful but it might not. On the other hand the Identity the other end sent might also have something useful or might not. If we look at different information available during IKEv2 negotiation to the endpoint of the exchange. During IKE_SA_INIT we might have Vendor IDs indicating the vendor of the implementation. This usually is hash of something, and it is always priprietary format, meaning you can recognize familiar vendors (i.e., you can map vendor you have seen before to vendor ID it sent before), but you cannot map random vendor ID to vendor. Anyways this might give you some debugging information. Then we have CERTREQ from the responder, i.e., we know which trust anchors it trusts, and we get hash of those keys it trust. The main idea there is to allow initiator to select one of the certificates he has in such way that he proposes certificate signed by one of those trust anchors. As both ends are supposed to be configured with trust anchors which they trust in, and from which they have certificates from, they can map this hash to actual trust anchor without any problems. Creating a mapping from trust anchor hash to trust anchor is trivial if you ever see the actual trust anchor certificate anywhere. If you ever have more than one TA ever in normal operations you want to mandate sending CERTREQs always. In the IKE_AUTH you have CERTREQ from the initiator, containing all of the trust anchors from the initiator, even when it used certificate from the only one of them. This allows responder to use different trust anchor when responding, i.e., initiator might use TA1, and responder might use TA2, but both trust in both TA1, and TA2, but they just happen to have certificates from different TAs. In addition to that there is CERT from to initiator, if initiator does not already know that the responder has its certificate. In some setups the TA hierarchy is properly made and each peer can find certificates from somewhere else, and there is no need to send them inside IKEv2 at all. In most common case you always send end entity certificate inside the IKE_AUTH so other end can verify it against its TA and match it against the identity. Note, that the certificate itself include Subject Name telling who this certificate was created for, and Issure Name telling who signed it. If the certificate hierarchy and names in the hierarchy are properly set there is no need to send TA. If the Subject name is "CN=device1, OU=HR Department, O=Example Inc, C=US", and the Issuer name is "CN=Root TA 2020, O=Example Inc, C=US", that already gives you all information you need to find out who is the owner of the cert. If the names are stupid like Subject name of "CN=device1231", and Issuer Name of "CN=Root" that does not help to get TA, as the TA again just have both Issuer Name and Subject Name of "CN=Root" which does not help you. Then there is still the IDi and IDr identities, those tell the identity of the peer. Depending on what identities are in use they might be very useful for debugging (like "devi...@hr.example.com" and "v...@example.com") or they might be completely useless like "10.5.0.1" and "10.1.0.1". Anyways sending TA only helps at all if the one who created the TA actually put some useful information in there, and if he did that, then the same information is already in the EE, thus seeing the TA does not really help. I would just put suggestion saying that whoever is creating those certificate hierarhies, they should use proper naming and include the name of the company etc in the Subject name of the certificates... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
