Network Working Group S. Santesson
Request for Comments: 4681 A. Medvinsky
Updates: 4346 J. Ball
Category: Standards Track Microsoft
October 2006
TLS User Mapping Extension
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a TLS extension that enables clients to send
generic user mapping hints in a supplemental data handshake message
defined in RFC 4680. One such mapping hint is defined in an
informative section, the UpnDomainHint, which may be used by a server
to locate a user in a directory database. Other mapping hints may be
defined in other documents in the future.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Design Considerations ......................................2
2. User Mapping Extension ..........................................3
3. User Mapping Handshake Exchange .................................3
4. Message Flow ....................................................5
5. Security Considerations .........................................6
6. UPN Domain Hint (Informative) ...................................7
7. IANA Considerations .............................................8
8. Normative References ............................................9
9. Acknowledgements ................................................9
Santesson, et al. Standards Track [Page 1]
RFC 4681 TLS User Mapping Extension October 2006
1. Introduction
This document has a normative part and an informative part. Sections
2-5 are normative. Section 6 is informative.
This specification defines a TLS extension and a payload for the
SupplementalData handshake message, defined in RFC 4680 [N6], to
accommodate mapping of users to their user accounts when using TLS
client authentication as the authentication method.
The new TLS extension (user_mapping) is sent in the client hello
message. Per convention defined in RFC 4366 [N4], the server places
the same extension (user_mapping) in the server hello message, to
inform the client that the server understands this extension. If the
server does not understand the extension, it will respond with a
server hello omitting this extension, and the client will proceed as
normal, ignoring the extension, and not include the
UserMappingDataList data in the TLS handshake.
If the new extension is understood, the client will inject
UserMappingDataList data in the SupplementalData handshake message
prior to the Client's Certificate message. The server will then
parse this message, extracting the client's domain, and store it in
the context for use when mapping the certificate to the user's
directory account.
No other modifications to the protocol are required. The messages
are detailed in the following sections.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [N1].
The syntax for the TLS User Mapping extension is defined using the
TLS Presentation Language, which is specified in Section 4 of [N2].
1.2. Design Considerations
The reason the mapping data itself is not placed in the extension
portion of the client hello is to prevent broadcasting this
information to servers that don't understand the extension.
Santesson, et al. Standards Track [Page 2]
RFC 4681 TLS User Mapping Extension October 2006
2. User Mapping Extension
A new extension type (user_mapping(6)) is added to the Extension used
in both the client hello and server hello messages. The extension
type is specified as follows.
datatracker.ietf.org