idnits 2.17.1 draft-ietf-tls-applayerprotoneg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2013) is 4020 days in the past. Is this intentional? 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 191, but not defined == Unused Reference: 'RFC3264' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'I-D.mbelshe-httpbis-spdy' is defined on line 325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-02 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S.F. Friedl 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Popov 5 Expires: October 27, 2013 Microsoft Corp. 6 A. Langley 7 Google Inc. 8 E. Stephan 9 France Telecom - Orange 10 April 25, 2013 12 Transport Layer Security (TLS) Application Layer Protocol Negotiation 13 Extension 14 draft-ietf-tls-applayerprotoneg-01 16 Abstract 18 This document describes a Transport Layer Security (TLS) extension 19 for application layer protocol negotiation within the TLS handshake. 20 For instances in which the TLS connection is established over a well 21 known TCP/IP port not associated with the desired application layer 22 protocol, this extension allows the application layer to negotiate 23 which protocol will be used within the TLS session. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 27, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Application Layer Protocol Negotiation . . . . . . . . . . . 3 62 3.1. The Application Layer Protocol Negotiation Extension . . 3 63 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 5 64 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Increasingly, application layer protocols are encapsulated in the TLS 76 security protocol [RFC5246]. This encapsulation enables applications 77 to use the existing, secure communications links already present on 78 port 443 across virtually the entire global IP infrastructure. 80 When multiple application protocols are supported on a single server- 81 side port number, such as port 443, the client and the server need to 82 negotiate an application protocol for use with each connection. It 83 is desirable to accomplish this negotiation without adding network 84 round-trips between the client and the server, as each round-trip 85 will degrade an end-user's experience. Further, it would be 86 advantageous to allow certificate selection based on the negotiated 87 application protocol. 89 This document specifies a TLS extension which permits the application 90 layer to negotiate protocol selection within the TLS handshake. This 91 work was requested by the HTTPbis WG to address the negotiation of 92 HTTP version ([RFC2616], [I-D.ietf-httpbis-http2]) over TLS, however 93 ALPN facilitates negotiation of arbitrary application layer 94 protocols. 96 With ALPN, the client sends the list of supported application 97 protocols as part of the TLS ClientHello message. The server chooses 98 a protocol and sends the selected protocol as part of the TLS 99 ServerHello message. The application protocol negotiation can thus 100 be accomplished within the TLS handshake, without adding network 101 round-trips, and allows the server to associate a different 102 certificate with each application protocol, if desired. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Application Layer Protocol Negotiation 112 3.1. The Application Layer Protocol Negotiation Extension 114 A new extension type ("application_layer_protocol_negotiation(16)") 115 is defined and MAY be included by the client in its "ClientHello" 116 message. 118 enum { 119 application_layer_protocol_negotiation(16), (65535) 120 } ExtensionType; 122 The "extension_data" field of the 123 ("application_layer_protocol_negotiation(16)") extension SHALL 124 contain a "ProtocolNameList" value. 126 opaque ProtocolName<1..2^8-1>; 128 struct { 129 ProtocolName protocol_name_list<2..2^16-1> 130 } ProtocolNameList; 132 "ProtocolNameList" contains the list of protocols advertised by the 133 client, in descending order of preference. Protocols are named by 134 IANA registered, opaque, non-empty byte strings, as described further 135 in Section 6 "IANA Considerations" of this document. Implementations 136 MUST ensure that an empty string is not included and that no byte 137 strings are truncated. 139 Experimental protocol names, which are not registered by IANA, will 140 start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). 142 Servers that receive a client hello containing the 143 "application_layer_protocol_negotiation" extension, MAY return a 144 suitable protocol selection response to the client. The server will 145 ignore any protocol name that it does not recognize. A new 146 ServerHello extension type 147 ("application_layer_protocol_negotiation(16)") MAY be returned to the 148 client within the extended ServerHello message. The "extension_data" 149 field of the ("application_layer_protocol_negotiation(16)") extension 150 SHALL be structured the same as described above for the client 151 "extension_data", except that the "ProtocolNameList" MUST contain 152 exactly one "ProtocolName". 154 Therefore, a full handshake with the 155 "application_layer_protocol_negotiation" extension in the ClientHello 156 and ServerHello messages has the following flow (contrast with 157 section 7.3 of [RFC5246]): 159 Client Server 161 ClientHello --------> ServerHello 162 (ALPN extension & (ALPN extension & 163 list of protocols) selected protocol) 164 Certificate* 165 ServerKeyExchange* 166 CertificateRequest* 167 <-------- ServerHelloDone 168 Certificate* 169 ClientKeyExchange 170 CertificateVerify* 171 [ChangeCipherSpec] 172 Finished --------> 173 [ChangeCipherSpec] 174 <-------- Finished 175 Application Data <-------> Application Data 177 Figure 1 179 An abbreviated handshake with the 180 "application_layer_protocol_negotiation" extension has the following 181 flow: 183 Client Server 185 ClientHello --------> ServerHello 186 (ALPN extension & (ALPN extension & 187 list of protocols) selected protocol) 188 [ChangeCipherSpec] 189 <-------- Finished 191 [ChangeCipherSpec] 192 Finished --------> 193 Application Data <-------> Application Data 195 Figure 2 197 Unlike many other TLS extensions, this extension does not establish 198 properties of the session, only of the connection. When session 199 resumption or session tickets [RFC5077] are used, the previous 200 contents of this extension are irrelevant and only the values in the 201 new handshake messages are considered. 203 3.2. Protocol Selection 205 It is expected that a server will have a list of protocols that it 206 supports, in preference order, and will only select a protocol if the 207 client supports it. In that case, the server SHOULD select the most 208 highly preferred protocol it supports which is also advertised by the 209 client. In the event that the server supports no protocols that the 210 client advertises, then the server SHALL respond with a fatal 211 "no_application_protocol" alert. 213 enum { 214 no_application_protocol(120), 215 (255) 216 } AlertDescription; 218 The "no_application_protocol" fatal alert is only defined for the 219 "application_layer_protocol_negotiation" extension and MUST NOT be 220 sent unless the server has received a ClientHello message containing 221 this extension. 223 The protocol identified in the 224 "application_layer_protocol_negotiation" extension type in the 225 ServerHello SHALL be definitive for the connection. The server SHALL 226 NOT respond with a selected protocol and subsequently use a different 227 protocol for application data exchange. 229 4. Design Considerations 231 The ALPN extension is intended to follow the typical design of TLS 232 protocol extensions. Specifically, the negotiation is performed 233 entirely within the client/server hello exchange in accordance with 234 established TLS architecture. The 235 "application_layer_protocol_negotiation" ServerHello extension is 236 intended to be definitive for the connection and is sent in plaintext 237 to permit network elements to provide differentiated service for the 238 connection when the TCP/IP port number is not definitive for the 239 application layer protocol to be used in the connection. By placing 240 ownership of protocol selection on the server, ALPN facilitates 241 scenarios in which certificate selection or connection rerouting may 242 be based on the negotiated protocol. 244 Finally, by managing protocol selection in the clear as part of the 245 handshake, ALPN avoids introducing false confidence with respect to 246 the the ability to hide the negotiated protocol in advance of 247 establishing the connection. If hiding the protocol is required, 248 then renegotiation after connection establishment, which would 249 provide true TLS security guarantees, would be a preferred 250 methodology. 252 A namespace will be assigned for experimental protocols, comprising 253 byte strings which start with the following sequence of bytes: 0x65, 254 0x78, 0x70 ("exp"). Assignments in this namespace do not need IANA 255 registration. 257 5. Security Considerations 259 The ALPN extension does not impact the security of TLS session 260 establishment or application data exchange. ALPN serves to provide 261 an externally visible marker for the application layer protocol 262 associated with the TLS connection. Historically, the application 263 layer protocol associated with a connection could be ascertained from 264 the TCP/IP port number in use. 266 6. IANA Considerations 268 The IANA has updated its Registry of TLS ExtensionType Values to 269 include the following entry: 271 - 16 application_layer_protocol_negotiation 273 This document also requires the IANA to create a registry of 274 Application Layer Protocol Negotiation protocol byte strings, 275 initially containing the following entries: 277 - "http/1.1": HTTP/1.1 [RFC2616]; 279 - "http/2.0": HTTP/2.0 [I-D.ietf-httpbis-http2]; 281 - "spdy/1": (obsolete) SPDY version 1; 283 - "spdy/2": SPDY version 2; 285 - "spdy/3": SPDY version 3. 287 We propose that this new registry be created in a new page entitled: 288 "Application Layer Protocol Negotiation (ALPN) Protocol IDs" beneath 289 the existing heading of "Transport Layer Security (TLS)". 291 7. Acknowledgements 293 This document benefitted specifically from the NPN extension draft 294 authored by Adam Langley and from discussions with Tom Wesselman and 295 Cullen Jennings both of Cisco. 297 8. References 299 8.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 305 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 306 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 308 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 309 with Session Description Protocol (SDP)", RFC 3264, June 310 2002. 312 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 313 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 315 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 316 Extension Definitions", RFC 6066, January 2011. 318 8.2. Informative References 320 [I-D.ietf-httpbis-http2] 321 Belshe, M., Peon, R., Thomson, M., and A. Melnikov, 322 "Hypertext Transfer Protocol version 2.0", draft-ietf- 323 httpbis-http2-02 (work in progress), April 2013. 325 [I-D.mbelshe-httpbis-spdy] 326 Belshe, M. and R. Peon, "SPDY Protocol", draft-mbelshe- 327 httpbis-spdy-00 (work in progress), February 2012. 329 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 330 "Transport Layer Security (TLS) Session Resumption without 331 Server-Side State", RFC 5077, January 2008. 333 Authors' Addresses 334 Stephan Friedl 335 Cisco Systems, Inc. 336 170 West Tasman Drive 337 San Jose, CA 95134 338 USA 340 Phone: (720)562-6785 341 Email: sfriedl@cisco.com 343 Andrei Popov 344 Microsoft Corp. 345 One Microsoft Way 346 Redmond, WA 98052 347 USA 349 Email: andreipo@microsoft.com 351 Adam Langley 352 Google Inc. 353 USA 355 Email: agl@google.com 357 Emile Stephan 358 France Telecom - Orange 359 2 avenue Pierre Marzin 360 Lannion F-22307 361 France 363 Email: emile.stephan@orange.com