idnits 2.17.00 (12 Aug 2021) /tmp/idnits43186/draft-schinazi-httpbis-transport-auth-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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 January 2020) is 864 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-24 == Outdated reference: A later version (-03) exists of draft-vvv-webtransport-http3-01 == Outdated reference: A later version (-02) exists of draft-schinazi-masque-01 == Outdated reference: draft-ietf-quic-tls has been published as RFC 9001 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Experimental 8 January 2020 5 Expires: 11 July 2020 7 HTTP Transport Authentication 8 draft-schinazi-httpbis-transport-auth-01 10 Abstract 12 The most common existing authentication mechanisms for HTTP are sent 13 with each HTTP request, and authenticate that request instead of the 14 underlying HTTP connection, or transport. While these mechanisms 15 work well for existing uses of HTTP, they are not suitable for 16 emerging applications that multiplex non-HTTP traffic inside an HTTP 17 connection. This document describes the HTTP Transport 18 Authentication Framework, a method of authenticating not only an HTTP 19 request, but also its underlying transport. 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 https://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 11 July 2020. 38 Copyright Notice 40 Copyright (c) 2020 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 56 2. Computing the Authentication Proof . . . . . . . . . . . . . 3 57 3. Header Field Definition . . . . . . . . . . . . . . . . . . . 3 58 3.1. The u Directive . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. The p Directive . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. The a Directive . . . . . . . . . . . . . . . . . . . . . 4 61 4. Transport Authentication Schemes . . . . . . . . . . . . . . 4 62 4.1. Signature . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Proxy Considerations . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Transport-Authentication Header Field . . . . . . . . . . 6 68 7.2. Transport Authentication Schemes Registry . . . . . . . . 6 69 7.3. TLS Keying Material Exporter Labels . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The most common existing authentication mechanisms for HTTP are sent 79 with each HTTP request, and authenticate that request instead of the 80 underlying HTTP connection, or transport. While these mechanisms 81 work well for existing uses of HTTP, they are not suitable for 82 emerging applications that multiplex non-HTTP traffic inside an HTTP 83 connection. This document describes the HTTP Transport 84 Authentication Framework, a method of authenticating not only an HTTP 85 request, but also its underlying transport. 87 Traditional HTTP semantics specify that HTTP is a stateless protocol 88 where each request can be understood in isolation [RFC7230]. 89 However, the emergence of QUIC [I-D.ietf-quic-transport] as a new 90 transport protocol that can carry HTTP [I-D.ietf-quic-http] and the 91 existence of QUIC extensions such as the DATAGRAM frame 92 [I-D.pauly-quic-datagram] enable new uses of HTTP such as 93 [I-D.vvv-webtransport-http3] and [I-D.schinazi-masque] where some 94 traffic is exchanged that is disctinct from HTTP requests and 95 responses. In order to authenticate this traffic, it is necessary to 96 authenticate the underlying transport (e.g., QUIC or TLS [RFC8446]) 97 instead of authenticate each request individually. This mechanism 98 aims to supplement the HTTP Authentication Framework [RFC7235], not 99 replace it. 101 Note that there is currently no mechanism for origin servers to 102 request that user agents authenticate themselves using Transport 103 Authentication, this is left as future work. 105 1.1. Conventions and Definitions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 This document uses the Augmented BNF defined in [RFC5234] and updated 114 by [RFC7405] along with the "#rule" extension defined in Section 7 of 115 [RFC7230]. The rules below are defined in [RFC3061], [RFC5234], 116 [RFC7230], and [RFC7235]: 118 OWS = 119 quoted-string = 120 token = 121 token68 = 122 oid = 124 2. Computing the Authentication Proof 126 This document only defines Transport Authentication for uses of HTTP 127 with TLS. This includes any use of HTTP over TLS as typically used 128 for HTTP/2, or HTTP/3 where the transport protocol uses TLS as its 129 authentication and key exchange mechanism [I-D.ietf-quic-tls]. 131 The user agent leverages a TLS keying material exporter [RFC5705] to 132 generate a nonce which can be signed using the user-id's key. The 133 keying material exporter uses a label that starts with the characters 134 "EXPORTER-HTTP-Transport-Authentication-" (see Section 4 for the 135 labels and contexts used by each scheme). The TLS keying material 136 exporter is used to generate a 32-byte key which is then used as a 137 nonce. 139 3. Header Field Definition 141 The "Transport-Authentication" header allows a user agent to 142 authenticate its transport connection with an origin server. 144 Transport-Authentication = transp-auth-scheme *( OWS ";" OWS parameter ) 145 transp-auth-scheme = token 146 parameter = token "=" ( token / quoted-string ) 148 3.1. The u Directive 150 The OPTIONAL "u" (user-id) directive specifies the user-id that the 151 user agent wishes to authenticate. It is encoded using Base64 152 (Section 4 of [RFC4648]). 154 u = token68 156 3.2. The p Directive 158 The OPTIONAL "p" (proof) directive specifies the proof that the user 159 agent provides to attest to possessing the credential that matches 160 its user-id. It is encoded using Base64 (Section 4 of [RFC4648]). 162 p = token68 164 3.3. The a Directive 166 The OPTIONAL "a" (algorithm) directive specifies the algorithm used 167 to compute the proof transmitted in the "p" directive. 169 a = oid 171 4. Transport Authentication Schemes 173 The Transport Authentication Framework allows defining Transport 174 Authentication Schemes, which specify how to authenticate user-ids. 175 This documents defined the "Signature" and "HMAC" schemes. 177 4.1. Signature 179 The "Signature" Transport Authentication Scheme uses asymmetric 180 cyptography. User agents possess a user-id and a public/private key 181 pair, and origin servers maintain a mapping of authorized user-ids to 182 their associated public keys. When using this scheme, the "u", "p", 183 and "a" directives are REQUIRED. The TLS keying material export 184 label for this scheme is "EXPORTER-HTTP-Transport-Authentication- 185 Signature" and the associated context is empty. The nonce is then 186 signed using the selected asymmetric signature algorithm and 187 transmitted as the proof directive. 189 For example, the user-id "john.doe" authenticating using Ed25519 190 [RFC8410] could produce the following header (lines are folded to 191 fit): 193 Transport-Authentication: Signature u="am9obi5kb2U=";a=1.3.101.112; 194 p="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo 195 aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==" 197 4.2. HMAC 199 The "HMAC" Transport Authentication Scheme uses symmetric 200 cyptography. User agents possess a user-id and a secret key, and 201 origin servers maintain a mapping of authorized user-ids to their 202 associated secret key. When using this scheme, the "u", "p", and "a" 203 directives are REQUIRED. The TLS keying material export label for 204 this scheme is "EXPORTER-HTTP-Transport-Authentication-HMAC" and the 205 associated context is empty. The nonce is then HMACed using the 206 selected HMAC algorithm and transmitted as the proof directive. 208 For example, the user-id "john.doe" authenticating using HMAC-SHA-512 209 [RFC6234] could produce the following header (lines are folded to 210 fit): 212 Transport-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3; 213 p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl 214 cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ==" 216 5. Proxy Considerations 218 Since Transport Authentication authenticates the underlying transport 219 by leveraging TLS keying material exporters, it cannot be 220 transparently forwarded by proxies that terminate TLS. However it 221 can be sent over proxied connections when TLS is performed end-to-end 222 (e.g., when using HTTP CONNECT proxies). 224 6. Security Considerations 226 Transport Authentication allows a user-agent to authenticate to an 227 origin server while guaranteeing freshness and without the need for 228 the server to transmit a nonce to the user agent. This allows the 229 server to accept authenticated clients without revealing that it 230 supports or expects authentication for some resources. It also 231 allows authentication without the user agent leaking the presence of 232 authentication to observers due to clear-text TLS Client Hello 233 extensions. 235 7. IANA Considerations 236 7.1. Transport-Authentication Header Field 238 This document, if approved, requests IANA to register the "Transport- 239 Authentication" header in the "Permanent Message Header Field Names" 240 registry maintained at https://www.iana.org/assignments/message- 241 headers/ (https://www.iana.org/assignments/message-headers/). 243 +--------------------------+----------+--------------+---------------+ 244 | Header Field Name | Protocol | Status | Reference | 245 +--------------------------+----------+--------------+---------------+ 246 | Transport-Authentication | http | experimental | This document | 247 +--------------------------+----------+--------------+---------------+ 249 7.2. Transport Authentication Schemes Registry 251 This document, if approved, requests IANA to create a new HTTP 252 Transport Authentication Schemes Registry with the following entries: 254 +---------------------------------+---------------+ 255 | Transport Authentication Scheme | Reference | 256 +---------------------------------+---------------+ 257 | Signature | This document | 258 +---------------------------------+---------------+ 259 | HMAC | This document | 260 +---------------------------------+---------------+ 262 7.3. TLS Keying Material Exporter Labels 264 This document, if approved, requests IANA to register the following 265 entries in the "TLS Exporter Labels" registry maintained at 266 https://www.iana.org/assignments/tls-parameters/tls- 267 parameters.xhtml#exporter-labels (https://www.iana.org/assignments/ 268 tls-parameters/tls-parameters.xhtml#exporter-labels) 270 +--------------------------------------------------+ 271 | Value | 272 +--------------------------------------------------+ 273 | EXPORTER-HTTP-Transport-Authentication-Signature | 274 +--------------------------------------------------+ 275 | EXPORTER-HTTP-Transport-Authentication-HMAC | 276 +--------------------------------------------------+ 278 Both of these entries are listed with the following qualifiers: 280 +---------+-------------+---------------+ 281 | DTLS-OK | Recommended | Reference | 282 +---------+-------------+---------------+ 283 | N | Y | This document | 284 +---------+-------------+---------------+ 286 8. References 288 8.1. Normative References 290 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 291 Protocol (HTTP/1.1): Message Syntax and Routing", 292 RFC 7230, DOI 10.17487/RFC7230, June 2014, 293 . 295 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 296 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 297 . 299 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 300 Protocol (HTTP/1.1): Authentication", RFC 7235, 301 DOI 10.17487/RFC7235, June 2014, 302 . 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, 306 DOI 10.17487/RFC2119, March 1997, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 314 Specifications: ABNF", STD 68, RFC 5234, 315 DOI 10.17487/RFC5234, January 2008, 316 . 318 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 319 RFC 7405, DOI 10.17487/RFC7405, December 2014, 320 . 322 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 323 RFC 3061, DOI 10.17487/RFC3061, February 2001, 324 . 326 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 327 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 328 March 2010, . 330 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 331 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 332 . 334 8.2. Informative References 336 [I-D.ietf-quic-transport] 337 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 338 and Secure Transport", Work in Progress, Internet-Draft, 339 draft-ietf-quic-transport-24, 3 November 2019, 340 . 343 [I-D.ietf-quic-http] 344 Bishop, M., "Hypertext Transfer Protocol Version 3 345 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 346 quic-http-24, 4 November 2019, . 349 [I-D.pauly-quic-datagram] 350 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 351 Datagram Extension to QUIC", Work in Progress, Internet- 352 Draft, draft-pauly-quic-datagram-05, 4 November 2019, 353 . 356 [I-D.vvv-webtransport-http3] 357 Vasiliev, V., "WebTransport over HTTP/3", Work in 358 Progress, Internet-Draft, draft-vvv-webtransport-http3-01, 359 3 November 2019, . 362 [I-D.schinazi-masque] 363 Schinazi, D., "The MASQUE Protocol", Work in Progress, 364 Internet-Draft, draft-schinazi-masque-01, 8 July 2019, 365 . 368 [I-D.ietf-quic-tls] 369 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 370 Work in Progress, Internet-Draft, draft-ietf-quic-tls-24, 371 3 November 2019, . 374 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 375 Ed25519, Ed448, X25519, and X448 for Use in the Internet 376 X.509 Public Key Infrastructure", RFC 8410, 377 DOI 10.17487/RFC8410, August 2018, 378 . 380 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 381 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 382 DOI 10.17487/RFC6234, May 2011, 383 . 385 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 386 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 387 DOI 10.17487/RFC7427, January 2015, 388 . 390 Acknowledgments 392 The authors would like to thank many members of the IETF community, 393 as this document is the fruit of many hallway conversations. Using 394 the OID for the signature and HMAC algorithms was inspired by 395 Signature Authentication in IKEv2 [RFC7427]. 397 Author's Address 399 David Schinazi 400 Google LLC 401 1600 Amphitheatre Parkway 402 Mountain View, California 94043, 403 United States of America 405 Email: dschinazi.ietf@gmail.com