idnits 2.17.1 draft-schinazi-httpbis-transport-auth-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 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 (July 08, 2019) is 1746 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 383 -- Looks like a reference, but probably isn't: '2' on line 385 ** 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 (-34) exists of draft-ietf-quic-http-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-05) exists of draft-pauly-quic-datagram-03 == Outdated reference: A later version (-02) exists of draft-schinazi-masque-00 == Outdated reference: A later version (-03) exists of draft-vvv-webtransport-http3-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). 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 July 08, 2019 5 Expires: January 9, 2020 7 HTTP Transport Authentication 8 draft-schinazi-httpbis-transport-auth-00 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 January 9, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 (https://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 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 57 2. Computing the Authentication Proof . . . . . . . . . . . . . 3 58 3. Header Field Definition . . . . . . . . . . . . . . . . . . . 4 59 3.1. The u Directive . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. The p Directive . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. The a Directive . . . . . . . . . . . . . . . . . . . . . 4 62 4. Transport Authentication Schemes . . . . . . . . . . . . . . 4 63 4.1. Signature . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Proxy Considerations . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Transport-Authentication Header Field . . . . . . . . . . 6 69 7.2. Transport Authentication Schemes Registry . . . . . . . . 6 70 7.3. TLS Keying Material Exporter Labels . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The most common existing authentication mechanisms for HTTP are sent 81 with each HTTP request, and authenticate that request instead of the 82 underlying HTTP connection, or transport. While these mechanisms 83 work well for existing uses of HTTP, they are not suitable for 84 emerging applications that multiplex non-HTTP traffic inside an HTTP 85 connection. This document describes the HTTP Transport 86 Authentication Framework, a method of authenticating not only an HTTP 87 request, but also its underlying transport. 89 Traditional HTTP semantics specify that HTTP is a stateless protocol 90 where each request can be understood in isolation [RFC7230]. 91 However, the emergence of QUIC [I-D.ietf-quic-transport] as a new 92 transport protocol that can carry HTTP [I-D.ietf-quic-http] and the 93 existence of QUIC extensions such as the DATAGRAM frame 94 [I-D.pauly-quic-datagram] enable new uses of HTTP such as 95 [I-D.vvv-webtransport-http3] and [I-D.schinazi-masque] where some 96 traffic is exchanged that is disctinct from HTTP requests and 97 responses. In order to authenticate this traffic, it is necessary to 98 authenticate the underlying transport (e.g., QUIC or TLS [RFC8446]) 99 instead of authenticate each request individually. This mechanism 100 aims to supplement the HTTP Authentication Framework [RFC7235], not 101 replace it. 103 Note that there is currently no mechanism for origin servers to 104 request that user agents authenticate themselves using Transport 105 Authentication, this is left as future work. 107 1.1. Conventions and Definitions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 This document uses the Augmented BNF defined in [RFC5234] and updated 116 by [RFC7405] along with the "#rule" extension defined in Section 7 of 117 [RFC7230]. The rules below are defined in [RFC3061], [RFC5234], 118 [RFC7230], and [RFC7235]: 120 OWS = 121 quoted-string = 122 token = 123 token68 = 124 oid = 126 2. Computing the Authentication Proof 128 This document only defines Transport Authentication for uses of HTTP 129 with TLS. This includes any use of HTTP over TLS as typically used 130 for HTTP/2, or HTTP/3 where the transport protocol uses TLS as its 131 authentication and key exchange mechanism [I-D.ietf-quic-tls]. 133 The user agent leverages a TLS keying material exporter [RFC5705] to 134 generate a nonce which can be signed using the user-id's key. The 135 keying material exporter uses a label that starts with the characters 136 "EXPORTER-HTTP-Transport-Authentication-" (see Section 4 for the 137 labels and contexts used by each scheme). The TLS keying material 138 exporter is used to generate a 32-byte key which is then used as a 139 nonce. 141 3. Header Field Definition 143 The "Transport-Authentication" header allows a user agent to 144 authenticate its transport connection with an origin server. 146 Transport-Authentication = transp-auth-scheme *( OWS ";" OWS parameter ) 147 transp-auth-scheme = token 148 parameter = token "=" ( token / quoted-string ) 150 3.1. The u Directive 152 The OPTIONAL "u" (user-id) directive specifies the user-id that the 153 user agent wishes to authenticate. It is encoded using Base64 154 (Section 4 of [RFC4648]). 156 u = token68 158 3.2. The p Directive 160 The OPTIONAL "p" (proof) directive specifies the proof that the user 161 agent provides to attest to possessing the credential that matches 162 its user-id. It is encoded using Base64 (Section 4 of [RFC4648]). 164 p = token68 166 3.3. The a Directive 168 The OPTIONAL "a" (algorithm) directive specifies the algorithm used 169 to compute the proof transmitted in the "p" directive. 171 a = oid 173 4. Transport Authentication Schemes 175 The Transport Authentication Framework allows defining Transport 176 Authentication Schemes, which specify how to authenticate user-ids. 177 This documents defined the "Signature" and "HMAC" schemes. 179 4.1. Signature 181 The "Signature" Transport Authentication Scheme uses asymmetric 182 cyptography. User agents possess a user-id and a public/private key 183 pair, and origin servers maintain a mapping of authorized user-ids to 184 their associated public keys. When using this scheme, the "u", "p", 185 and "a" directives are REQUIRED. The TLS keying material export 186 label for this scheme is "EXPORTER-HTTP-Transport-Authentication- 187 Signature" and the associated context is empty. The nonce is then 188 signed using the selected asymmetric signature algorithm and 189 transmitted as the proof directive. 191 For example, the user-id "john.doe" authenticating using Ed25519 192 [RFC8410] could produce the following header (lines are folded to 193 fit): 195 Transport-Authentication: Signature u="am9obi5kb2U=";a=1.3.101.112; 196 p="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo 197 aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==" 199 4.2. HMAC 201 The "HMAC" Transport Authentication Scheme uses symmetric 202 cyptography. User agents possess a user-id and a secret key, and 203 origin servers maintain a mapping of authorized user-ids to their 204 associated secret key. When using this scheme, the "u", "p", and "a" 205 directives are REQUIRED. The TLS keying material export label for 206 this scheme is "EXPORTER-HTTP-Transport-Authentication-HMAC" and the 207 associated context is empty. The nonce is then HMACed using the 208 selected HMAC algorithm and transmitted as the proof directive. 210 For example, the user-id "john.doe" authenticating using HMAC-SHA-512 211 [RFC6234] could produce the following header (lines are folded to 212 fit): 214 Transport-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3; 215 p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl 216 cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ==" 218 5. Proxy Considerations 220 Since Transport Authentication authenticates the underlying transport 221 by leveraging TLS keying material exporters, it cannot be 222 transparently forwarded by proxies that terminate TLS. However it 223 can be sent over proxied connections when TLS is performed end-to-end 224 (e.g., when using HTTP CONNECT proxies). 226 6. Security Considerations 228 Transport Authentication allows a user-agent to authenticate to an 229 origin server while guaranteeing freshness and without the need for 230 the server to transmit a nonce to the user agent. This allows the 231 server to accept authenticated clients without revealing that it 232 supports or expects authentication for some resources. It also 233 allows authentication without the user agent leaking the presence of 234 authentication to observers due to clear-text TLS Client Hello 235 extensions. 237 7. IANA Considerations 239 7.1. Transport-Authentication Header Field 241 This document, if approved, requests IANA to register the "Transport- 242 Authentication" header in the "Permanent Message Header Field Names" 243 registry maintained at https://www.iana.org/assignments/message- 244 headers/ [1]. 246 +--------------------------+----------+--------------+---------------+ 247 | Header Field Name | Protocol | Status | Reference | 248 +--------------------------+----------+--------------+---------------+ 249 | Transport-Authentication | http | experimental | This document | 250 +--------------------------+----------+--------------+---------------+ 252 7.2. Transport Authentication Schemes Registry 254 This document, if approved, requests IANA to create a new HTTP 255 Transport Authentication Schemes Registry with the following entries: 257 +---------------------------------+---------------+ 258 | Transport Authentication Scheme | Reference | 259 +---------------------------------+---------------+ 260 | Signature | This document | 261 +---------------------------------+---------------+ 262 | HMAC | This document | 263 +---------------------------------+---------------+ 265 7.3. TLS Keying Material Exporter Labels 267 This document, if approved, requests IANA to register the following 268 entries in the "TLS Exporter Labels" registry maintained at 269 https://www.iana.org/assignments/tls-parameters/tls- 270 parameters.xhtml#exporter-labels [2] 272 +--------------------------------------------------+ 273 | Value | 274 +--------------------------------------------------+ 275 | EXPORTER-HTTP-Transport-Authentication-Signature | 276 +--------------------------------------------------+ 277 | EXPORTER-HTTP-Transport-Authentication-HMAC | 278 +--------------------------------------------------+ 280 Both of these entries are listed with the following qualifiers: 282 +---------+-------------+---------------+ 283 | DTLS-OK | Recommended | Reference | 284 +---------+-------------+---------------+ 285 | N | Y | This document | 286 +---------+-------------+---------------+ 288 8. References 290 8.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997, 295 . 297 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 298 RFC 3061, DOI 10.17487/RFC3061, February 2001, 299 . 301 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 302 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 303 . 305 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 306 Specifications: ABNF", STD 68, RFC 5234, 307 DOI 10.17487/RFC5234, January 2008, 308 . 310 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 311 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 312 March 2010, . 314 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 315 Protocol (HTTP/1.1): Message Syntax and Routing", 316 RFC 7230, DOI 10.17487/RFC7230, June 2014, 317 . 319 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 320 Protocol (HTTP/1.1): Authentication", RFC 7235, 321 DOI 10.17487/RFC7235, June 2014, 322 . 324 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 325 RFC 7405, DOI 10.17487/RFC7405, December 2014, 326 . 328 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 329 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 330 May 2017, . 332 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 333 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 334 . 336 8.2. Informative References 338 [I-D.ietf-quic-http] 339 Bishop, M., "Hypertext Transfer Protocol Version 3 340 (HTTP/3)", draft-ietf-quic-http-20 (work in progress), 341 April 2019. 343 [I-D.ietf-quic-tls] 344 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 345 draft-ietf-quic-tls-20 (work in progress), April 2019. 347 [I-D.ietf-quic-transport] 348 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 349 and Secure Transport", draft-ietf-quic-transport-20 (work 350 in progress), April 2019. 352 [I-D.pauly-quic-datagram] 353 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 354 Datagram Extension to QUIC", draft-pauly-quic-datagram-03 355 (work in progress), July 2019. 357 [I-D.schinazi-masque] 358 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 359 masque-00 (work in progress), February 2019. 361 [I-D.vvv-webtransport-http3] 362 Vasiliev, V., "WebTransport over HTTP/3", draft-vvv- 363 webtransport-http3-00 (work in progress), May 2019. 365 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 366 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 367 DOI 10.17487/RFC6234, May 2011, 368 . 370 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 371 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 372 DOI 10.17487/RFC7427, January 2015, 373 . 375 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 376 Ed25519, Ed448, X25519, and X448 for Use in the Internet 377 X.509 Public Key Infrastructure", RFC 8410, 378 DOI 10.17487/RFC8410, August 2018, 379 . 381 8.3. URIs 383 [1] https://www.iana.org/assignments/message-headers/ 385 [2] https://www.iana.org/assignments/tls-parameters/tls- 386 parameters.xhtml#exporter-labels 388 Acknowledgments 390 The authors would like to thank many members of the IETF community, 391 as this document is the fruit of many hallway conversations. Using 392 the OID for the signature and HMAC algorithms was inspired by 393 Signature Authentication in IKEv2 [RFC7427]. 395 Author's Address 397 David Schinazi 398 Google LLC 399 1600 Amphitheatre Parkway 400 Mountain View, California 94043 401 United States of America 403 Email: dschinazi.ietf@gmail.com