| blob | f2c09e3adb11a3fa2d617f79d2a474cb9e64f196 |
5 TLS Working Group S. Santesson (Microsoft)
6 INTERNET-DRAFT A. Medvinsky (Microsoft)
7 Intended Category: Informational J. Ball (Microsoft)
8 Expires June 2006 December 2005
11 TLS User Mapping Extension
12 <draft-santesson-tls-ume-00.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 December 2005
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 ................................................ 5
67 5 Security Considerations ..................................... 6
68 6 References .................................................. 7
69 Appendix A. IPR Disclosure ..................................... 8
70 Authors' Addresses ............................................. 8
71 Disclaimer ..................................................... 9
72 Copyright Statement ............................................ 9
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 non-extended
102 Server Hello message and the client will proceed as normal, ignoring
103 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 December 2005
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 December 2005
173 The user_mapping_data(n) enumeration results in a new Handshake
174 Message UserMappingData with the following structure:
177 enum {
178 UpnDomainHint(0), (255)
179 } UserMappingType;
181 struct {
182 opaque user_principle_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 UpnDomainHint:
190 UpnDomainHint;
191 }
192 } UserMappingData;
195 The user_principal_name parameter, when specified, SHALL be specified
196 in the form:
198 user@domain
200 For example the UPN 'foo@example.com' represents user 'foo' at domain
201 'example.com'.
203 The domain_name parameter, when specified, SHALL contain a domain
204 name in the "preferred name syntax," as specified by RFC 1034 [N4]
206 The UpnDomainHint MUST at least contain a non empty
207 user_principal_name or a non empty domain_name. The UpnDomainHint MAY
208 contain both user_principal_name and domain_name.
224 Santesson, et. all [Page 4]
225 \f
226 INTERNET DRAFT TLS User Mapping extension December 2005
229 4 Message flow
231 In order to negotiate to send user mapping data to a server in
232 accordance with this specification, clients MUST include an extension
233 of type "user_mapping" in the (extended) client hello. The
234 "extension_data" field of this extension SHALL be empty.
236 Servers that receive an extended client hello containing a
237 "user_mapping" extension, MAY indicate that they are willing to
238 accept user mapping data by including an extension of type
239 "user_mapping" in the (extended) server hello. The "extension_data"
240 field of this extension SHALL be empty.
242 After negotiation of the use of user mapping has been successfully
243 completed (by exchanging hellos including "user_mapping" extensions),
244 clients MAY send a "UserMappingData" message before the "Certificate"
245 message. The message flow is illustrated in Fig. 1 below.
247 Client Server
249 ClientHello
250 /* with user_mapping ext */ -------->
252 ServerHello
253 /* with user-mapping ext */
254 Certificate*
255 ServerKeyExchange*
256 CertificateRequest*
257 <-------- ServerHelloDone
259 UserMappingData
260 Certificate*
261 ClientKeyExchange
262 CertificateVerify*
263 [ChangeCipherSpec]
264 Finished -------->
265 [ChangeCipherSpec]
266 <-------- Finished
267 Application Data <-------> Application Data
269 Fig. 1 - Message flow with user mapping data
271 * Indicates optional or situation-dependent messages that are not
272 always sent according to RFC 2246 [N2].
280 Santesson, et. all [Page 5]
281 \f
282 INTERNET DRAFT TLS User Mapping extension December 2005
285 5 Security Considerations
287 The UPN sent in the UserMappingData is unauthenticated data that MUST
288 NOT be treated as a trusted identifier. Authentication of the user
289 represented by that UPN MUST rely solely on validation of the client
290 certificate. One way to do this safely is to use the UPN to locate
291 and extract a certificate of the claimed user from a directory and
292 subsequently match this certificate against the validated client
293 certificate from the TLS handshake.
296 As the client is the initiator of this TLS extension, it needs to
297 determine when it is appropriate to send the User Mapping
298 Information. It may not be prudent to broadcast this information to
299 just any server at any time, as it can reveal network infrastructure
300 the client and server are using.
302 To avoid superfluously sending this information, two techniques
303 SHOULD be used to control its dissemination.
305 - The client SHOULD only send the UserMappingData handshake
306 message if it is agreed upon in the Hello exchange, preventing
307 the information from being sent to a server that doesn't
308 understand the User Mapping Extension.
310 - The client SHOULD further only send this information if the
311 server belongs to a domain to which the client intends to
312 authenticate using the UPN as identifier.
336 Santesson, et. all [Page 6]
337 \f
338 INTERNET DRAFT TLS User Mapping extension December 2005
341 6 References
343 Normative references:
345 [N1] S. Bradner, "Key words for use in RFCs to Indicate
346 Requirement Levels", BCP 14, RFC 2119, March 1997.
348 [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
349 RFC 2246, January 1999.
351 [N3] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
352 T. Wright, "Transport Layer Security (TLS) Extensions",
353 RFC 3546, June 2003.
355 [N4] Mockapetris, P., "Domain Names - Concepts and
356 Facilities", STD 13, RFC 1034, November 1987.
392 Santesson, et. all [Page 7]
393 \f
394 INTERNET DRAFT TLS User Mapping extension December 2005
397 Appendix A. IPR Disclosure
399 TBD
401 Authors' Addresses
404 Stefan Santesson
405 Microsoft
406 Tuborg Boulevard 12
407 2900 Hellerup
408 Denmark
410 EMail: stefans(at)microsoft.com
413 Ari Medvinsky
414 Microsoft
415 One Microsoft Way
416 Redmond, WA 98052-6399
418 Email: arimed(at)microsoft.com
421 Joshua Ball
422 Microsoft
423 One Microsoft Way
424 Redmond, WA 98052-6399
426 Email: joshball(at)microsoft.com
448 Santesson, et. all [Page 8]
449 \f
450 INTERNET DRAFT TLS User Mapping extension December 2005
453 Disclaimer
455 This document and the information contained herein are provided on an
456 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
457 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
458 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
459 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
460 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
461 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
464 Copyright Statement
466 Copyright (C) The Internet Society (2005).
468 This document is subject to the rights, licenses and restrictions
469 contained in BCP 78, and except as set forth therein, the authors
470 retain all their rights.
473 Expires June 2006
504 Santesson, et. all [Page 9]