On Fri, 19 Jun 2020, 'Toerless Eckert' wrote:
Michael Richardson was suggesting to include the cert of the TA into the IKEv2 certificate exchange. This was rejected by Valery/Paul and the suggestion was to use CERTREQ instead.
Normally, you do not include the TA itself, only intermediate root's and the EE-cert. The CERTREQ contains the hashes of _all_ trust anchors supported by that party, not just the one it is thinking of using right now with the exchange in progress.
In my reading of CERTREQ, it would not help in this situation, because the hash of an unknown TA does not progress the troubleshooting much as there is in general no offline way to resolve it. In addition, that hash would AFAIK already be available from the Signature of the cert (chain) received from the peer.
Basically, in IKE_SA_INIT, before the IKE_AUTH and CERT payloads exchange, you exchange CERTREQ. You basically give a somewhat anonymised list of trust anchors you support. The initiator can loop through its known TA's and if it matches one, pick the proper certificate if there is one for that TA. 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.
CERTREQ seems to only help the peer to select the right Cert (chain) to send back in case it has multiple, but not to learn the peers TA details when there is no match. Pls correct me if i am wrong.
That is correct.
So i am tentatively adding the following text: <t>CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer in selecting the ACP certificate in case it has certificates also from other TA. It is RECOMMENDED for IKEv2 to be set up such that it will only use the ACP certificate/TA when acting as a responder on the transport endpoints indicated in DULL GRASP for the ACP.</t>
I'm not sure how much of your protocol involves talking to different parties that might have to install each others root CAs. Usually, either everyone shares the same (private) root CA because the root CA is an enterprise wide trust anchor, or if the connection is between two enterprises that are independent, administrators use PSK because neither one wants to trust a root CA maintained by the other. So the problem you describe hardly happens. But I'm not familiar with your uses cases.
Let me know if there is something wrong with this.
I would not say MUST. If both parties know they have the same root CA installed, the IKEv2 protocol does not require you send that Root CA hashed in a CERTREQ. SHOULD would be better here?
Nevertheless, this does not solve the original troubleshooting issue Michael wanted to resolve. From what i figure i can only write text that IKEv2 does not support this troubleshooting and that instead this should be solved by adding diagnostics information, such as the TA certificate to DULL GRASP (but that would be for future work). Let me know if you can think of a way to "legally" send the full certificate of the TA during IKEv2 exchanges.
Nothing prevents you from including the root CA (TA) in the CERT payload. It is perfectly valid. There is a privacy/security risk of revealing the root your trust. But that's your risk to evaluate. If you want to convey you are trusting many roots, then CERTREQ is the better place. You dont want to send 150+ root CAs over IKE. Presumbly, since you have 1 configured EE-cert to use for this connection, it will chain back to one intermediate/root CA ? That's the one you can just send as part of the CERT payload. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
