TLS User Mapping Extension
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
updates
- rfc-4346 — The Transport Layer Security (TLS) Protocol Version 1.1
Extracted elements (20)
The mapping data is placed in a SupplementalData handshake message rather than in the client hello extension itself, to prevent broadcasting the sensitive user mapping information to servers that do not understand the extension.
The UPN domain hint was introduced to allow a single certificate to be mapped to one or more user accounts without requiring a proprietary UPN in the certificate, addressing drawbacks of Microsoft's legacy approach that required UPN presence in the client certificate.
This document updates RFC 4346 (TLS 1.1). The user_mapping extension follows the convention from RFC 4366 where the server echoes the same extension type in the server hello to signal understanding; absence of the echo means the client ignores the extension and sends no UserMappingDataList.
Clients MUST include a user_mapping extension in the (extended) client hello to negotiate sending user mapping data, and the extension SHALL contain a list of supported hint types.
Clients SHOULD only send user mapping hints if they recognize the server as a legitimate recipient, to avoid superfluously broadcasting sensitive mapping data.
If the client sends more than one user mapping hint, the server SHOULD use the applicable mapping supported by the server. No preference is given to the order in which hints are specified in the UserMappingDataList vector.
The domain_name field in UpnDomainHint is an IDN-unaware domain name slot; domain names containing non-ASCII characters MUST be processed per RFC 3490 (IDNA) before being stored in this field.
The list of hint types in the server hello's UserMappingTypeList SHALL be either equal to or a subset of the list provided by the client. If none of the client's hint types are supported, the server SHALL omit the user_mapping extension in the server hello.
The server MUST expect and gracefully handle the case where the client chooses not to send any supplementalData handshake message even after successful negotiation of the user_mapping extension.
The UpnDomainHint MUST contain at least a non-empty user_principal_name or a non-empty domain_name; it MAY contain both.
The user mapping hint (UserMappingDataList) MUST NOT be treated as a trusted identifier. Authentication MUST rely solely on validation of the client certificate.
A new TLS extension type user_mapping(6) is added to the ExtensionType enumeration, used in both client hello and server hello messages. The extension_data field SHALL contain a UserMappingTypeList listing supported hint types.
IANA created an entry user_mapping(6) in the existing ExtensionType registry (RFC 4366), an entry user_mapping_data(0) in the SupplementalDataType registry (RFC 4680), and established a new TLS UserMappingType registry with upn_domain_hint(64) as the first entry.
TLS UserMappingType value ranges: 0-63 are assigned via Standards Action; 64-223 via Specification Required (with upn_domain_hint at 64); 224-255 are reserved for Private Use.
The user mapping hint may itself be regarded as sensitive information. The double handshake technique described in RFC 4680 can be used to protect the user mapping hint from eavesdroppers.
The UserMappingDataList is unauthenticated; authentication must rely solely on the client certificate. One recommended approach is to use the hint to locate the claimed user's certificate in a trusted directory and match it against the validated TLS client certificate.
After the client and server exchange hello messages including user_mapping extensions, the client MAY send a SupplementalData message with UserMappingDataList before the Certificate message. If the server does not echo the extension, the client proceeds normally without sending the UserMappingDataList.
UpnDomainHint carries two opaque variable-length fields: user_principal_name<0..2^16-1> and domain_name<0..2^16-1>. The user_principal_name, when present, MUST be of the form 'user@domain' with a UTF-8 encoded Unicode user part.
UserMappingDataList is a vector of UserMappingData structures (`user_mapping_data_list<1..2^16-1>`), each containing a UserMappingType, a uint16 length field, and type-selected data. The SupplementalDataType enumeration defines user_mapping_data(0).
UserMappingTypeList encodes a variable-length list of UserMappingType values: `struct { UserMappingType user_mapping_types<1..2^8-1>; }`. The list in a client hello signals supported hint types; in a server hello it signals preferred hint types.