On Fri, Jun 26, 2020 at 04:40:53PM +0300, Tero Kivinen wrote:
> 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...
I hope -25 captures this accordingly.
Signalling of TA certificates may not be appropriate when the
deployment is relying on a security model where the TA certificate
content is considered confidential and only its hash is appropriate
for signalling. ACP nodes SHOULD have a mechanism to select whether
the TA certificate is signalled or not. Assuming that both options
are possible with a specific secure channel protocol.
Btw: i have not heard an explanation why a CA cert would have to
be secret other than the classic "security by secrecy" dogma.
Do you have an actual example why a CA cert would need to be kept secret ?
I can only think of something like oh, the Coca Cola Root Certificate
having the Coca Cola recipe in one of its fields as a human proof
of authenticity of the certificate. But i can't imagine a ral
case where this has been done. Although it sounds like a fun idea
to be able to claim in court that a cert was creted by a holder of
a particular non-cypto secret. Alas, that claim would then mean
you would hve to reveal that non-crypto secret to court.
In any case: If there is an actual crypto root CA in a company,
you can always create a non-secret TA as a subCA without any of the
secret information in the rootCA. IMHO!
> > 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".
Of course not, but it is a lot easier to put diagnostic information
into the root-CA that you may actually have manually crafted
instead of the automatically enrolled EE or even potentially also
automatically created intermediate CA certs. Like rfc822Name
addresses of actual human contacts.
> 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, there are no mandates whatsoever for any form of transparency
to support diagnostics. The goal of the technology choices made is to
support diagnostics if so desired by the operator deploying the
solution. Mandating any level of transparency is beyond the reach
of this spec.
> 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.
Yepp. As i said in before, as much as i like to do as much for
diagnostics in ACP as possible, i will not be the one asking for
anything new to be put into ACP, because the whole IETF/IESG review
goes on for years already, so it needs to finish so we can work on
all those additional good ideas via followup documents.
>
> 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.
Sure. But i still fail to see an example where this would be really helpfull.
I get the idea, but the root problem is that a particular IPsec
session is opened by the initiator for a particular functional
purpose. Different VPNs, different ACP, etc. pp. As soon
as the certificates for different purposes where derived
from overlapping TA, CERTREQ does not help to identify the
purpose. And IPsec implementations are prone to not
support binding to different UDP ports for different purposes,
so there are always workarounds needed to support multiple
purposes on the same device simultaneously.
> Creating a mapping from trust anchor hash to trust anchor is trivial
> if you ever see the actual trust anchor certificate anywhere.
Sure. You just need to have seen the actul trust anchor cert once.
> If you ever have more than one TA ever in normal operations you want
> to mandate sending CERTREQs always.
See above. To actually ensure that the other sides cert chain
is signalled even when connection fails (for diagnosstics),
the certreq must be ignored, which is fine, but given how it
was also not helpfull (IMHO) to determine the purpose and hence
valid TA in the first place, i consider it to be a well
meaning but not useful option.
But always happy to hear solutions that would only work when it is used.
> 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.
yepp. i think i understand how it works.
> 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.
Sure. actually the more common case. Albeit also one that i think
should be avoided as much as possible because it just creates
additional compllexity / third party dependencies. TO me its just
an optimization when there are lots of possible TA (whole set of
web CA for example), or a lot of connections for which setup is to
be optimized.
> 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.
yepp.
> 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".
Hah. Ok, so this is an interesting point. I didn't try to
understand this part so far and was just taking in the advice
to use the ID_IPV6_ADDR from the certs ACP domain informatin field
The more complete ID would have actually been the complete
ACP domain information field, which would be possible too because
IKEv2 also supports ID_RFC822_ADDR, which is the forward we have
for the domain information field. Alas, there are IMHO unjustified
dogmatic concerns about using rfc822addr at all, so it wouldn't
really help to suggest using this also as the ID in IKEv2 for
our case - however logical and iseful IMHO that would be.
Are there actual configs in typical IKEv2 implementations
that would allow to tie policies to flexibly matched peer
identifies. And by that i men not IPv4/IPv6 peer identities
but any of the other identitites, all of which are more
descriptive than IPv4/IPv6. ??
> 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.
Agreed. But see above, this was at least from my side the
intent anyhow (allow CA certs to have diagnostic info).
> 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...
Yes. Good point to explicitly indicate that signaling TA
is only more useful than not when it has additional
useful diagnostics, sch as e.g.: contact person email or the like.
Cheers
Toerless
> --
> kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
