datatracker.ietf.org
Sign in
Version 5.6.3, 2014-09-19
Report a bug

TLS User Mapping Extension
RFC 4681

Document type: RFC - Proposed Standard (October 2006; No errata)
Updates RFC 4346
Was draft-santesson-tls-ume (individual in sec area)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4681 (Proposed Standard)
Responsible AD: Russ Housley
Send notices to: stefans@microsoft.com

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.

[include full document text]