idnits 2.17.1 draft-santesson-tls-ume-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 359. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The draft header indicates that this document updates RFC4346, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2246, updated by this document, for RFC5378 checks: 1996-12-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6645 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'STDWORDS' is mentioned on line 104, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 254, but not defined == Missing Reference: 'IANA' is mentioned on line 318, but not defined == Unused Reference: 'N1' is defined on line 297, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. 'N2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (ref. 'N3') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (ref. 'N4') (Obsoleted by RFC 5246, RFC 6066) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson (Microsoft) 3 Updates: 2246, 4346 (once approved) A. Medvinsky (Microsoft) 4 Intended Category: Standards track J. Ball (Microsoft) 5 Expires August 2006 February 2006 7 TLS User Mapping Extension 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than a "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This document specifies a TLS extension that enables clients to send 40 generic user mapping data in a new handshake message. One such 41 mapping is defined, the UpnDomainHint, which may be used by a server 42 to locate a user in a directory database. Other mappings may be 43 defined in other documents in the future. 45 Table of Contents 47 1 Introduction ................................................ 2 48 2 User mapping extension ...................................... 3 49 3 User mapping handshake protocol ............................. 4 50 4 Message flow ................................................ 6 51 5 Security Considerations ..................................... 7 52 6 References .................................................. 8 53 7 IANA Considerations ... ...................................... 8 54 Authors' Addresses ............................................. 9 55 Disclaimer ..................................................... 10 56 Copyright Statement ............................................ 10 58 1. Introduction 60 This specification documents a TLS extension and a handshake message, 61 which has been defined and implemented by Microsoft to accommodate 62 mapping of users to their user accounts when using TLS client 63 authentication as the authentication method. 65 The UPN (User Principal Name) is a name form defined by Microsoft 66 which specifies a user's entry in a directory in the form of 67 userName@domainName. Traditionally Microsoft has relied on such UPN 68 names to be present in the client certificate when logging on to a 69 domain account. 71 This has several drawbacks however since it prevents the use of 72 certificates with an absent UPN and also requires re-issuance of 73 certificates or issuance of multiple certificates to reflect account 74 changes or creation of new accounts. 76 The TLS extension defined in this document provide a significant 77 improvement to this situation since it allows a single certificate to 78 be mapped to one or more accounts of the user and does not require 79 the certificate to contain a UPN. 81 The new TLS extension (user_mapping) is sent in the client hello 82 message. Per convention defined in RFC 4366 [N4], the server places 83 the same extension (user_mapping) in the server hello message, to 84 inform the client that the server understands this extension. If the 85 server does not understand the extension, it will respond with a 86 server hello omitting this extension and the client will proceed as 87 normal, ignoring the extension, and not include the 88 UserMappingDataList message in the TLS handshake. 90 If the new extension is understood, the client will inject a new 91 handshake message prior to the Client's Certificate message. The 92 server will then parse this message, extracting the client's domain, 93 and store it in the context for use when mapping the certificate to 94 the user's directory account. 96 No other modifications to the protocol are required. The messages are 97 detailed in the following sections. 99 1.1 Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [STDWORDS]. 105 The syntax for the TLS User Mapping extension is defined using the 106 TLS Presentation Language, which is specified in Section 4 of [N2]. 108 1.2 Design considerations 110 The reason the mapping data itself is not placed in the extension 111 portion of the client hello is to prevent broadcasting this 112 information to servers that don't understand the extension. 113 Additionally, if new mapping information were to be considered 114 confidential, the addition of a new handshake message allows the data 115 to be encrypted using the server's public key. 117 2 User mapping extension 119 A new extension type (user_mapping(n)) is added to the Extension used 120 in both the client hello and server hello messages. The extension 121 type is specified as follows. 123 enum { 124 user_mapping(n), (65535) 125 } ExtensionType; 127 The "extension_data" field of this extension SHALL contain 128 "UserMappingTypeList" with a list of supported hint types where: 130 struct { 131 UserMappingType user_mapping_types<1..2^8-1> 132 } UserMappingTypeList; 134 Enumeration of hint types (user_mapping_types) defined in this 135 document is provided in section 3. 137 The list of user_mapping_types included in a client hello SHALL 138 signal the hint types supported by the client. The list of 139 user_mapping_types included in the server hello SHALL signal the hint 140 types preferred by the server. 142 If none of the hint types listed by the client is supported by the 143 server, the server SHALL omit the user_mapping extension in the 144 server hello. 146 When the user_mapping extension is included in the server hello, the 147 list of hint types in "UserMappingTypeList" SHALL be either equal to, 148 or a subset of, the list provided by the client. 150 3 User mapping handshake protocol 152 A new HandshakeType (user_mapping_data) is defined to accommodate 153 communication of generic user mapping data. See RFC 2246 (TLS 1.0) 154 [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types. 156 The information in this handshake message carries an unauthenticated 157 hint, inserted by the client side. Upon receipt and successful 158 completion of the TLS handshake, the server MAY use this hint to 159 locate the user's account from which user information and credentials 160 MAY be retrieved to support authentication based on the client 161 certificate. 163 enum { 164 user_mapping_data(n),(255) 165 } HandshakeType; 167 The user_mapping_data(n) enumeration results in a new Handshake 168 Message UserMappingDataList with the following structure: 170 enum { 171 upn_domain_hint(0), (255) 172 } UserMappingType; 174 struct { 175 opaque user_principal_name<0..2^16-1>; 176 opaque domain_name<0..2^16-1>; 177 } UpnDomainHint; 179 struct { 180 UserMappingType user_mapping_version 181 select(UserMappingType) { 182 case upn_domain_hint: 184 UpnDomainHint; 185 } 186 } UserMappingData; 188 struct{ 189 UserMappingData user_mapping_data_list<1..2^16-1>; 190 }UserMappingDataList; 192 The user_principal_name parameter, when specified, SHALL be specified 193 in the form: 195 user@domain 197 For example the UPN 'foo@example.com' represents user 'foo' at domain 198 'example.com'. 200 The domain_name parameter, when specified, SHALL contain a domain 201 name in the "preferred name syntax," as specified by RFC 1034 [N5] 203 The UpnDomainHint MUST at least contain a non empty 204 user_principal_name or a non empty domain_name. The UpnDomainHint MAY 205 contain both user_principal_name and domain_name. 207 The UserMappingData structure contains a single mapping of type 208 UserMappingType. This structure can be leveraged to define new types 209 of user mapping hints in the future. The UserMappingDataList MAY 210 carry multiple hints; it is defined as a vector of UserMappingData 211 structures. 213 No preference is given to the order in which hints are specified in 214 this vector. If the client sends more then one hint then the Server 215 SHOULD use the applicable mapping supported by the server. 217 4 Message flow 219 In order to negotiate to send user mapping data to a server in 220 accordance with this specification, clients MUST include an extension 221 of type "user_mapping" in the (extended) client hello, which SHALL 222 contain a list of supported hint types. 224 Servers that receive an extended client hello containing a 225 "user_mapping" extension, MAY indicate that they are willing to 226 accept user mapping data by including an extension of type 227 "user_mapping" in the (extended) server hello, which SHALL contain a 228 list of preferred hint types. 230 After negotiation of the use of user mapping has been successfully 231 completed (by exchanging hello messages including "user_mapping" 232 extensions), clients MAY send a "UserMappingDataList" message before 233 the "Certificate" message. The message flow is illustrated in Fig. 1 234 below. 236 Client Server 238 ClientHello 239 /* with user_mapping ext */ --------> 241 ServerHello 242 /* with user-mapping ext */ 243 Certificate* 244 ServerKeyExchange* 245 CertificateRequest* 246 <-------- ServerHelloDone 248 UserMappingDataList 249 Certificate* 250 ClientKeyExchange 251 CertificateVerify* 252 [ChangeCipherSpec] 253 Finished --------> 254 [ChangeCipherSpec] 255 <-------- Finished 256 Application Data <-------> Application Data 258 Fig. 1 - Message flow with user mapping data 260 * Indicates optional or situation-dependent messages that are not 261 always sent according to RFC 2246 [N2] and RFC 4346 [N3]. 263 5 Security Considerations 265 The UPN sent in the UserMappingDataList is unauthenticated data that 266 MUST NOT be treated as a trusted identifier. Authentication of the 267 user represented by that UPN MUST rely solely on validation of the 268 client certificate. One way to do this in the Microsoft environment 269 is to use the UPN to locate and extract a certificate of the claimed 270 user from the trusted directory and subsequently match this 271 certificate against the validated client certificate from the TLS 272 handshake. 274 As the client is the initiator of this TLS extension, it needs to 275 determine when it is appropriate to send the User Mapping 276 Information. It may not be prudent to broadcast this information to 277 just any server at any time, as it can reveal network infrastructure 278 the client and server are using. 280 To avoid superfluously sending this information, two techniques 281 SHOULD be used to control its dissemination. 283 - The client SHOULD only send the UserMappingDataList handshake 284 message if it is agreed upon in the hello message exchange, 285 preventing 286 the information from being sent to a server that doesn't 287 understand the User Mapping Extension. 289 - The client SHOULD further only send this information if the 290 server belongs to a domain to which the client intends to 291 authenticate using the UPN as identifier. 293 6 References 295 Normative references: 297 [N1] S. Bradner, "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 301 RFC 2246, January 1999. 303 [N3] T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1", 304 RFC 4346, January 2006. 306 [N4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, 307 T. Wright, "Transport Layer Security (TLS) Extensions", 308 RFC 4366, February 2006. 310 [N5] Mockapetris, P., "Domain Names - Concepts and 311 Facilities", STD 13, RFC 1034, November 1987. 313 7 IANA Considerations 315 IANA needs to establish a registry for TLS UserMappingType values. 316 The first entry in the registry is upn_domain_hint(0). TLS 317 UserMappingType values in the inclusive range 0-63 (decimal) are 318 assigned via RFC 2434 [IANA] Standards Action. Values from the 319 inclusive range 64-223 (decimal) are assigned via RFC 2434 320 Specification Required. Values from the inclusive range 224-255 321 (decimal) are reserved for RFC 2434 Private Use. 323 Appendix A. IPR Disclosure 325 TBD 327 Authors' Addresses 329 Stefan Santesson 330 Microsoft 331 Tuborg Boulevard 12 332 2900 Hellerup 333 Denmark 335 EMail: stefans(at)microsoft.com 337 Ari Medvinsky 338 Microsoft 339 One Microsoft Way 340 Redmond, WA 98052-6399 342 Email: arimed(at)microsoft.com 344 Joshua Ball 345 Microsoft 346 One Microsoft Way 347 Redmond, WA 98052-6399 349 Email: joshball(at)microsoft.com 351 Disclaimer 353 This document and the information contained herein are provided on an 354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 356 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 357 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 358 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 361 Copyright Statement 363 Copyright (C) The Internet Society (2006). 365 This document is subject to the rights, licenses and restrictions 366 contained in BCP 78, and except as set forth therein, the authors 367 retain all their rights. 369 Expires August 2006