idnits 2.17.1 draft-santesson-tls-ume-06.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 408. ** 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 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 (April 2006) is 6579 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: 'ChangeCipherSpec' is mentioned on line 278, but not defined == Unused Reference: 'N5' is defined on line 338, 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) ** Obsolete normative reference: RFC 3490 (ref. 'N7') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 2434 (ref. 'N8') (Obsoleted by RFC 5226) Summary: 13 errors (**), 0 flaws (~~), 3 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 October 2006 April 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 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document specifies a TLS extension that enables clients to send 36 generic user mapping hints in a supplemental data handshake message 37 defined in RFC TBD. One such mapping hint is defined, the 38 UpnDomainHint, which may be used by a server to locate a user in a 39 directory database. Other mapping hints may be defined in other 40 documents in the future. 42 (NOTE TO RFC EDITOR: Replace "RFC TBD" with the RFC number assigned 43 to draft-santesson-tls-supp-00.txt) 45 Table of Contents 47 1 Introduction ................................................ 2 48 2 User mapping extension ...................................... 3 49 3 User mapping handshake exchange ............................. 4 50 4 Message flow ................................................ 7 51 5 Security Considerations ..................................... 8 52 6 References .................................................. 9 53 7 IANA Considerations ... ...................................... 9 54 Authors' Addresses ............................................. 10 55 Acknowledgements ............................................... 10 56 Disclaimer ..................................................... 11 57 Copyright Statement ............................................ 11 59 1. Introduction 61 This specification defines a TLS extension and a payload for the 62 SupplementalData handshake message, defined in RFC TBD [N6], to 63 accommodate mapping of users to their user accounts when using TLS 64 client authentication as the authentication method. 66 This specification specifies one new user mapping hint type, 67 providing means to send Domain Name hints and User Principal Name 68 hints. Other hint types may be defined in other documents in the 69 future. 71 The User Principal Name (UPN) represents a name which specifies a 72 user's entry in a directory in the form of userName@domainName. 73 Traditionally Microsoft has relied on such name form to be present in 74 the client certificate when logging on to a domain account. This has 75 however several drawbacks since it prevents the use of certificates 76 with an absent UPN and also requires re-issuance of certificates or 77 issuance of multiple certificates to reflect account changes or 78 creation of new accounts. The TLS extension in combination with the 79 defined hint type provide a significant improvement to this situation 80 as it allows a single certificate to be mapped to one or more 81 accounts of the user and does not require the certificate to contain 82 a UPN. 84 The new TLS extension (user_mapping) is sent in the client hello 85 message. Per convention defined in RFC 4366 [N4], the server places 86 the same extension (user_mapping) in the server hello message, to 87 inform the client that the server understands this extension. If the 88 server does not understand the extension, it will respond with a 89 server hello omitting this extension and the client will proceed as 90 normal, ignoring the extension, and not include the 91 UserMappingDataList data in the TLS handshake. 93 If the new extension is understood, the client will inject 94 UserMappingDataList data in the SupplementalData handshake message 95 prior to the Client's Certificate message. The server will then parse 96 this message, extracting the client's domain, and store it in the 97 context for use when mapping the certificate to the user's directory 98 account. 100 No other modifications to the protocol are required. The messages are 101 detailed in the following sections. 103 1.1 Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [N1]. 109 The syntax for the TLS User Mapping extension is defined using the 110 TLS Presentation Language, which is specified in Section 4 of [N2]. 112 1.2 Design considerations 114 The reason the mapping data itself is not placed in the extension 115 portion of the client hello is to prevent broadcasting this 116 information to servers that don't understand the extension. 118 2 User mapping extension 120 A new extension type (user_mapping(TBD)) is added to the Extension 121 used in both the client hello and server hello messages. The 122 extension type is specified as follows. 124 enum { 125 user_mapping(TBD), (65535) 126 } ExtensionType; 128 The "extension_data" field of this extension SHALL contain 129 "UserMappingTypeList" with a list of supported hint types where: 131 struct { 132 UserMappingType user_mapping_types<1..2^8-1> 133 } UserMappingTypeList; 135 Enumeration of hint types (user_mapping_types) defined in this 136 document is provided in section 3. 138 The list of user_mapping_types included in a client hello SHALL 139 signal the hint types supported by the client. The list of 140 user_mapping_types included in the server hello SHALL signal the hint 141 types preferred by the server. 143 If none of the hint types listed by the client is supported by the 144 server, the server SHALL omit the user_mapping extension in the 145 server hello. 147 When the user_mapping extension is included in the server hello, the 148 list of hint types in "UserMappingTypeList" SHALL be either equal to, 149 or a subset of, the list provided by the client. 151 3 User mapping handshake exchange 153 The underlying structure of the SupplementalData handshake message, 154 used to carry information defined in this section, is defined in RFC 155 TBD [N6]. 157 A new SupplementalDataType [N6] is defined to accommodate 158 communication of generic user mapping data. See RFC 2246 (TLS 1.0) 159 [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types. 161 The information in this data type carries one or more unauthenticated 162 hints, UserMappingDataList, inserted by the client side. Upon receipt 163 and successful completion of the TLS handshake, the server MAY use 164 this hint to locate the user's account from which user information 165 and credentials MAY be retrieved to support authentication based on 166 the client certificate. 168 The hint defined in this specification (upn_domain_hint) specifies 169 two fields, user_principal_name and domain_name. The domain_name 170 field MAY be used when only domain information is needed, e.g. where 171 a user have accounts in multiple domains using the same username 172 name, where that user name is known from another source (e.g. from 173 the client certificate). When the user name is also needed, the 174 user_principal_name field MAY be used to indicate both username and 175 domain name. If both fields are present, then the server can make use 176 of whichever one it chooses. 178 struct { 179 SupplementalDataType supp_data_type; 180 select(SupplementalDataType) { 181 case user_mapping_data: UserMappingDataList; 182 } 183 } SupplementalDataEntry; 184 enum { 185 user_mapping_data(TBD), (65535) 186 } SupplementalDataType; 188 The user_mapping_data(TBD) enumeration results in a new supplemental 189 data type UserMappingDataList with the following structure: 191 enum { 192 upn_domain_hint(0), (255) 193 } UserMappingType; 195 struct { 196 opaque user_principal_name<0..2^16-1>; 197 opaque domain_name<0..2^16-1>; 198 } UpnDomainHint; 200 struct { 201 UserMappingType user_mapping_version 202 select(UserMappingType) { 203 case upn_domain_hint: 204 UpnDomainHint; 205 } 206 } UserMappingData; 208 struct{ 209 UserMappingData user_mapping_data_list<1..2^16-1>; 210 }UserMappingDataList; 212 The user_principal_name field, when specified, SHALL be of the form 213 "user@domain", where "user" is a UTF-8 encoded Unicode string that 214 does not contain the "@" character, and "domain" is a domain name 215 meeting the requirements in the following paragraph. 217 The domain_name field, when specified, SHALL contain a domain name in 218 the usual text form: in other words, a sequence of one or more domain 219 labels separated by ".", each domain label starting and ending with 220 an alphanumeric character and possibly also containing "-" 221 characters. This field is an "IDN-unaware domain name slot" as 222 defined in RFC 3490 [N7] and therefore, domain names containing non- 223 ASCII characters have to be processed as described in RFC 3490 before 224 being stored in this field. 226 The UpnDomainHint MUST at least contain a non empty 227 user_principal_name or a non empty domain_name. The UpnDomainHint MAY 228 contain both user_principal_name and domain_name. 230 The UserMappingData structure contains a single mapping of type 231 UserMappingType. This structure can be leveraged to define new types 232 of user mapping hints in the future. The UserMappingDataList MAY 233 carry multiple hints; it is defined as a vector of UserMappingData 234 structures. 236 No preference is given to the order in which hints are specified in 237 this vector. If the client sends more then one hint then the Server 238 SHOULD use the applicable mapping supported by the server. 240 4 Message flow 242 In order to negotiate to send user mapping data to a server in 243 accordance with this specification, clients MUST include an extension 244 of type "user_mapping" in the (extended) client hello, which SHALL 245 contain a list of supported hint types. 247 Servers that receive an extended client hello containing a 248 "user_mapping" extension, MAY indicate that they are willing to 249 accept user mapping data by including an extension of type 250 "user_mapping" in the (extended) server hello, which SHALL contain a 251 list of preferred hint types. 253 After negotiation of the use of user mapping has been successfully 254 completed (by exchanging hello messages including "user_mapping" 255 extensions), clients MAY send a "SupplementalData" message containing 256 the "UserMappingDataList" before the "Certificate" message. The 257 message flow is illustrated in Fig. 1 below. 259 Client Server 261 ClientHello 262 /* with user_mapping ext */ --------> 264 ServerHello 265 /* with user-mapping ext */ 266 Certificate* 267 ServerKeyExchange* 268 CertificateRequest* 269 <-------- ServerHelloDone 271 SupplementalData 272 /* with UserMappingDataList */ 273 Certificate* 274 ClientKeyExchange 275 CertificateVerify* 276 [ChangeCipherSpec] 277 Finished --------> 278 [ChangeCipherSpec] 279 <-------- Finished 280 Application Data <-------> Application Data 282 Fig. 1 - Message flow with user mapping data 284 * Indicates optional or situation-dependent messages that are not 285 always sent according to RFC 2246 [N2] and RFC 4346 [N3]. 287 The server MUST expect and gracefully handle the case where the 288 client chooses to not send any supplementalData handshake message 289 even after successful negotiation of extensions. The client MAY at 290 its own discretion decide that the user mapping hint it initially 291 intended to send no longer is relevant for this session. One such 292 reason could be that the server certificate fails to meet certain 293 requirements. 295 5 Security Considerations 297 The user mapping hint sent in the UserMappingDataList is 298 unauthenticated data that MUST NOT be treated as a trusted 299 identifier. Authentication of the user represented by that user 300 mapping hint MUST rely solely on validation of the client 301 certificate. One way to do this is to use the user mapping hint to 302 locate and extract a certificate of the claimed user from the trusted 303 directory and subsequently match this certificate against the 304 validated client certificate from the TLS handshake. 306 As the client is the initiator of this TLS extension, it needs to 307 determine when it is appropriate to send the User Mapping 308 Information. It may not be prudent to broadcast this information to 309 just any server at any time, as it can reveal network infrastructure 310 the client and server are using. 312 To avoid superfluously sending this information, clients SHOULD only 313 send this information if the server belongs to a domain to which the 314 client intends to authenticate using the UPN as identifier. 316 In some cases, the user mapping hint may itself be regarded as 317 sensitive. In such case the double handshake technique described in 318 [N6] can be used to provide protection for the user mapping hint 319 information. 321 6 References 323 Normative references: 325 [N1] S. Bradner, "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 329 RFC 2246, January 1999. 331 [N3] T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1", 332 RFC 4346, January 2006. 334 [N4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, 335 T. Wright, "Transport Layer Security (TLS) Extensions", 336 RFC 4366, February 2006. 338 [N5] Mockapetris, P., "Domain Names - Concepts and 339 Facilities", STD 13, RFC 1034, November 1987. 341 [N6] S. Santesson, "TLS Handshake Message for Supplementary 342 Data", RFC TBD (currently: draft-santesson-tls-supp-02, 343 Date 2006. 345 [N7] P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing 346 Domain Names in Applications (IDNA)", RFC 3490, March 2003 348 [N8] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 349 Considerations Section in RFCs", RFC 2434, October 1998 351 7 IANA Considerations 353 IANA needs to take the following actions: 355 1) Create an entry, user_mapping(TBD), in the existing registry for 356 ExtensionType (defined in RFC 4366 [N4]). 358 2) Create an entry, user_mapping_data(TBD), in the new registry for 359 SupplementalDataType (defined in draft-santesson-tls-supp-02). 361 3) Establish a registry for TLS UserMappingType values. The first 362 entry in the registry is upn_domain_hint(0). TLS UserMappingType 363 values in the inclusive range 0-63 (decimal) are assigned via RFC 364 2434 [N8] Standards Action. Values from the inclusive range 64-223 365 (decimal) are assigned via RFC 2434 Specification Required. Values 366 from the inclusive range 224-255 (decimal) are reserved for RFC 2434 367 Private Use. 369 Authors' Addresses 371 Stefan Santesson 372 Microsoft 373 Finlandsgatan 30 374 164 93 KISTA 375 Sweden 377 EMail: stefans(at)microsoft.com 379 Ari Medvinsky 380 Microsoft 381 One Microsoft Way 382 Redmond, WA 98052-6399 383 USA 385 Email: arimed(at)microsoft.com 387 Joshua Ball 388 Microsoft 389 One Microsoft Way 390 Redmond, WA 98052-6399 391 USA 393 Email: joshball(at)microsoft.com 395 Acknowledgements 397 The authors extend a special thanks to Russ Housley, Eric Resocorla 398 and Paul Leach for their substantial contributions. 400 Disclaimer 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 405 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 406 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 407 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 Copyright Statement 412 Copyright (C) The Internet Society (2006). 414 This document is subject to the rights, licenses and restrictions 415 contained in BCP 78, and except as set forth therein, the authors 416 retain all their rights. 418 Expires October 2006