idnits 2.17.1 draft-santesson-tls-ume-07.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 429. ** 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 (May 2006) is 6553 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 235, but not defined == Unused Reference: 'N5' is defined on line 359, 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 November 2006 May 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 in an 38 informative section, the UpnDomainHint, which may be used by a server 39 to locate a user in a directory database. Other mapping hints may be 40 defined in other 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 ................................................ 6 51 5 Security Considerations ..................................... 8 52 6 UPN domain hint (Informative) ............................... 9 53 7 References .................................................. 10 54 8 IANA Considerations ......................................... 10 55 Authors' Addresses ............................................. 11 56 Acknowledgements ............................................... 11 57 Disclaimer ..................................................... 12 58 Copyright Statement ............................................ 12 60 1. Introduction 62 This document has a normative part and an informative part. Sections 63 2-5 are normative. Section 6 is informative. 65 This specification defines a TLS extension and a payload for the 66 SupplementalData handshake message, defined in RFC TBD [N6], to 67 accommodate mapping of users to their user accounts when using TLS 68 client authentication as the authentication method. 70 The new TLS extension (user_mapping) is sent in the client hello 71 message. Per convention defined in RFC 4366 [N4], the server places 72 the same extension (user_mapping) in the server hello message, to 73 inform the client that the server understands this extension. If the 74 server does not understand the extension, it will respond with a 75 server hello omitting this extension and the client will proceed as 76 normal, ignoring the extension, and not include the 77 UserMappingDataList data in the TLS handshake. 79 If the new extension is understood, the client will inject 80 UserMappingDataList data in the SupplementalData handshake message 81 prior to the Client's Certificate message. The server will then parse 82 this message, extracting the client's domain, and store it in the 83 context for use when mapping the certificate to the user's directory 84 account. 86 No other modifications to the protocol are required. The messages are 87 detailed in the following sections. 89 1.1 Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [N1]. 95 The syntax for the TLS User Mapping extension is defined using the 96 TLS Presentation Language, which is specified in Section 4 of [N2]. 98 1.2 Design considerations 100 The reason the mapping data itself is not placed in the extension 101 portion of the client hello is to prevent broadcasting this 102 information to servers that don't understand the extension. 104 2 User mapping extension 106 A new extension type (user_mapping(TBD)) is added to the Extension 107 used in both the client hello and server hello messages. The 108 extension type is specified as follows. 110 enum { 111 user_mapping(TBD), (65535) 112 } ExtensionType; 114 The "extension_data" field of this extension SHALL contain 115 "UserMappingTypeList" with a list of supported hint types where: 117 struct { 118 UserMappingType user_mapping_types<1..2^8-1> 119 } UserMappingTypeList; 121 Enumeration of hint types (user_mapping_types) defined in this 122 document is provided in section 3. 124 The list of user_mapping_types included in a client hello SHALL 125 signal the hint types supported by the client. The list of 126 user_mapping_types included in the server hello SHALL signal the hint 127 types preferred by the server. 129 If none of the hint types listed by the client is supported by the 130 server, the server SHALL omit the user_mapping extension in the 131 server hello. 133 When the user_mapping extension is included in the server hello, the 134 list of hint types in "UserMappingTypeList" SHALL be either equal to, 135 or a subset of, the list provided by the client. 137 3 User mapping handshake exchange 139 The underlying structure of the SupplementalData handshake message, 140 used to carry information defined in this section, is defined in RFC 141 TBD [N6]. 143 A new SupplementalDataType [N6] is defined to accommodate 144 communication of generic user mapping data. See RFC 2246 (TLS 1.0) 145 [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types. 147 The information in this data type carries one or more unauthenticated 148 hints, UserMappingDataList, inserted by the client side. Upon receipt 149 and successful completion of the TLS handshake, the server MAY use 150 this hint to locate the user's account from which user information 151 and credentials MAY be retrieved to support authentication based on 152 the client certificate. 154 struct { 155 SupplementalDataType supp_data_type; 156 select(SupplementalDataType) { 157 case user_mapping_data: UserMappingDataList; 158 } 159 } SupplementalDataEntry; 161 enum { 162 user_mapping_data(TBD), (65535) 163 } SupplementalDataType; 165 The user_mapping_data(TBD) enumeration results in a new supplemental 166 data type UserMappingDataList with the following structure: 168 enum { 169 (255) 170 } UserMappingType; 172 struct { 173 UserMappingType user_mapping_version 174 select(UserMappingType) { } 175 } UserMappingData; 177 struct{ 178 UserMappingData user_mapping_data_list<1..2^16-1>; 179 }UserMappingDataList; 181 The UserMappingData structure contains a single mapping of type 182 UserMappingType. This structure can be leveraged to define new types 183 of user mapping hints in the future. The UserMappingDataList MAY 184 carry multiple hints; it is defined as a vector of UserMappingData 185 structures. 187 No preference is given to the order in which hints are specified in 188 this vector. If the client sends more then one hint then the Server 189 SHOULD use the applicable mapping supported by the server. 191 Implementations MAY support the UPN domain hint as specified in 192 section 6 of this document. Implementations MAY also support other 193 user mapping types as they are defined. Definitions of standards- 194 track user mapping types must include a discussion of 195 internationalization considerations. 197 4 Message flow 199 In order to negotiate to send user mapping data to a server in 200 accordance with this specification, clients MUST include an extension 201 of type "user_mapping" in the (extended) client hello, which SHALL 202 contain a list of supported hint types. 204 Servers that receive an extended client hello containing a 205 "user_mapping" extension, MAY indicate that they are willing to 206 accept user mapping data by including an extension of type 207 "user_mapping" in the (extended) server hello, which SHALL contain a 208 list of preferred hint types. 210 After negotiation of the use of user mapping has been successfully 211 completed (by exchanging hello messages including "user_mapping" 212 extensions), clients MAY send a "SupplementalData" message containing 213 the "UserMappingDataList" before the "Certificate" message. The 214 message flow is illustrated in Fig. 1 below. 216 Client Server 218 ClientHello 219 /* with user_mapping ext */ --------> 221 ServerHello 222 /* with user-mapping ext */ 223 Certificate* 224 ServerKeyExchange* 225 CertificateRequest* 226 <-------- ServerHelloDone 228 SupplementalData 229 /* with UserMappingDataList */ 230 Certificate* 231 ClientKeyExchange 232 CertificateVerify* 233 [ChangeCipherSpec] 234 Finished --------> 235 [ChangeCipherSpec] 236 <-------- Finished 237 Application Data <-------> Application Data 239 Fig. 1 - Message flow with user mapping data 241 * Indicates optional or situation-dependent messages that are not 242 always sent according to RFC 2246 [N2] and RFC 4346 [N3]. 244 The server MUST expect and gracefully handle the case where the 245 client chooses to not send any supplementalData handshake message 246 even after successful negotiation of extensions. The client MAY at 247 its own discretion decide that the user mapping hint it initially 248 intended to send no longer is relevant for this session. One such 249 reason could be that the server certificate fails to meet certain 250 requirements. 252 5 Security Considerations 254 The user mapping hint sent in the UserMappingDataList is 255 unauthenticated data that MUST NOT be treated as a trusted 256 identifier. Authentication of the user represented by that user 257 mapping hint MUST rely solely on validation of the client 258 certificate. One way to do this is to use the user mapping hint to 259 locate and extract a certificate of the claimed user from the trusted 260 directory and subsequently match this certificate against the 261 validated client certificate from the TLS handshake. 263 As the client is the initiator of this TLS extension, it needs to 264 determine when it is appropriate to send the User Mapping 265 Information. It may not be prudent to broadcast a user mapping hint 266 to just any server at any time. 268 To avoid superfluously sending user mapping hints, clients SHOULD 269 only send this information if it recognizes the server as a 270 legitimate recipient. Recognition of the server can be done in many 271 ways. One way to do this could be to recognize the name and address 272 of the server. 274 In some cases, the user mapping hint may itself be regarded as 275 sensitive. In such case the double handshake technique described in 276 [N6] can be used to provide protection for the user mapping hint 277 information. 279 6 UPN domain hint (Informative) 281 This specification provides informative description of one user 282 mapping hint type for Domain Name hints and User Principal Name 283 hints. Other hint types may be defined in other documents in the 284 future. 286 The User Principal Name (UPN) in this hint type represents a name 287 which specifies a user's entry in a directory in the form 288 userName@domainName. Traditionally Microsoft has relied on such name 289 form to be present in the client certificate when logging on to a 290 domain account. This has however several drawbacks since it prevents 291 the use of certificates with an absent UPN and also requires re- 292 issuance of certificates or issuance of multiple certificates to 293 reflect account changes or creation of new accounts. The TLS 294 extension in combination with the defined hint type provide a 295 significant improvement to this situation as it allows a single 296 certificate to be mapped to one or more accounts of the user and does 297 not require the certificate to contain a UPN. 299 The domain_name field MAY be used when only domain information is 300 needed, e.g. where a user have accounts in multiple domains using the 301 same username name, where that user name is known from another source 302 (e.g. from the client certificate). When the user name is also 303 needed, the user_principal_name field MAY be used to indicate both 304 username and domain name. If both fields are present, then the server 305 can make use of whichever one it chooses. 307 enum { 308 upn_domain_hint(64), (255) 309 } UserMappingType; 311 struct { 312 opaque user_principal_name<0..2^16-1>; 313 opaque domain_name<0..2^16-1>; 314 } UpnDomainHint; 316 struct { 317 UserMappingType user_mapping_version 318 select(UserMappingType) { 319 case upn_domain_hint: 320 UpnDomainHint; 321 } 322 } UserMappingData; 324 The user_principal_name field, when specified, SHALL be of the form 325 "user@domain", where "user" is a UTF-8 encoded Unicode string that 326 does not contain the "@" character, and "domain" is a domain name 327 meeting the requirements in the following paragraph. 329 The domain_name field, when specified, SHALL contain a domain name in 330 the usual text form: in other words, a sequence of one or more domain 331 labels separated by ".", each domain label starting and ending with 332 an alphanumeric character and possibly also containing "-" 333 characters. This field is an "IDN-unaware domain name slot" as 334 defined in RFC 3490 [N7] and therefore, domain names containing non- 335 ASCII characters have to be processed as described in RFC 3490 before 336 being stored in this field. 338 The UpnDomainHint MUST at least contain a non empty 339 user_principal_name or a non empty domain_name. The UpnDomainHint MAY 340 contain both user_principal_name and domain_name. 342 6 References 344 Normative references: 346 [N1] S. Bradner, "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 350 RFC 2246, January 1999. 352 [N3] T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1", 353 RFC 4346, January 2006. 355 [N4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, 356 T. Wright, "Transport Layer Security (TLS) Extensions", 357 RFC 4366, February 2006. 359 [N5] Mockapetris, P., "Domain Names - Concepts and 360 Facilities", STD 13, RFC 1034, November 1987. 362 [N6] S. Santesson, "TLS Handshake Message for Supplementary 363 Data", RFC TBD (currently: draft-santesson-tls-supp-02, 364 Date 2006. 366 [N7] P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing 367 Domain Names in Applications (IDNA)", RFC 3490, March 2003 369 [N8] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 370 Considerations Section in RFCs", RFC 2434, October 1998 372 7 IANA Considerations 374 IANA needs to take the following actions: 376 1) Create an entry, user_mapping(TBD), in the existing registry for 377 ExtensionType (defined in RFC 4366 [N4]). 379 2) Create an entry, user_mapping_data(TBD), in the new registry for 380 SupplementalDataType (defined in draft-santesson-tls-supp-02). 382 3) Establish a registry for TLS UserMappingType values. The first 383 entry in the registry is upn_domain_hint(64). TLS UserMappingType 384 values in the inclusive range 0-63 (decimal) are assigned via RFC 385 2434 [N8] Standards Action. Values from the inclusive range 64-223 386 (decimal) are assigned via RFC 2434 Specification Required. Values 387 from the inclusive range 224-255 (decimal) are reserved for RFC 2434 388 Private Use. 390 Authors' Addresses 392 Stefan Santesson 393 Microsoft 394 Finlandsgatan 30 395 164 93 KISTA 396 Sweden 398 EMail: stefans(at)microsoft.com 400 Ari Medvinsky 401 Microsoft 402 One Microsoft Way 403 Redmond, WA 98052-6399 404 USA 406 Email: arimed(at)microsoft.com 408 Joshua Ball 409 Microsoft 410 One Microsoft Way 411 Redmond, WA 98052-6399 412 USA 414 Email: joshball(at)microsoft.com 416 Acknowledgements 418 The authors extend a special thanks to Russ Housley, Eric Resocorla 419 and Paul Leach for their substantial contributions. 421 Disclaimer 423 This document and the information contained herein are provided on an 424 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 425 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 426 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 427 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 428 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 429 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Copyright Statement 433 Copyright (C) The Internet Society (2006). 435 This document is subject to the rights, licenses and restrictions 436 contained in BCP 78, and except as set forth therein, the authors 437 retain all their rights. 439 Expires November 2006