Add.

1 files changed, 560 insertions, 0 deletions

diff --git a/doc/protocol/draft-santesson-tls-ume-01.txt b/doc/protocol/draft-santesson-tls-ume-01.txt
new file mode 100644
index 0000000000..903200bbc2
--- /dev/null
+++ b/doc/protocol/draft-santesson-tls-ume-01.txt
@@ -0,0 +1,560 @@
+
+
+
+
+TLS Working Group                               S. Santesson (Microsoft)
+INTERNET-DRAFT                                  A. Medvinsky (Microsoft)
+Intended Category: Standards track                   J. Ball (Microsoft)
+Expires July 2006                                           January 2006
+
+
+                       TLS User Mapping Extension
+                    <draft-santesson-tls-ume-01.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.
+
+   This document may not be modified, and derivative works of it may not
+   be created, except to publish it as an RFC and to translate it into
+   languages other than English.
+
+   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 data in a new handshake message. In particular
+   one such mapping is defined, the UpnDomainHint, which may be used by
+   a server to locate a user in a directory database.
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 1]
+
+INTERNET DRAFT         TLS User Mapping extension           January 2006
+
+
+Table of Contents
+
+   1  Introduction ................................................    2
+   2  User mapping extension ......................................    3
+   3  User mapping handshake protocol .............................    3
+   4  Message flow ................................................    6
+   5  Security Considerations .....................................    7
+   6  References ..................................................    8
+   Appendix A. IPR Disclosure .....................................    9
+   Authors' Addresses .............................................    9
+   Disclaimer .....................................................   10
+   Copyright Statement ............................................   10
+
+1.  Introduction
+
+   This specification documents a TLS extension and a handshake message,
+   which has been defined and implemented by Microsoft to accommodate
+   mapping of users to their user accounts when using TLS client
+   authentication as the authentication method.
+
+   The UPN (User Principal Name) is a name form defined by Microsoft
+   which specifies a user's entry in a directory in the form of
+   userName@domainName.  Traditionally Microsoft has relied on such UPN
+   names to be present in the client certificate when logging on to a
+   domain account.
+
+   This has several drawbacks however 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 extension defined in this document provide a significant
+   improvement to this situation since 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 new extension (user_mapping) is sent in the Client Hello message.
+   Per convention defined in RFC3546 [N3], 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.
+
+   If the new extension is understood, the client will inject a new
+   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
+
+
+
+Santesson, et. all                                              [Page 2]
+
+INTERNET DRAFT         TLS User Mapping extension           January 2006
+
+
+   the user's directory account.
+
+   The reason the mapping data itself is not placed in the extension
+   portion of the ClientHello is to prevent broadcasting this
+   information to servers that don't understand the extension.
+   Additionally, if new mapping information were to be considered
+   confidential, the addition of a new handshake message allows the data
+   to be encrypted using the servers public key.
+
+   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 [STDWORDS].
+
+
+2  User mapping extension
+
+   A new extension type (user_mapping(n)) is added to the Extension used
+   in both the Client Hello and Server Hello messages. The extension
+   type is specified as follows and has no data associated with it.
+
+
+      enum {
+           user_mapping(n), (65535)
+      } ExtensionType;
+
+
+3  User mapping handshake protocol
+
+   A new HandshakeType (user_mapping_data) is defined to accommodate
+   communication of generic user mapping data.
+
+   The information in this handshake message carries an unauthenticated
+   hint, 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.
+
+
+      enum {
+             user_mapping_data(n),(255)
+      } HandshakeType;
+
+
+
+Santesson, et. all                                              [Page 3]
+
+INTERNET DRAFT         TLS User Mapping extension           January 2006
+
+
+   The user_mapping_data(n) enumeration results in a new Handshake
+   Message UserMappingDataList with the following structure:
+
+
+      enum {
+             upn_domain_hint(0), (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;
+
+      struct{
+         UserMappingData user_mapping_data_list<1..2^16-1>;
+      }UserMappingDataList;
+
+
+
+   The user_principal_name parameter, when specified, SHALL be specified
+   in the form:
+
+      user@domain
+
+   For example the UPN 'foo@example.com' represents user 'foo' at domain
+   'example.com'.
+
+   The domain_name parameter, when specified, SHALL contain a domain
+   name in the "preferred name syntax," as specified by RFC 1034 [N4]
+
+   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.
+
+   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.
+
+
+
+
+Santesson, et. all                                              [Page 4]
+
+INTERNET DRAFT         TLS User Mapping extension           January 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 5]
+
+INTERNET DRAFT         TLS User Mapping extension           January 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.  The
+   "extension_data" field of this extension SHALL be empty.
+
+   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.  The "extension_data"
+   field of this extension SHALL be empty.
+
+   After negotiation of the use of user mapping has been successfully
+   completed (by exchanging hellos including "user_mapping" extensions),
+   clients MAY send a "UserMappingDataList" message 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
+
+      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].
+
+
+
+
+
+
+Santesson, et. all                                              [Page 6]
+
+INTERNET DRAFT         TLS User Mapping extension           January 2006
+
+
+5  Security Considerations
+
+   The UPN sent in the UserMappingDataList is unauthenticated data that
+   MUST NOT be treated as a trusted identifier. Authentication of the
+   user represented by that UPN MUST rely solely on validation of the
+   client certificate. One way to do this safely is to use the UPN to
+   locate and extract a certificate of the claimed user from a 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 this information to
+   just any server at any time, as it can reveal network infrastructure
+   the client and server are using.
+
+   To avoid superfluously sending this information, two techniques
+   SHOULD be used to control its dissemination.
+
+      - The client SHOULD only send the UserMappingDataList handshake
+        message if it is agreed upon in the Hello exchange, preventing
+        the information from being sent to a server that doesn't
+        understand the User Mapping Extension.
+
+      - The client SHOULD further only send this information if the
+        server belongs to a domain to which the client intends to
+        authenticate using the UPN as identifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 7]
+
+INTERNET DRAFT         TLS User Mapping extension           January 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]        S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
+               T. Wright, "Transport Layer Security (TLS) Extensions",
+               RFC 3546, June 2003.
+
+   [N4]        Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 8]
+
+INTERNET DRAFT         TLS User Mapping extension           January 2006
+
+
+Appendix A. IPR Disclosure
+
+   TBD
+
+Authors' Addresses
+
+
+   Stefan Santesson
+   Microsoft
+   Tuborg Boulevard 12
+   2900 Hellerup
+   Denmark
+
+   EMail: stefans(at)microsoft.com
+
+
+   Ari Medvinsky
+   Microsoft
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   Email: arimed(at)microsoft.com
+
+
+   Joshua Ball
+   Microsoft
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   Email: joshball(at)microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                              [Page 9]
+
+INTERNET DRAFT         TLS User Mapping extension           January 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 July 2006
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all                                             [Page 10]