The IESG has approved the following document: - 'Exported Authenticators in TLS' (draft-ietf-tls-exported-authenticator-15.txt) as Proposed Standard
This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ Technical Summary This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. Working Group Summary As further background, 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 alternativ e 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. The document author 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. 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. [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 Document Quality EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. See [2] for formal security reviews. Personnel Sean Turner is the document shepherd Roman Danyliw is the responsible AD. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
