Add.

1 files changed, 728 insertions, 0 deletions

diff --git a/doc/protocol/draft-santesson-tls-ume-07.txt b/doc/protocol/draft-santesson-tls-ume-07.txt
new file mode 100644
index 0000000000..79b62409d6
--- /dev/null
+++ b/doc/protocol/draft-santesson-tls-ume-07.txt
@@ -0,0 +1,728 @@
+
+
+
+
+INTERNET-DRAFT                                  S. Santesson (Microsoft)
+Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
+Intended Category: Standards track                   J. Ball (Microsoft)
+Expires November 2006                                           May 2006
+
+
+                       TLS User Mapping Extension
+                    <draft-santesson-tls-ume-07.txt>
+
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+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 TBD. 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.
+
+   (NOTE TO RFC EDITOR:  Replace "RFC TBD" with the RFC number assigned
+   to draft-santesson-tls-supp-00.txt)
+
+
+
+
+
+
+Santesson, et. all                                              [Page 1]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+Table of Contents
+
+   1  Introduction ................................................    2
+   2  User mapping extension ......................................    3
+   3  User mapping handshake exchange .............................    4
+   4  Message flow ................................................    6
+   5  Security Considerations .....................................    8
+   6  UPN domain hint (Informative) ...............................    9
+   7  References ..................................................   10
+   8  IANA Considerations .........................................   10
+   Authors' Addresses .............................................   11
+   Acknowledgements ...............................................   11
+   Disclaimer .....................................................   12
+   Copyright Statement ............................................   12
+
+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 TBD [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",
+
+
+
+Santesson, et. all                                              [Page 2]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+   "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.
+
+
+2  User mapping extension
+
+   A new extension type (user_mapping(TBD)) is added to the Extension
+   used in both the client hello and server hello messages. The
+   extension type is specified as follows.
+
+
+      enum {
+           user_mapping(TBD), (65535)
+      } ExtensionType;
+
+   The "extension_data" field of this extension SHALL contain
+   "UserMappingTypeList" with a list of supported hint types where:
+
+      struct {
+            UserMappingType user_mapping_types<1..2^8-1>
+      } UserMappingTypeList;
+
+   Enumeration of hint types (user_mapping_types) defined in this
+   document is provided in section 3.
+
+   The list of user_mapping_types included in a client hello SHALL
+   signal the hint types supported by the client. The list of
+   user_mapping_types included in the server hello SHALL signal the hint
+   types preferred by the server.
+
+   If none of the hint types listed by the client is supported by the
+   server, the server SHALL omit the user_mapping extension in the
+   server hello.
+
+   When the user_mapping extension is included in the server hello, the
+   list of hint types in "UserMappingTypeList" SHALL be either equal to,
+   or a subset of, the list provided by the client.
+
+
+
+
+
+Santesson, et. all                                              [Page 3]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+3  User mapping handshake exchange
+
+   The underlying structure of the SupplementalData handshake message,
+   used to carry information defined in this section, is defined in RFC
+   TBD [N6].
+
+   A new SupplementalDataType [N6] is defined to accommodate
+   communication of generic user mapping data. See RFC 2246 (TLS 1.0)
+   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
+
+   The information in this data type carries one or more unauthenticated
+   hints, UserMappingDataList, inserted by the client side. Upon receipt
+   and successful completion of the TLS handshake, the server MAY use
+   this hint to locate the user's account from which user information
+   and credentials MAY be retrieved to support authentication based on
+   the client certificate.
+
+
+      struct {
+            SupplementalDataType supp_data_type;
+            select(SupplementalDataType) {
+               case user_mapping_data: UserMappingDataList;
+               }
+      } SupplementalDataEntry;
+
+      enum {
+            user_mapping_data(TBD), (65535)
+      } SupplementalDataType;
+
+
+   The user_mapping_data(TBD) enumeration results in a new supplemental
+   data type UserMappingDataList with the following structure:
+
+
+      enum {
+            (255)
+      } UserMappingType;
+
+      struct {
+             UserMappingType user_mapping_version
+             select(UserMappingType) { }
+      } UserMappingData;
+
+      struct{
+         UserMappingData user_mapping_data_list<1..2^16-1>;
+      }UserMappingDataList;
+
+
+
+
+
+Santesson, et. all                                              [Page 4]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+   The UserMappingData structure contains a single mapping of type
+   UserMappingType.  This structure can be leveraged to define new types
+   of user mapping hints in the future.  The UserMappingDataList MAY
+   carry multiple hints; it is defined as a vector of UserMappingData
+   structures.
+
+   No preference is given to the order in which hints are specified in
+   this vector.  If the client sends more then one hint then the Server
+   SHOULD use the applicable mapping supported by the server.
+
+   Implementations MAY support the UPN domain hint as specified in
+   section 6 of this document.  Implementations MAY also support other
+   user mapping types as they are defined.  Definitions of standards-
+   track user mapping types must include a discussion of
+   internationalization considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 5]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+4  Message flow
+
+   In order to negotiate to send user mapping data to a server in
+   accordance with this specification, clients MUST include an extension
+   of type "user_mapping" in the (extended) client hello, which SHALL
+   contain a list of supported hint types.
+
+   Servers that receive an extended client hello containing a
+   "user_mapping" extension, MAY indicate that they are willing to
+   accept user mapping data by including an extension of type
+   "user_mapping" in the (extended) server hello, which SHALL contain a
+   list of preferred hint types.
+
+   After negotiation of the use of user mapping has been successfully
+   completed (by exchanging hello messages including "user_mapping"
+   extensions), clients MAY send a "SupplementalData" message containing
+   the "UserMappingDataList" before the "Certificate" message. The
+   message flow is illustrated in Fig. 1 below.
+
+      Client                                               Server
+
+      ClientHello
+       /* with user_mapping ext */ -------->
+
+                                                      ServerHello
+                                      /* with user-mapping ext */
+                                                     Certificate*
+                                               ServerKeyExchange*
+                                              CertificateRequest*
+                                   <--------      ServerHelloDone
+
+      SupplementalData
+       /* with UserMappingDataList */
+      Certificate*
+      ClientKeyExchange
+      CertificateVerify*
+      [ChangeCipherSpec]
+      Finished                     -------->
+                                               [ChangeCipherSpec]
+                                   <--------             Finished
+      Application Data             <------->     Application Data
+
+             Fig. 1 - Message flow with user mapping data
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent according to RFC 2246 [N2] and RFC 4346 [N3].
+
+   The server MUST expect and gracefully handle the case where the
+
+
+
+Santesson, et. all                                              [Page 6]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+   client chooses to not send any supplementalData handshake message
+   even after successful negotiation of extensions. The client MAY at
+   its own discretion decide that the user mapping hint it initially
+   intended to send no longer is relevant for this session. One such
+   reason could be that the server certificate fails to meet certain
+   requirements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 7]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+5  Security Considerations
+
+   The user mapping hint sent in the UserMappingDataList is
+   unauthenticated data that MUST NOT be treated as a trusted
+   identifier. Authentication of the user represented by that user
+   mapping hint MUST rely solely on validation of the client
+   certificate. One way to do this is to use the user mapping hint to
+   locate and extract a certificate of the claimed user from the trusted
+   directory and subsequently match this certificate against the
+   validated client certificate from the TLS handshake.
+
+   As the client is the initiator of this TLS extension, it needs to
+   determine when it is appropriate to send the User Mapping
+   Information. It may not be prudent to broadcast a user mapping hint
+   to just any server at any time.
+
+   To avoid superfluously sending user mapping hints, clients SHOULD
+   only send this information if it recognizes the server as a
+   legitimate recipient. Recognition of the server can be done in many
+   ways. One way to do this could be to recognize the name and address
+   of the server.
+
+   In some cases, the user mapping hint may itself be regarded as
+   sensitive. In such case the double handshake technique described in
+   [N6] can be used to provide protection for the user mapping hint
+   information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 8]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+6  UPN domain hint (Informative)
+
+   This specification provides informative description of one user
+   mapping hint type for Domain Name hints and User Principal Name
+   hints. Other hint types may be defined in other documents in the
+   future.
+
+   The User Principal Name (UPN) in this hint type represents a name
+   which specifies a user's entry in a directory in the form
+   userName@domainName. Traditionally Microsoft has relied on such name
+   form to be present in the client certificate when logging on to a
+   domain account. This has however several drawbacks since it prevents
+   the use of certificates with an absent UPN and also requires re-
+   issuance of certificates or issuance of multiple certificates to
+   reflect account changes or creation of new accounts. 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.
+
+   The domain_name field MAY be used when only domain information is
+   needed, e.g. where a user have accounts in multiple domains using the
+   same username name, where that user name is known from another source
+   (e.g. from the client certificate). When the user name is also
+   needed, the user_principal_name field MAY be used to indicate both
+   username and domain name. If both fields are present, then the server
+   can make use of whichever one it chooses.
+
+
+      enum {
+             upn_domain_hint(64), (255)
+      } UserMappingType;
+
+      struct {
+             opaque user_principal_name<0..2^16-1>;
+             opaque domain_name<0..2^16-1>;
+      } UpnDomainHint;
+
+      struct {
+             UserMappingType user_mapping_version
+             select(UserMappingType) {
+                   case upn_domain_hint:
+                        UpnDomainHint;
+             }
+      } UserMappingData;
+
+
+
+
+
+
+Santesson, et. all                                              [Page 9]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+   The user_principal_name field, when specified, SHALL be of the form
+   "user@domain", where "user" is a UTF-8 encoded Unicode string that
+   does not contain the "@" character, and "domain" is a domain name
+   meeting the requirements in the following paragraph.
+
+   The domain_name field, when specified, SHALL contain a domain name in
+   the usual text form: in other words, a sequence of one or more domain
+   labels separated by ".", each domain label starting and ending with
+   an alphanumeric character and possibly also containing "-"
+   characters.  This field is an "IDN-unaware domain name slot" as
+   defined in RFC 3490 [N7] and therefore, domain names containing non-
+   ASCII characters have to be processed as described in RFC 3490 before
+   being stored in this field.
+
+   The UpnDomainHint MUST at least contain a non empty
+   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
+   contain both user_principal_name and domain_name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                             [Page 10]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+6 References
+
+   Normative references:
+
+   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
+             RFC 2246, January 1999.
+
+   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
+             RFC 4346, January 2006.
+
+   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
+             T. Wright, "Transport Layer Security (TLS) Extensions",
+             RFC 4366, February 2006.
+
+   [N5]      Mockapetris, P., "Domain Names - Concepts and
+             Facilities", STD 13, RFC 1034, November 1987.
+
+   [N6]      S. Santesson, "TLS Handshake Message for Supplementary
+             Data", RFC TBD (currently: draft-santesson-tls-supp-02,
+             Date 2006.
+
+   [N7]      P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
+             Domain Names in Applications (IDNA)", RFC 3490, March 2003
+
+   [N8]      T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
+             Considerations Section in RFCs", RFC 2434, October 1998
+
+
+7 IANA Considerations
+
+   IANA needs to take the following actions:
+
+   1) Create an entry, user_mapping(TBD), in the existing registry for
+   ExtensionType (defined in RFC 4366 [N4]).
+
+   2) Create an entry, user_mapping_data(TBD), in the new registry for
+   SupplementalDataType (defined in draft-santesson-tls-supp-02).
+
+   3) Establish a registry for TLS UserMappingType values.  The first
+   entry in the registry is upn_domain_hint(64). TLS UserMappingType
+   values in the inclusive range 0-63 (decimal) are assigned via RFC
+   2434 [N8] Standards Action.  Values from the inclusive range 64-223
+   (decimal) are assigned via RFC 2434 Specification Required.  Values
+   from the inclusive range 224-255 (decimal) are reserved for RFC 2434
+   Private Use.
+
+
+
+Santesson, et. all                                             [Page 11]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+Authors' Addresses
+
+
+   Stefan Santesson
+   Microsoft
+   Finlandsgatan 30
+   164 93 KISTA
+   Sweden
+
+   EMail: stefans(at)microsoft.com
+
+
+   Ari Medvinsky
+   Microsoft
+   One Microsoft Way
+   Redmond, WA 98052-6399
+   USA
+
+   Email: arimed(at)microsoft.com
+
+
+   Joshua Ball
+   Microsoft
+   One Microsoft Way
+   Redmond, WA 98052-6399
+   USA
+
+   Email: joshball(at)microsoft.com
+
+
+
+Acknowledgements
+
+   The authors extend a special thanks to Russ Housley, Eric Resocorla
+   and Paul Leach for their substantial contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                             [Page 12]
+
+INTERNET DRAFT         TLS User Mapping extension               May 2006
+
+
+Disclaimer
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+
+Expires November 2006
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                             [Page 13]