TLS Handshake Message for Supplemental Data
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org> Subject: Protocol Action: 'TLS User Mapping Extension' to Proposed Standard The IESG has approved the following documents: - 'TLS User Mapping Extension ' <draft-santesson-tls-ume-08.txt> as a Proposed Standard - 'TLS Handshake Message for Supplemental Data ' <draft-santesson-tls-supp-03.txt> as a Proposed Standard These documents have been reviewed in the IETF but are not the products of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-08.txt
Technical Summary The TLS User Mapping extension enables a client to send a name hint to a server during a TLS handshake, enabling the server to locate necessary authentication credentials, such as X.509 certificates, for the claimed user. This aims to solve two issues: 1) To enable use of legacy PKI implementations where existing certificates lack a name that unambiguously maps to the user account at the server. 2) Allow a user to use the same certificate to authenticate to multiple accounts, while still being able to specify which account the user intends to employ for a particular TLS session. In the case of allowing legacy PKI, the user mapping hint provide information that can be used by the server to retrieve any necessary data, including certificates, to authenticate the user. The proposed TLS protocol extensions allow additional user mapping hint types to be defined in the future. The basic hint type allows either a UPN (Universal Principal Name) or a DNS hint to be sent to the server. The UPN hint enables authentication to a Microsoft domain account using existing PKI deployments. Without this TLS protocol extension, the client certificate must contain a UPN name in the form of the Microsoft UPN otherName in the Subject Alternative Name extension. Working Group Summary This document is an individual submission. However, the draft was announced to the TLS WG, and it was presented at the TLS WG session during IETF 64 in Vancouver. Comments received from WG participants were addressed. After resolving these comments, no further objections were raised. Protocol Quality This TLS protocol extension is being implemented by Microsoft in Windows Vista. It is expected to be used by enterprise customers with PKI deployments. In fact, the development of this TLS protocol extension is a direct result of requirements raised from the user community. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor Please update the end of the 3rd paragraph of Section 1 in draft-santesson-tls-ume: OLD: The TLS extension in combination with the defined hint type provide a significant improvement to this situation as it allows a single certificate to be mapped to one or more accounts of the user and does not require the certificate to contain a UPN. NEW: The TLS extension in combination with the defined hint type provide a significant improvement to this situation as it allows a single certificate to be mapped to one or more accounts of the user and does not require the certificate to contain a proprietary UPN.