idnits 2.17.1 draft-ietf-httpbis-tunnel-protocol-05.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 (June 11, 2015) is 3240 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) -- Looks like a reference, but probably isn't: '1' on line 292 -- Looks like a reference, but probably isn't: '2' on line 295 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group A. Hutton 3 Internet-Draft Unify 4 Intended status: Standards Track J. Uberti 5 Expires: December 13, 2015 Google 6 M. Thomson 7 Mozilla 8 June 11, 2015 10 The ALPN HTTP Header Field 11 draft-ietf-httpbis-tunnel-protocol-05 13 Abstract 15 This specification allows HTTP CONNECT requests to indicate what 16 protocol is intended to be used within the tunnel once established, 17 using the ALPN header field. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 13, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. The ALPN HTTP Header Field . . . . . . . . . . . . . . . . . 3 56 2.1. Header Field Values . . . . . . . . . . . . . . . . . . . 3 57 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 5.2. Informative References . . . . . . . . . . . . . . . . . 6 64 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The HTTP CONNECT method (Section 4.3.6 of [RFC7231]) requests that 70 the recipient establish a tunnel to the identified origin server and 71 thereafter forward packets, in both directions, until the tunnel is 72 closed. Such tunnels are commonly used to create end-to-end virtual 73 connections, through one or more proxies. 75 The HTTP ALPN header field identifies the protocol or protocols that 76 the client intends to use within a tunnel that is established using 77 CONNECT. This uses the Application Layer Protocol Negotiation 78 identifier (ALPN, [RFC7301]). 80 For a tunnel that is then secured using TLS [RFC5246], the header 81 field carries the same application protocol label as will be carried 82 within the TLS handshake [RFC7301]. If there are multiple possible 83 application protocols, all of those application protocols are 84 indicated. 86 The ALPN header field carries an indication of client intent only. 87 An ALPN identifier is used here only to identify the application 88 protocol or suite of protocols that the client intends to use in the 89 tunnel. No negotiation takes place using this header field. In TLS, 90 the final choice of application protocol is made by the server from 91 the set of choices presented by the client. Other substrates could 92 negotiate the application protocol differently. 94 Proxies do not implement the tunneled protocol, though they might 95 choose to make policy decisions based on the value of the header 96 field. For example, a proxy could use the application protocol to 97 select appropriate traffic prioritization. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. The ALPN HTTP Header Field 107 Clients include the ALPN header field in an HTTP CONNECT request to 108 indicate the application layer protocol that a client intends to use 109 within the tunnel, or a set of protocols that might be used within 110 the tunnel. 112 2.1. Header Field Values 114 Valid values for the protocol field are taken from the "Application- 115 Layer Protocol Negotiation (ALPN) Protocol ID" registry ([1]) 116 established by [RFC7301]. 118 2.2. Syntax 120 The ABNF (Augmented Backus-Naur Form) syntax for the ALPN header 121 field value is given below. It uses the syntax defined in 122 Section 1.2 of [RFC7230]. 124 ALPN = 1#protocol-id 125 protocol-id = token ; percent-encoded ALPN protocol identifier 127 ALPN protocol names are octet sequences with no additional 128 constraints on format. Octets not allowed in tokens ([RFC7230], 129 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 130 [RFC3986]. Consequently, the octet representing the percent 131 character "%" (hex 25) MUST be percent-encoded as well. 133 In order to have precisely one way to represent any ALPN protocol 134 name, the following additional constraints apply: 136 o Octets in the ALPN protocol MUST NOT be percent-encoded if they 137 are valid token characters except "%", and 139 o When using percent-encoding, uppercase hex digits MUST be used. 141 With these constraints, recipients can apply simple string comparison 142 to match protocol identifiers. 144 For example: 146 CONNECT www.example.com HTTP/1.1 147 Host: www.example.com 148 ALPN: h2, http%2F1.1 150 2.3. Usage 152 When used in the ALPN header field, an ALPN identifier is used to 153 identify an entire application protocol stack, not a single protocol 154 layer or component. 156 For a CONNECT tunnel that conveys a protocol secured with TLS, the 157 value of the ALPN header field contains the same list of ALPN 158 identifiers that will be sent in the TLS ClientHello message 159 [RFC7301]. 161 Where no protocol negotiation is expected to occur, such as in 162 protocols that do not use TLS, the ALPN header field contains a 163 single ALPN Protocol Identifier corresponding to the application 164 protocol that is intended to be used. If an alternative form of 165 protocol negotiation is possible, the ALPN header field contains the 166 set of protocols that might be negotiated. 168 A proxy can use the value of the ALPN header field to more cleanly 169 and efficiently reject requests for a CONNECT tunnel. Exposing 170 protocol information at the HTTP layer allows a proxy to deny 171 requests earlier, with better error reporting (such as a 403 status 172 code). The ALPN header field can be falsified and is therefore not 173 sufficient basis for authorizing a request. 175 A proxy could attempt to inspect packets to determine the protocol in 176 use. This requires that the proxy understand each ALPN identifier. 177 Protocols like TLS could hide negotiated protocols, or protocol 178 negotiation details could change over time. Proxies SHOULD NOT break 179 a CONNECT tunnel solely on the basis of a failure to recognize the 180 protocol. 182 A proxy can use the ALPN header field value to change how it manages 183 or prioritizes connections. 185 3. IANA Considerations 187 HTTP header fields are registered within the "Permanent Message 188 Header Field Names" registry maintained at [2]. This document 189 defines and registers the ALPN header field, according to [RFC3864] 190 as follows: 192 Header Field Name: ALPN 194 Protocol: http 196 Status: Standard 198 Reference: Section 2 200 Change Controller: IETF (iesg@ietf.org) - Internet Engineering Task 201 Force 203 4. Security Considerations 205 In case of using HTTP CONNECT to a TURN server ("Traversal Using 206 Relays around NAT", [RFC5766]) the security considerations of 207 Section 4.3.6 of [RFC7231] apply. It states that there "are 208 significant risks in establishing a tunnel to arbitrary servers, 209 particularly when the destination is a well-known or reserved TCP 210 port that is not intended for Web traffic. Proxies that support 211 CONNECT SHOULD restrict its use to a limited set of known ports or a 212 configurable whitelist of safe request targets." 214 The ALPN header field described in this document is OPTIONAL. 215 Clients and HTTP proxies could choose to not support it and therefore 216 either fail to provide it, or ignore it when present. If the header 217 field is not available or ignored, a proxy cannot identify the 218 purpose of the tunnel and use this as input to any authorization 219 decision regarding the tunnel. This is indistinguishable from the 220 case where either client or proxy does not support the ALPN header 221 field. 223 There is no confidentiality protection for the ALPN header field. 224 ALPN identifiers that might expose confidential or sensitive 225 information SHOULD NOT be sent, as described in Section 5 of 226 [RFC7301]. 228 The value of the ALPN header field could be falsified by a client. 229 If the data being sent through the tunnel is encrypted (for example, 230 with TLS [RFC5246]), then the proxy might not be able to directly 231 inspect the data to verify that the claimed protocol is the one which 232 is actually being used, though a proxy might be able to perform 233 traffic analysis [TRAFFIC]. A proxy therefore cannot rely on the 234 value of the ALPN header field as a policy input in all cases. 236 5. References 238 5.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 242 RFC2119, March 1997, 243 . 245 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 246 Procedures for Message Header Fields", BCP 90, RFC 3864, 247 DOI 10.17487/RFC3864, September 2004, 248 . 250 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 251 Resource Identifier (URI): Generic Syntax", STD 66, RFC 252 3986, DOI 10.17487/RFC3986, January 2005, 253 . 255 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 256 (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 257 10.17487/RFC7230, June 2014, 258 . 260 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 261 (HTTP/1.1): Semantics and Content", RFC 7231, DOI 262 10.17487/RFC7231, June 2014, 263 . 265 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 266 "Transport Layer Security (TLS) Application-Layer Protocol 267 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 268 July 2014, . 270 5.2. Informative References 272 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 273 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 274 RFC5246, August 2008, 275 . 277 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 278 Relays around NAT (TURN): Relay Extensions to Session 279 Traversal Utilities for NAT (STUN)", RFC 5766, DOI 280 10.17487/RFC5766, April 2010, 281 . 283 [TRAFFIC] Pironti, A., Strub, P-Y., and K. Bhargavan, "Website Users 284 by TLS Traffic Analysis: New Attacks and Effective 285 Countermeasures, Revision 1", 2012, 286 . 290 5.3. URIs 292 [1] http://www.iana.org/assignments/tls-extensiontype-values/#alpn- 293 protocol-ids 295 [2] https://www.iana.org/assignments/message-headers 297 Authors' Addresses 299 Andrew Hutton 300 Unify 301 Technology Drive 302 Nottingham NG9 1LA 303 UK 305 EMail: andrew.hutton@unify.com 307 Justin Uberti 308 Google 309 747 6th Ave S 310 Kirkland, WA 98033 311 US 313 EMail: justin@uberti.name 315 Martin Thomson 316 Mozilla 317 331 E Evelyn Street 318 Mountain View, CA 94041 319 US 321 EMail: martin.thomson@gmail.com