diff options
Diffstat (limited to 'doc/protocol/draft-santesson-tls-ume-01.txt')
| -rw-r--r-- | doc/protocol/draft-santesson-tls-ume-01.txt | 560 |
1 files changed, 0 insertions, 560 deletions
diff --git a/doc/protocol/draft-santesson-tls-ume-01.txt b/doc/protocol/draft-santesson-tls-ume-01.txt deleted file mode 100644 index 903200bbc2..0000000000 --- a/doc/protocol/draft-santesson-tls-ume-01.txt +++ /dev/null @@ -1,560 +0,0 @@ - - - - -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] |