idnits 2.17.1 draft-santesson-tls-supp-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 288. ** 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 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: 'STDWORDS' is mentioned on line 65, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 225, but not defined == Unused Reference: 'N1' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'N4' is defined on line 244, 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 2434 (ref. 'N5') (Obsoleted by RFC 5226) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 4 Intended Category: Standards track 5 Expires October 2006 April 2006 7 TLS Handshake Message for Supplemental Data 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 specification specifies a TLS handshake message for exchange of 36 supplemental application data. TLS hello message extensions are used 37 to determine which supplemental data types are supported by both the 38 TLS client and the TLS server. Then, the supplemental data handshake 39 message is used to exchange the data. Other documents will define 40 the syntax of these extensions and the syntax of the associated 41 supplemental data types. 43 1. Introduction 45 Recent standards activities have proposed different mechanisms for 46 transmitting supplemental application data in the TLS handshake 47 message. For example, recent proposals transfer data that is not 48 processed by the TLS protocol itself, but assist the TLS-protected 49 application in the authentication and authorization decisions. One 50 proposal transfers user name hints for locating credentials, and 51 another proposal transfers attribute certificates and SAML assertions 52 for authorization checks. 54 In order to avoid definition of multiple handshake messages, one for 55 each new type of application specific supplemental data, this 56 specification defines a new handshake message type that bundles all 57 data objects, that are to be delivered to the TLS-protected 58 application, together and sends them in a single handshake message. 60 1.1 Terminology 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [STDWORDS]. 66 The syntax for the supplemental_data handshake message is defined 67 using the TLS Presentation Language, which is specified in Section 4 68 of [N2]. 70 2 Supplemental Data Handshake Message 72 The new supplemental_data handshake message type is defined to 73 accommodate communication of supplemental data objects as agreed 74 during the exchange of extensions in the client and server hello 75 messages. See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3] 76 for other handshake message types. 78 Information provided in a supplemental data object MUST be intended 79 to be used exclusively by applications and protocols above the TLS 80 protocol layer. Any such data MUST NOT need to be processed by the 81 TLS protocol. 83 enum { 84 supplemental_data(TBD), (255) 85 } HandshakeType; 87 struct { 88 HandshakeType msg_type; /* handshake type */ 89 uint24 length; /* octets in message */ 90 select (HandshakeType) { 91 case supplemental_data: SupplementalData; 92 } body; 93 } Handshake; 95 struct { 96 SupplementalDataEntry supp_data<1..2^24-1>; 97 } SupplementalData; 99 struct { 100 SupplementalDataType supp_data_type; 101 select(SupplementalDataType) { } 102 } SupplementalDataEntry; 104 enum { 105 (65535) 106 } SupplementalDataType; 108 The client MUST NOT send more than one SupplementalData handshake 109 message, and the server MUST NOT send more than one SupplementalData 110 handshake message. Receiving more than one SupplementalData 111 handshake message results in a fatal error, and the receiver MUST 112 close the connection with a fatal unexpected_message alert. 114 If present, the SupplementalData handshake message MUST contain a 115 non-empty SupplementalDataEntry structure carrying data associated 116 with at least one defined SupplementalDataType. An explicit 117 agreement that governs presence of any supplemental data MUST be 118 concluded between client and server for each SupplementalDataType 119 using the TLS extensions in the client and server hello messages. 120 Receiving an unexpected SupplementalData handshake message results in 121 a fatal error, and the receiver MUST close the connection with a 122 fatal unexpected_message alert. 124 Other documents will specify specific SupplementalDataType and their 125 associated data syntax and processing. These same specifications 126 must also specify the client and server hello message extensions that 127 are used to negotiate the support for the specified supplemental data 128 type. This document simply specifies the TLS Handshake Protocol 129 message that will carry the supplemental data objects. 131 Different situations require the transfer of supplemental data from 132 the client to the server, require the transfer of supplemental data 133 from server to the client, or require the transfer of supplemental 134 data from the client to the server as well as the transfer from the 135 server to the client. All three situations are fully supported. 137 4 Message flow 139 The SupplementalData handshake message, if exchanged, MUST be sent as 140 the first handshake message as illustrated in Figure 1 below. 142 Client Server 144 ClientHello (with extensions) --------> 146 ServerHello(with extensions) 147 SupplementalData* 148 Certificate* 149 ServerKeyExchange* 150 CertificateRequest* 151 <-------- ServerHelloDone 153 SupplementalData* 154 Certificate* 155 ClientKeyExchange 156 CertificateVerify* 157 [ChangeCipherSpec] 158 Finished --------> 159 [ChangeCipherSpec] 160 <-------- Finished 161 Application Data <-------> Application Data 163 * Indicates optional or situation-dependent messages. 165 Figure 1. Message flow with SupplementalData 167 5 Security Considerations 169 Each SupplementalDataType included in the handshake message defined 170 in this specification introduces its own unique set of security 171 properties and related considerations. Security considerations must 172 therefore be defined in each document that defines a supplemetal data 173 type. 175 In some cases the SupplementalData information may be sensitive. The 176 double handshake technique can be used to provide protection for the 177 SupplementalData information. Figure 2 illustrates the double 178 handshake, where the initial handshake does not include any 179 extensions, but it does result in protected communications. Then, a 180 second handshake that includes the SupplementalData information is 181 performed using the protected communications. In Figure 2, the 182 number on the right side indicates the amount of protection for the 183 TLS message on that line. A zero (0) indicates that there is no 184 communication protection; a one (1) indicates that protection is 185 provided by the first TLS session; and a two (2) indicates that 186 protection is provided by both TLS sessions. 188 The placement of the SupplementalData message in the TLS Handshake 189 results in the server providing its SupplementalData information 190 before the client is authenticated. In many situations, servers will 191 not want to provide authorization information until the client is 192 authenticated. The double handshake illustrated in Figure 2 provides 193 a technique to ensure that the parties are mutually authenticated 194 before either party provides SupplementalData information. 196 Client Server 198 ClientHello (no extensions) --------> |0 199 ServerHello (no extensions) |0 200 Certificate* |0 201 ServerKeyExchange* |0 202 CertificateRequest* |0 203 <-------- ServerHelloDone |0 204 Certificate* |0 205 ClientKeyExchange |0 206 CertificateVerify* |0 207 [ChangeCipherSpec] |0 208 Finished --------> |1 209 [ChangeCipherSpec] |0 210 <-------- Finished |1 211 ClientHello (w/ extensions) --------> |1 212 ServerHello (w/ extensions) |1 213 SupplementalData* |1 214 Certificate* |1 216 ServerKeyExchange* |1 217 CertificateRequest* |1 218 <-------- ServerHelloDone |1 219 SupplementalData* |1 220 Certificate* |1 221 ClientKeyExchange |1 222 CertificateVerify* |1 223 [ChangeCipherSpec] |1 224 Finished --------> |2 225 [ChangeCipherSpec] |1 226 <-------- Finished |2 227 Application Data <-------> Application Data |2 229 * Indicates optional or situation-dependent messages. 231 Figure 2. Double Handshake to Protect Supplemental Data 233 6 Normative References 235 [N1] S. Bradner, "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 239 RFC 2246, January 1999. 241 [N3] T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1", 242 RFC 4346, January 2006. 244 [N4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, 245 T. Wright, "Transport Layer Security (TLS) Extensions", 246 RFC 4366, February 2006. 248 [N5] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 249 Considerations Section in RFCs", RFC 2434, October 1998 251 7 IANA Considerations 253 IANA needs to take the following actions: 255 1) Create an entry, supplemental_data(TBD), in the existing registry 256 for HandshakeType (defined in RFC 2246 [N2]). 258 2) Establish a registry for TLS Supplemental Data Formats 259 (SupplementalDataType). Values in the inclusive range 0-16385 260 (decimal) are assigned via RFC 2434 [N5] Standards Action. Values 261 from the inclusive range 16386-65279 (decimal) are assigned via RFC 262 2434 IETF Consensus. Values from the inclusive range 65280-65535 263 (decimal) are reserved for RFC 2434 Private Use. 265 Author's Address 267 Stefan Santesson 268 Microsoft 269 Finlandsgatan 30 270 164 93 KISTA 271 Sweden 273 EMail: stefans(at)microsoft.com 275 Acknowledgements 277 The fundamental architectural idea for the supplemental data 278 handshake message was provided by Russ Housley and Eric Rescorla. 280 Disclaimer 282 This document and the information contained herein are provided on an 283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 285 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 286 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 287 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 Copyright Statement 292 Copyright (C) The Internet Society (2006). 294 This document is subject to the rights, licenses and restrictions 295 contained in BCP 78, and except as set forth therein, the authors 296 retain all their rights. 298 Expires October 2006