Summary
Sean Turner is the DS.
Ben Kaduk is the responsible AD.
Exported Authenticators (EAs) provide a way for endpoints of a TLS connection
to prove ownership over multiple identities (certificates) outside of TLS.
Endpoints can export authenticators to applications for transmission and
verification. Mechanically, authenticators mirror certificate proofs in the TLS
handshake, i.e., triggered by an authenticator (certificate) request, an
endpoint can provide an authenticator response comprised of a certificate,
signature, and enveloping MAC (Certificate, CertificateVerify, and Finished).
Endpoints may encode requests and responses using standard TLS encoding rules
for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and
CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed
using keys exported from the underlying TLS connection, which means that
authenticators are only useful to endpoints party to that keying material. As
an authentication mechanism, EAs provide an alternative to post-handshake
client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the
extended master secret extension). Moreover, unlike Token Binding, which is
negotiated via an extension, there is little risk of endpoint
non-interoperatbility due to non-compliant or extension-stripping middle boxes.
EAs received formal security review from Cas Cremers and Jonathan Hoyland [2]
(which in turn led to followup work in [3]). EAs guarantee compound
authentication, i.e., proof of multiple separate identities, bound to a single
TLS connection against an attacker without access to certificate private keys
or TLS secrets.
The intended status is Standards Track, given its use for HTTP/2 Secondary
Certificates [1]. The document has received ample review from the WG members,
as well as discussion in the httpbis working group with respect to its use in
Secondary Certificates.
Review and Consensus
Nick presented the document several times to the WG. Over 50 emails were
exchanged on the draft during its lifecycle in the WG. The group waited to move
to WGLC until the security review [2] was complete. The document went through
three WGLCs, with the first leading to non-trivial changes in the document
before completion. (Some editorial, and some content changes that came out of
the security review.) There were no objections or blocking issues during the
second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir
review that returned the draft to the WG.
Intellectual Property
The DS confirmed with the author that any IPR related to this document has
already been disclosed, in conformance with BCPs 78 and 79.
Other Considerations
EAs have been implemented by at least two independent parties. To the best of
our knowledge, no browser has yet implemented the mechanism yet.
[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03
[2]
https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf
[3]
https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00