Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

Hi Ryan!

Thank you for taking the time to review and comment!
A few thoughts to your comments -

IssuerAndSerialNumber was chosen because it was small (< 1KB) and we figured it was something an endpoint would already know how to construct. Hash of entire certificate would also work, and something an endpoint would also already know how to do.

Regarding the example you described, perhaps we need more clarity on the issue you have raised! The extension merely provides a hint to the peer that a certificate listed in the extension is owned by the same entity that provided the cert. A peer using non-composite hybrid auth provides two certificates for use in authentication, and if one includes the BoundCertificates extension, the protocol should check that it appropriately names the other cert provided- however, both certificates would still go through the normal validation process before communication is considered authenticated.

There is no presumption that all certificates are issued within the same PKI. There is a presumption that the endpoint will not accept certificates that it doesn't have a trust anchor for. This mechanism probably doesn't work well for endpoints with liberal trust anchor inclusion policy.

Concerning renewal, each certificate is valid on its own. The newer certificate would only need renewal on the expiration of the older certificate if a relying party still needed what that older certificate represented. The extension is just a hint to relying party that some care has been taken during issuance that the new cert is being issued to the same entity as the old cert. It is no stronger a hint than any PKI the relying party dares to trust.

The goal of this draft is to aid in multiple authentication (particularly for PQ migration) by ensuring that all certificates provided by a peer for authentication purposes are in fact owned by the same entity.

Appreciate the feedback!
-Alie
________________________________
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Sent: Tuesday, March 22, 2022 7:11 PM
To: Alison Becker (GOV) <aebecke@uwe.nsa.gov>
Cc: spasm@ietf.org <spasm@ietf.org>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

Could you explain the rationale a bit more for the IssuerAndSerialNumber construction?

It won't necessarily unambiguously identify a certificate, in the absence of a global directory. Within a multi-stakeholder PKI (like those deployed on the Internet today), it's possible for two distinct entities to have the same encoded issuer value, but be in possession of distinct keys. The path algorithms involved in X.509 and PKIX are able to resolve this (by virtue of signature checking to resolve which issuing CA), which also applies to OCSP responses, but it seems like it wouldn't apply here.  Broadly, the assumption of X.509v3 that Issuer and Serial Number would be globally unique and unambiguous didn't hold, as previous communications in the IETF with the ITU revealed [1][2][3], and that Distinguished Names aren't, well, Distinguished. Is there reason not to use a stronger binding (e.g. the hash of the certificate being referenced)?

If two certificates, A and B, both identify the same Subject ("Subject Foo"), but with different keys and numbering schemes, it seems that if a bound certificate was issued to entity C, with IssuerAndSerial of "Subject Foo":1 (referring to A), that B could issue a malicious certificate bearing that same serial number, and have it be accepted as legitimate for C.

That said, I do feel I must be missing an important use case, because I'm not fully sure I see the utility in this. Is it fair to say that the assumption is that both certificates (the original and the bound certificate) are participants in the same PKI hierarchy and same set of PKI policies? If they weren't, it seems like the issuance of the BoundCertificate may introduce operational considerations for the renewal/replacement of the target/original certificate, in that replacement of the original would necessitate issuing a new bound certificate. Wouldn't that unintentionally affect the security considerations/agility of the target/original certificate, in unanticipated and perhaps harmful ways? Minimally, it seems such chains of binding would have to be ordered from "slowest to fastest to replace", to mitigate, and that seems like a relevant security consideration.

[1] https://www.ietf.org/proceedings/70/minutes/pkix.htm<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F70%2Fminutes%2Fpkix.htm&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TNI2q6HoF1jGtYBjJ7yi%2BK83wkvejqqFa1r2uMmWD4Q%3D&reserved=0>
[2] https://www.ietf.org/proceedings/70/slides/pkix-4.pdf<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F70%2Fslides%2Fpkix-4.pdf&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3KTtbo%2FlFN%2B7lOv14H%2F%2FKOATIGEtX7HY2nfcz43%2FwB0%3D&reserved=0>
[3] https://datatracker.ietf.org/liaison/375/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fliaison%2F375%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hGHr1zaIyMuWFk9N6v%2BsTLqo00a%2BiigjRX47%2B3GBk8U%3D&reserved=0>

On Tue, Mar 22, 2022 at 2:16 PM aebecke@uwe.nsa.gov<mailto:aebecke@uwe.nsa.gov> <aebecke=40uwe.nsa.gov@dmarc.ietf.org<mailto:40uwe.nsa.gov@dmarc.ietf.org>> wrote:
Hi LAMPS,

  Two new drafts related to PQ migration are available here (note- these drafts are an update to the talk we gave at IETF112 in November) : https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bx4qCS%2B5H%2FKRK331Uu47qRdT2oddFKt8dKLgP6x3bDU%3D&reserved=0> and https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-noncomposite-hybrid-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uNkGPxzPeJqsWpYDTHPotu4Iaq8Zm6FA3JDpTIk4gJ4%3D&reserved=0>

The noncomposite-hybrid-auth-00 draft is an informational draft that gives a general overview of hybrid authentication, and details the solution space of what we are calling non-composite type hybrid solutions for authentication.

The cert-binding-for-multi-auth-00 draft defines a new CSR attribute, bindingRequest, and a new X.509 certificate extension, BoundCertificates, which together provide additional assurance that multiple certificates (used in non-composite hybrid authentication) each belong to the same end entity.

  Please feel free to provide any comments and feedback!

  Regards,
  Alie Becker + coauthors Rebecca Guthrie, Mike Jenkins

  ----
  Alison Becker, PhD
  Center for Cybersecurity Standards
  National Security Agency
_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C1415fa5db4e5444470f008da0c595c4e%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637835875937999273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2YIar7Ut0i2WJk7zJB58BFix15e7PzSs9%2BE%2FYj90%2FmM%3D&reserved=0>