In ACP, we use IKEv2 between peers without assumed methods to retrieve
certificates from "external" sources like http repositories. And CA most
likely will have non-public Trust Anchor (TA) (enterptrise PKI).
Imagine a large multi-tenant network infrastructure (office building,
skyscraper)
where each tenant runs their own network. It is easy to see how ACP nodes
can be misplugged and unintentionally connect to a different tenants ACP
node, or more likely, or where the building owner has not updated the
L2 segmentation of the office areas according to tenancy. In this case the
TA will not match, but the problem is how help troubleshoot the problem
by being able to identify which other tenants (PKI) is on the other
side of a non-working ACP connection.
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.
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. 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.
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>
Let me know if there is something wrong with this.
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.
Thanks
Toerless
On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote:
> > > 2. If certificate chains are used, all intermediate certificates up to,
> > > and including the locally provisioned trust anchor certificate MUST
> > > be signaled. See Section 6.10.7 for the sub-CA example in which
> > > certificate chains are used.
> > >
> > > This is confusing. I read this text as the ???MUST??? is imposed only
> > > if
> > > ???certificate chains are used???. Does it mean that implementations
> > > may skip this ???MUST??? if EE certificate is directly signed by CA
> > > certificate
> > > and there is no intermediate certificates? Or is it still a chain
> > > and ???if??? is relevant to the case when there is no CA and there is
> > > a direct trust to EE certificates
> > > (in which case PKI is not needed at all and you can use RAW public
> > > keys)?
> >
> > I agree it should not try to dictate how certificate based IKE
> > certification works, but just reference to IKEv2 and its updates for
> > that.
>
> That was my point :-)
>
> > > Another point: trust anchors certificates usually are not included
> > > in CERT payload in IKEv2.
> > > I see draft???s a reasoning that this inclusion would allow better
> > > network debugging,
> > > but I???m not sure I can buy this argument. Probably more detailed
> > > explanation is needed.
> >
> > They could suggest that for easier debuggint a CERTREQ payload is
> > included. That has the hash of the CA, which should be good enough.
> > But again, IKEv2 already specifies this. Why is this document trying
> > to change IKEv2 certificate processing?
>
> Agree.
>
> Regards,
> Valery.
>
> > Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
