| blob | 903200bbc2ef5cc5570231ba0428821088e23be5 |
5 TLS Working Group S. Santesson (Microsoft)
6 INTERNET-DRAFT A. Medvinsky (Microsoft)
7 Intended Category: Standards track J. Ball (Microsoft)
8 Expires July 2006 January 2006
11 TLS User Mapping Extension
12 <draft-santesson-tls-ume-01.txt>
15 Status of this Memo
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 This document may not be modified, and derivative works of it may not
23 be created, except to publish it as an RFC and to translate it into
24 languages other than English.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
29 Drafts.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than a "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/1id-abstracts.html
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html
43 Abstract
45 This document specifies a TLS extension that enables clients to send
46 generic user mapping data in a new handshake message. In particular
47 one such mapping is defined, the UpnDomainHint, which may be used by
48 a server to locate a user in a directory database.
56 Santesson, et. all [Page 1]
57 \f
58 INTERNET DRAFT TLS User Mapping extension January 2006
61 Table of Contents
63 1 Introduction ................................................ 2
64 2 User mapping extension ...................................... 3
65 3 User mapping handshake protocol ............................. 3
66 4 Message flow ................................................ 6
67 5 Security Considerations ..................................... 7
68 6 References .................................................. 8
69 Appendix A. IPR Disclosure ..................................... 9
70 Authors' Addresses ............................................. 9
71 Disclaimer ..................................................... 10
72 Copyright Statement ............................................ 10
74 1. Introduction
76 This specification documents a TLS extension and a handshake message,
77 which has been defined and implemented by Microsoft to accommodate
78 mapping of users to their user accounts when using TLS client
79 authentication as the authentication method.
81 The UPN (User Principal Name) is a name form defined by Microsoft
82 which specifies a user's entry in a directory in the form of
83 userName@domainName. Traditionally Microsoft has relied on such UPN
84 names to be present in the client certificate when logging on to a
85 domain account.
87 This has several drawbacks however since it prevents the use of
88 certificates with an absent UPN and also requires re-issuance of
89 certificates or issuance of multiple certificates to reflect account
90 changes or creation of new accounts.
92 The extension defined in this document provide a significant
93 improvement to this situation since it allows a single certificate to
94 be mapped to one or more accounts of the user and does not require
95 the certificate to contain a UPN.
97 The new extension (user_mapping) is sent in the Client Hello message.
98 Per convention defined in RFC3546 [N3], the server places the same
99 extension (user_mapping) in the Server Hello message, to inform the
100 client that the server understands this extension. If the server does
101 not understand the extension, it will respond with a Server Hello
102 omitting this extension and the client will proceed as normal,
103 ignoring the extension.
105 If the new extension is understood, the client will inject a new
106 handshake message prior to the Client's Certificate message. The
107 server will then parse this message, extracting the client's domain,
108 and store it in the context for use when mapping the certificate to
112 Santesson, et. all [Page 2]
113 \f
114 INTERNET DRAFT TLS User Mapping extension January 2006
117 the user's directory account.
119 The reason the mapping data itself is not placed in the extension
120 portion of the ClientHello is to prevent broadcasting this
121 information to servers that don't understand the extension.
122 Additionally, if new mapping information were to be considered
123 confidential, the addition of a new handshake message allows the data
124 to be encrypted using the servers public key.
126 No other modifications to the protocol are required. The messages are
127 detailed in the following sections.
130 1.1 Terminology
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
134 document are to be interpreted as described in RFC 2119 [STDWORDS].
137 2 User mapping extension
139 A new extension type (user_mapping(n)) is added to the Extension used
140 in both the Client Hello and Server Hello messages. The extension
141 type is specified as follows and has no data associated with it.
144 enum {
145 user_mapping(n), (65535)
146 } ExtensionType;
149 3 User mapping handshake protocol
151 A new HandshakeType (user_mapping_data) is defined to accommodate
152 communication of generic user mapping data.
154 The information in this handshake message carries an unauthenticated
155 hint, inserted by the client side. Upon receipt and successful
156 completion of the TLS handshake, the server MAY use this hint to
157 locate the user's account from which user information and credentials
158 MAY be retrieved to support authentication based on the client
159 certificate.
162 enum {
163 user_mapping_data(n),(255)
164 } HandshakeType;
168 Santesson, et. all [Page 3]
169 \f
170 INTERNET DRAFT TLS User Mapping extension January 2006
173 The user_mapping_data(n) enumeration results in a new Handshake
174 Message UserMappingDataList with the following structure:
177 enum {
178 upn_domain_hint(0), (255)
179 } UserMappingType;
181 struct {
182 opaque user_principal_name<0..2^16-1>;
183 opaque domain_name<0..2^16-1>;
184 } UpnDomainHint;
186 struct {
187 UserMappingType user_mapping_version
188 select(UserMappingType) {
189 case upn_domain_hint:
190 UpnDomainHint;
191 }
192 } UserMappingData;
194 struct{
195 UserMappingData user_mapping_data_list<1..2^16-1>;
196 }UserMappingDataList;
200 The user_principal_name parameter, when specified, SHALL be specified
201 in the form:
203 user@domain
205 For example the UPN 'foo@example.com' represents user 'foo' at domain
206 'example.com'.
208 The domain_name parameter, when specified, SHALL contain a domain
209 name in the "preferred name syntax," as specified by RFC 1034 [N4]
211 The UpnDomainHint MUST at least contain a non empty
212 user_principal_name or a non empty domain_name. The UpnDomainHint MAY
213 contain both user_principal_name and domain_name.
215 The UserMappingData structure contains a single mapping of type
216 UserMappingType. This structure can be leveraged to define new types
217 of user mapping hints in the future. The UserMappingDataList MAY
218 carry multiple hints; it is defined as a vector of UserMappingData
219 structures.
224 Santesson, et. all [Page 4]
225 \f
226 INTERNET DRAFT TLS User Mapping extension January 2006
229 No preference is given to the order in which hints are specified in
230 this vector. If the client sends more then one hint then the Server
231 SHOULD use the applicable mapping supported by the server.
280 Santesson, et. all [Page 5]
281 \f
282 INTERNET DRAFT TLS User Mapping extension January 2006
285 4 Message flow
287 In order to negotiate to send user mapping data to a server in
288 accordance with this specification, clients MUST include an extension
289 of type "user_mapping" in the (extended) client hello. The
290 "extension_data" field of this extension SHALL be empty.
292 Servers that receive an extended client hello containing a
293 "user_mapping" extension, MAY indicate that they are willing to
294 accept user mapping data by including an extension of type
295 "user_mapping" in the (extended) server hello. The "extension_data"
296 field of this extension SHALL be empty.
298 After negotiation of the use of user mapping has been successfully
299 completed (by exchanging hellos including "user_mapping" extensions),
300 clients MAY send a "UserMappingDataList" message before the
301 "Certificate" message. The message flow is illustrated in Fig. 1
302 below.
304 Client Server
306 ClientHello
307 /* with user_mapping ext */ -------->
309 ServerHello
310 /* with user-mapping ext */
311 Certificate*
312 ServerKeyExchange*
313 CertificateRequest*
314 <-------- ServerHelloDone
316 UserMappingDataList
317 Certificate*
318 ClientKeyExchange
319 CertificateVerify*
320 [ChangeCipherSpec]
321 Finished -------->
322 [ChangeCipherSpec]
323 <-------- Finished
324 Application Data <-------> Application Data
326 Fig. 1 - Message flow with user mapping data
328 * Indicates optional or situation-dependent messages that are not
329 always sent according to RFC 2246 [N2].
336 Santesson, et. all [Page 6]
337 \f
338 INTERNET DRAFT TLS User Mapping extension January 2006
341 5 Security Considerations
343 The UPN sent in the UserMappingDataList is unauthenticated data that
344 MUST NOT be treated as a trusted identifier. Authentication of the
345 user represented by that UPN MUST rely solely on validation of the
346 client certificate. One way to do this safely is to use the UPN to
347 locate and extract a certificate of the claimed user from a directory
348 and subsequently match this certificate against the validated client
349 certificate from the TLS handshake.
352 As the client is the initiator of this TLS extension, it needs to
353 determine when it is appropriate to send the User Mapping
354 Information. It may not be prudent to broadcast this information to
355 just any server at any time, as it can reveal network infrastructure
356 the client and server are using.
358 To avoid superfluously sending this information, two techniques
359 SHOULD be used to control its dissemination.
361 - The client SHOULD only send the UserMappingDataList handshake
362 message if it is agreed upon in the Hello exchange, preventing
363 the information from being sent to a server that doesn't
364 understand the User Mapping Extension.
366 - The client SHOULD further only send this information if the
367 server belongs to a domain to which the client intends to
368 authenticate using the UPN as identifier.
392 Santesson, et. all [Page 7]
393 \f
394 INTERNET DRAFT TLS User Mapping extension January 2006
397 6 References
399 Normative references:
401 [N1] S. Bradner, "Key words for use in RFCs to Indicate
402 Requirement Levels", BCP 14, RFC 2119, March 1997.
404 [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
405 RFC 2246, January 1999.
407 [N3] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
408 T. Wright, "Transport Layer Security (TLS) Extensions",
409 RFC 3546, June 2003.
411 [N4] Mockapetris, P., "Domain Names - Concepts and
412 Facilities", STD 13, RFC 1034, November 1987.
448 Santesson, et. all [Page 8]
449 \f
450 INTERNET DRAFT TLS User Mapping extension January 2006
453 Appendix A. IPR Disclosure
455 TBD
457 Authors' Addresses
460 Stefan Santesson
461 Microsoft
462 Tuborg Boulevard 12
463 2900 Hellerup
464 Denmark
466 EMail: stefans(at)microsoft.com
469 Ari Medvinsky
470 Microsoft
471 One Microsoft Way
472 Redmond, WA 98052-6399
474 Email: arimed(at)microsoft.com
477 Joshua Ball
478 Microsoft
479 One Microsoft Way
480 Redmond, WA 98052-6399
482 Email: joshball(at)microsoft.com
504 Santesson, et. all [Page 9]
505 \f
506 INTERNET DRAFT TLS User Mapping extension January 2006
509 Disclaimer
511 This document and the information contained herein are provided on an
512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
514 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
515 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
516 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
520 Copyright Statement
522 Copyright (C) The Internet Society (2006).
524 This document is subject to the rights, licenses and restrictions
525 contained in BCP 78, and except as set forth therein, the authors
526 retain all their rights.
529 Expires July 2006
560 Santesson, et. all [Page 10]