On Fri, Jun 19, 2020 at 01:10:37PM -0400, Paul Wouters wrote:
> > 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.
For use across ACP, all nodes MUST have the same set of TA to mutually
authenticate each other, so CERTREQ would not make sense. I am just
trying to figure out the prior suggestions on this thread by Michael et. al.
that we should use CERTREQ, but have a hard time figuring out why.
What i thought to understand is this:
Responder has a lot of different set of TA, but only one of them
for use with ACP. These sets MAY have common TA. How should the
responder select which cert to send back to initiator.
CERTREQ from the initiator would help if the set of ACP TA is
disjoint from the TA used for other IKEv2 uses on the responder.
But that may not be the case.
Aka: I think i will not bother with CERTREQ unless someone gives me
a fully worked out suggestion how to use it beneficially. But i
think i will keep the text saying that IKEv2 for ACP needs to
run on a transport endpoint where ONLY use of ACP certificate
and TA is assumed.
> 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?
See above. I am inclinded to completely remove the sugestion to
use CERTREQ.
> > 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.
Ok. Then i will keep that text and check where to put the
discussion about the confidentiality of root CA problem.
> 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.
Sure.
> 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.
Normally yes. But when you have M&A (Mergers and Aquisitions) you
would need to support multiple TA, but you would only send the TA cert
from which your own cert is derived. Thats sufficient for
troubleshooting.
Thanks!
Toerless
> Paul
--
---
t...@cs.fau.de
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
