idnits 2.17.1 draft-ietf-tls-applayerprotoneg-00.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 05, 2013) is 4038 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 201, but not defined == Missing Reference: 'RFC2616' is mentioned on line 292, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Unused Reference: 'RFC6066' is defined on line 326, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 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.P. Popov 5 Expires: October 07, 2013 Microsoft Corp. 6 April 05, 2013 8 Transport Layer Security (TLS) Application Layer Protocol Negotiation 9 Extension 10 draft-ietf-tls-applayerprotoneg-00 12 Abstract 14 This document describes a Transport Layer Security (TLS) extension 15 for application layer protocol negotiation within the TLS handshake. 16 For instances in which the TLS connection is established over a well 17 known TCP/IP port not associated with the desired application layer 18 protocol, this extension allows the application layer to negotiate 19 which protocol will be used within the TLS session. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 07, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Application Layer Protocol Negotiation . . . . . . . . . . . 3 58 3.1. The Application Layer Protocol Negotiation Extension . . 3 59 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 5 60 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Currently, the Next Protocol Negotiation extension (NPN) is used to 72 establish a SPDY [spdy] protocol session within a TLS RFC 5246 73 [RFC5246] session on port 443. NPN is not specific to SPDY and can 74 be used to negotiate sessions for a wide variety of protocols within 75 the TLS handshake. 77 NPN seeks to provide a reliable mechanism for application developers 78 to establish secure sessions for arbitrary protocols without 79 interference from firewalls, HTTP proxies and MITM proxies. It 80 addresses this goal by introducing a protocol negotiation process 81 into the TLS handshake under the constraints that no additional 82 roundtrips be added to the handshake and that the final protocol 83 selection be opaque to the network carrying the TLS session. Within 84 the NPN extension, it is the server that first generates and 85 transmits an offer of supported protocols to the client. The offer 86 is sent as part of the TLS ServerHello message before the 87 [ChangeCipherSpec] subprotocol has been started, therefore the list 88 of protocols supported by the server is transmitted in plaintext. 89 The client chooses a protocol which may or may not appear in the 90 offer from the server and then responds with the definitive protocol 91 selection answer. The client response is sent after the 92 [ChangeCipherSpec] subprotocol has been initiated, so the protocol 93 selected is encrypted in the client response. 95 In many other application layer protocol negotiation processes, it is 96 the client that first sends an offer of protocols it supports to the 97 server. The server then selects the protocol to be used in the 98 session and includes this answer in the response. RFC 3264 [RFC3264] 99 describes a SDP based offer/answer model which is not proscriptive in 100 terms of which party generates the offer, however in practice it is 101 typically the client generating the offer and the server replying 102 with the answer. This permits the server to act as the definitive 103 entity for selection of the application layer protocol. 105 This draft proposes an alternative formulation of the NPN protocol 106 which 1) brings the offer/answer negotiation into alignment with the 107 majority of other application layer protocol negotiation standards, 108 2) allows certificate selection based on the application protocol and 109 3) makes the definitive protocol selection answer from the server 110 visible to the network, when the parties so desire. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Application Layer Protocol Negotiation 120 3.1. The Application Layer Protocol Negotiation Extension 122 A new extension type ("application_layer_protocol_negotiation(16)") 123 is defined and MAY be included by the client in its "ClientHello" 124 message. 126 enum { 127 application_layer_protocol_negotiation(16), (65535) 128 } ExtensionType; 130 The "extension_data" field of the 131 ("application_layer_protocol_negotiation(16)") extension SHALL 132 contain a "ProtocolNameList" value. 134 opaque ProtocolName<1..2^8-1>; 136 struct { 137 ProtocolName protocol_name_list<2..2^16-1> 138 } ProtocolNameList; 140 "ProtocolNameList" contains the list of protocols advertised by the 141 client, in descending order of preference. Protocols are named by 142 IANA registered, opaque, non-empty byte strings. Implementations 143 MUST ensure that an empty string is not included and that no byte 144 strings are truncated. 146 Experimental protocol names, which are not registered by IANA, will 147 start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). 149 Servers that receive a client hello containing the 150 "application_layer_protocol_negotiation" extension, MAY return a 151 suitable protocol selection response to the client. The server will 152 ignore any protocol name that it does not recognize. A new 153 ServerHello extension type 154 ("application_layer_protocol_negotiation(16)") MAY be returned to the 155 client within the extended ServerHello message. The "extension_data" 156 field of the ("application_layer_protocol_negotiation(16)") extension 157 SHALL be structured the same as described above for the client 158 "extension_data", except that the "ProtocolNameList" MUST contain 159 exactly one "ProtocolName". 161 The additional content associated with this extension MUST be 162 included in the hash calculations associated with the "Finished" 163 messages. 165 Therefore, a full handshake with the 166 "application_layer_protocol_negotiation" extension in the ClientHello 167 and ServerHello messages has the following flow (contrast with 168 section 7.3 of RFC 5246 [RFC5246]): 170 Client Server 172 ClientHello --------> ServerHello 173 (ALPN extension & (ALPN extension & 174 list of protocols) selected protocol) 175 Certificate* 176 ServerKeyExchange* 177 CertificateRequest* 178 <-------- ServerHelloDone 179 Certificate* 180 ClientKeyExchange 181 CertificateVerify* 182 [ChangeCipherSpec] 183 Finished --------> 184 [ChangeCipherSpec] 185 <-------- Finished 186 Application Data <-------> Application Data 188 Figure 1 190 An abbreviated handshake with the 191 "application_layer_protocol_negotiation" extension has the following 192 flow: 194 Client Server 196 ClientHello --------> ServerHello 197 (ALPN extension & (ALPN extension & 198 list of protocols) selected protocol) 199 [ChangeCipherSpec] 200 <-------- Finished 201 [ChangeCipherSpec] 202 Finished --------> 203 Application Data <-------> Application Data 205 Figure 2 207 Unlike many other TLS extensions, this extension does not establish 208 properties of the session, only of the connection. When session 209 resumption or session tickets RFC 5077 [RFC5077] are used, the 210 previous contents of this extension are irrelevant and only the 211 values in the new handshake messages are considered. 213 3.2. Protocol Selection 215 It is expected that a server will have a list of protocols that it 216 supports, in preference order, and will only select a protocol if the 217 client supports it. In that case, the server SHOULD select the most 218 highly preferred protocol it supports which is also advertised by the 219 client. In the event that the server supports no protocols that the 220 client advertises, then the server SHALL respond with a fatal 221 "no_application_protocol" alert. 223 enum { 224 no_application_protocol(120), 225 (255) 226 } AlertDescription; 228 The "no_application_protocol" fatal alert is only defined for the 229 "application_layer_protocol_negotiation" extension and MUST NOT be 230 sent unless the server has received a ClientHello message containing 231 this extension. 233 The protocol identified in the 234 "application_layer_protocol_negotiation" extension type in the 235 ServerHello SHALL be definitive for the connection. The server SHALL 236 NOT respond with a selected protocol and subsequently use a different 237 protocol for application data exchange. 239 4. Design Considerations 241 The ALPN extension is intended to follow the typical design of TLS 242 protocol extensions. Specifically, the negotiation is performed 243 entirely within the client/server hello exchange in accordance with 244 established TLS architecture. The 245 "application_layer_protocol_negotiation" ServerHello extension is 246 intended to be definitive for the connection and is sent in plaintext 247 to permit network elements to provide differentiated service for the 248 connection when the TCP/IP port number is not definitive for the 249 application layer protocol to be used in the connection. By placing 250 ownership of protocol selection on the server, ALPN facilitates 251 scenarios in which certificate selection or connection rerouting may 252 be based on the negotiated protocol. 254 Finally, by managing protocol selection in the clear as part of the 255 handshake, ALPN avoids introducing false confidence with respect to 256 the the ability to hide the negotiated protocol in advance of 257 establishing the connection. If hiding the protocol is required, 258 then renegotiation after connection establishment, which would 259 provide true TLS security guarantees, would be a preferred 260 methodology. 262 A namespace will be assigned for experimental protocols, comprising 263 byte strings which start with the following sequence of bytes: 0x65, 264 0x78, 0x70 ("exp"). Assignments in this namespace do not need IANA 265 registration. 267 5. Security Considerations 269 The ALPN extension does not impact the security of TLS session 270 establishment or application data exchange. ALPN serves to provide 271 an externally visible marker for the application layer protocol 272 associated with the TLS connection. Historically, the application 273 layer protocol associated with a connection could be ascertained from 274 the TCP/IP port number in use. 276 Encrypting the selected application protocol information and sending 277 it before the Finished messages are exchanged, as done in NPN, does 278 not provide confidentiality guarantees due to the possibility of man- 279 in-the-middle attacks. 281 6. IANA Considerations 283 The IANA has updated its Registry of TLS ExtensionType Values to 284 include the following entry: 286 - 16 application_layer_protocol_negotiation 288 This document also requires the IANA to create a registry of 289 Application Layer Protocol Negotiation protocol byte strings, 290 initially containing the following entries: 292 - "http/1.1": HTTP/1.1 [RFC2616]; 294 - "http/2.0": HTTP/2.0; 296 - "spdy/1": (obsolete) SPDY version 1; 298 - "spdy/2": SPDY version 2; 300 - "spdy/3": SPDY version 3. 302 We propose that this new registry be created in a new page entitled: 303 "Application Layer Protocol Negotiation (ALPN) Protocol IDs" beneath 304 the existing heading of "Transport Layer Security (TLS)". 306 7. Acknowledgements 308 This document benefitted specifically from the NPN extension draft 309 authored by Adam Langley of Google and from discussions with Tom 310 Wesselman and Cullen Jennings both of Cisco. 312 8. References 314 8.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 320 with Session Description Protocol (SDP)", RFC 3264, June 321 2002. 323 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 324 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 326 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 327 Extension Definitions", RFC 6066, January 2011. 329 8.2. Informative References 331 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 332 "Transport Layer Security (TLS) Session Resumption without 333 Server-Side State", RFC 5077, January 2008. 335 [spdy] Belshe, M. and R. Peon, "SPDY Protocol (Internet Draft)", 336 2012. 338 Authors' Addresses 340 Stephan Friedl 341 Cisco Systems, Inc. 342 170 West Tasman Drive 343 San Jose, CA 95134 344 USA 346 Phone: (720)562-6785 347 Email: sfriedl@cisco.com 349 Andrei Popov 350 Microsoft Corp. 351 One Microsoft Way 352 Redmond, WA 98052 353 USA 355 Email: andreipo@microsoft.com