Paul Wouters <p...@nohats.ca> wrote:
> 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.
Unless we can convince various people otherwise, the TA will all be private
enterprise/ISP CAs.
> 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.
Sending the *complete* trust chain solves the problem, and should never cause a
problem to any properly implemented daemon/certificate chain validator.
> 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.
At private ISP peering points, at IXPs (until discovered and disabled), and
when cables and/or systems are mis-attached, the ACP may attempt to connect
across security boundaries. This is intended in almost all cases to fail.
Knowing what peers were rejected helps significantly in determining if some
cables were misconnected. Since a goal of the ACP work is to reduce the
expense (dollars and CO2 emissions) of deploying new network equipment, one
can expect that over time the quality of the "remote hands" will find a new
lower bound.
(While we conceive of inter-ISP secure channels that might require
cross-installation of trust anchors, those are just talk at this point)
> So the problem you describe hardly happens. But I'm not familiar with
> your uses cases.
....
> 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.
Good, we are in agreement here.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
