idnits 2.17.1 draft-schinazi-httpbis-transport-auth-04.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 (September 10, 2020) is 1317 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 == Outdated reference: A later version (-03) exists of draft-schinazi-masque-protocol-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 == Outdated reference: A later version (-03) exists of draft-vvv-webtransport-http3-02 Summary: 2 errors (**), 0 flaws (~~), 7 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 September 10, 2020 5 Expires: March 14, 2021 7 HTTP Transport Authentication 8 draft-schinazi-httpbis-transport-auth-04 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 March 14, 2021. 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Proxy Considerations . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 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 [QUIC] as a new transport protocol 90 that can carry HTTP [HTTP3] and the existence of QUIC extensions such 91 as the DATAGRAM frame [DGRAM] enable new uses of HTTP such as 92 [WEBTRANS-H] and [MASQUE] where some traffic is exchanged that is 93 disctinct from HTTP requests and responses. In order to authenticate 94 this traffic, it is necessary to authenticate the underlying 95 transport (e.g., QUIC or TLS [RFC8446]) instead of authenticate each 96 request individually. This mechanism aims to supplement the HTTP 97 Authentication Framework [RFC7235], not replace it. 99 Note that there is currently no mechanism for origin servers to 100 request that user agents authenticate themselves using Transport 101 Authentication, this is left as future work. 103 1.1. Conventions and Definitions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 This document uses the Augmented BNF defined in [RFC5234] and updated 112 by [RFC7405] along with the "#rule" extension defined in Section 7 of 113 [RFC7230]. The rules below are defined in [RFC3061], [RFC5234], 114 [RFC7230], and [RFC7235]: 116 OWS = 117 quoted-string = 118 token = 119 token68 = 120 oid = 122 2. Computing the Authentication Proof 124 This document only defines Transport Authentication for uses of HTTP 125 with TLS. This includes any use of HTTP over TLS as typically used 126 for HTTP/2, or HTTP/3 where the transport protocol uses TLS as its 127 authentication and key exchange mechanism [QUIC-TLS]. 129 The user agent leverages a TLS keying material exporter [RFC5705] to 130 generate a nonce which can be signed using the user-id's key. The 131 keying material exporter uses a label that starts with the characters 132 "EXPORTER-HTTP-Transport-Authentication-" (see Section 4 for the 133 labels and contexts used by each scheme). The TLS keying material 134 exporter is used to generate a 32-byte key which is then used as a 135 nonce. 137 3. Header Field Definition 139 The "Transport-Authentication" header allows a user agent to 140 authenticate its transport connection with an origin server. 142 Transport-Authentication = tpauth-scheme *( OWS ";" OWS param ) 143 tpauth-scheme = token 144 param = token "=" ( token / quoted-string ) 146 3.1. The u Directive 148 The OPTIONAL "u" (user-id) directive specifies the user-id that the 149 user agent wishes to authenticate. It is encoded using Base64 150 (Section 4 of [RFC4648]). 152 u = token68 154 3.2. The p Directive 156 The OPTIONAL "p" (proof) directive specifies the proof that the user 157 agent provides to attest to possessing the credential that matches 158 its user-id. It is encoded using Base64 (Section 4 of [RFC4648]). 160 p = token68 162 3.3. The a Directive 164 The OPTIONAL "a" (algorithm) directive specifies the algorithm used 165 to compute the proof transmitted in the "p" directive. 167 a = oid 169 4. Transport Authentication Schemes 171 The Transport Authentication Framework allows defining Transport 172 Authentication Schemes, which specify how to authenticate user-ids. 173 This documents defined the "Signature" and "HMAC" schemes. 175 4.1. Signature 177 The "Signature" Transport Authentication Scheme uses asymmetric 178 cyptography. User agents possess a user-id and a public/private key 179 pair, and origin servers maintain a mapping of authorized user-ids to 180 their associated public keys. When using this scheme, the "u", "p", 181 and "a" directives are REQUIRED. The TLS keying material export 182 label for this scheme is "EXPORTER-HTTP-Transport-Authentication- 183 Signature" and the associated context is empty. The nonce is then 184 signed using the selected asymmetric signature algorithm and 185 transmitted as the proof directive. 187 For example, the user-id "john.doe" authenticating using Ed25519 188 [RFC8410] could produce the following header (lines are folded to 189 fit): 191 Transport-Authentication: Signature u="am9obi5kb2U="; 192 a=1.3.101.112; 193 p="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo 194 aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==" 196 4.2. HMAC 198 The "HMAC" Transport Authentication Scheme uses symmetric 199 cyptography. User agents possess a user-id and a secret key, and 200 origin servers maintain a mapping of authorized user-ids to their 201 associated secret key. When using this scheme, the "u", "p", and "a" 202 directives are REQUIRED. The TLS keying material export label for 203 this scheme is "EXPORTER-HTTP-Transport-Authentication-HMAC" and the 204 associated context is empty. The nonce is then HMACed using the 205 selected HMAC algorithm and transmitted as the proof directive. 207 For example, the user-id "john.doe" authenticating using HMAC-SHA-512 208 [RFC6234] could produce the following header (lines are folded to 209 fit): 211 Transport-Authentication: HMAC u="am9obi5kb2U="; 212 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 237 7.1. Transport-Authentication Header Field 239 This document, if approved, requests IANA to register the "Transport- 240 Authentication" header in the "Permanent Message Header Field Names" 241 registry maintained at https://www.iana.org/assignments/message- 242 headers/ (https://www.iana.org/assignments/message-headers/). 244 +--------------------------+----------+--------+---------------+ 245 | Header Field Name | Protocol | Status | Reference | 246 +--------------------------+----------+--------+---------------+ 247 | Transport-Authentication | http | exp | This document | 248 +--------------------------+----------+--------+---------------+ 250 7.2. Transport Authentication Schemes Registry 252 This document, if approved, requests IANA to create a new HTTP 253 Transport Authentication Schemes Registry with the following entries: 255 +---------------------------------+---------------+ 256 | Transport Authentication Scheme | Reference | 257 +---------------------------------+---------------+ 258 | Signature | This document | 259 +---------------------------------+---------------+ 260 | HMAC | This document | 261 +---------------------------------+---------------+ 263 7.3. TLS Keying Material Exporter Labels 265 This document, if approved, requests IANA to register the following 266 entries in the "TLS Exporter Labels" registry maintained at 267 https://www.iana.org/assignments/tls-parameters/tls- 268 parameters.xhtml#exporter-labels (https://www.iana.org/assignments/ 269 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 296 RFC 3061, DOI 10.17487/RFC3061, February 2001, 297 . 299 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 300 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 301 . 303 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 304 Specifications: ABNF", STD 68, RFC 5234, 305 DOI 10.17487/RFC5234, January 2008, 306 . 308 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 309 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 310 March 2010, . 312 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 313 Protocol (HTTP/1.1): Message Syntax and Routing", 314 RFC 7230, DOI 10.17487/RFC7230, June 2014, 315 . 317 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 318 Protocol (HTTP/1.1): Authentication", RFC 7235, 319 DOI 10.17487/RFC7235, June 2014, 320 . 322 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 323 RFC 7405, DOI 10.17487/RFC7405, December 2014, 324 . 326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 328 May 2017, . 330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 332 . 334 8.2. Informative References 336 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 337 Datagram Extension to QUIC", Work in Progress, Internet- 338 Draft, draft-ietf-quic-datagram-01, August 24, 2020, 339 . 342 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 343 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 344 quic-http-29, June 9, 2020, . 347 [MASQUE] Schinazi, D., "The MASQUE Protocol", Work in Progress, 348 Internet-Draft, draft-schinazi-masque-protocol-01, March 349 12, 2020, . 352 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 353 and Secure Transport", Work in Progress, Internet-Draft, 354 draft-ietf-quic-transport-29, June 9, 2020, 355 . 358 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 359 Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 360 June 9, 2020, . 363 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 364 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 365 DOI 10.17487/RFC6234, May 2011, 366 . 368 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 369 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 370 DOI 10.17487/RFC7427, January 2015, 371 . 373 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 374 Ed25519, Ed448, X25519, and X448 for Use in the Internet 375 X.509 Public Key Infrastructure", RFC 8410, 376 DOI 10.17487/RFC8410, August 2018, 377 . 379 [WEBTRANS-H] 380 Vasiliev, V., "WebTransport over HTTP/3", Work in 381 Progress, Internet-Draft, draft-vvv-webtransport-http3-02, 382 June 30, 2020, . 385 Acknowledgments 387 The authors would like to thank many members of the IETF community, 388 as this document is the fruit of many hallway conversations. Using 389 the OID for the signature and HMAC algorithms was inspired by 390 Signature Authentication in IKEv2 [RFC7427]. 392 Author's Address 394 David Schinazi 395 Google LLC 396 1600 Amphitheatre Parkway 397 Mountain View, California 94043, 398 United States of America 400 Email: dschinazi.ietf@gmail.com