idnits 2.17.1 draft-thomson-webpush-vapid-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 5, 2016) is 3026 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' == Outdated reference: A later version (-12) exists of draft-ietf-webpush-protocol-02 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-12) exists of draft-cavage-http-signatures-05 == Outdated reference: A later version (-09) exists of draft-ietf-httpbis-encryption-encoding-00 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-11 == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-02 -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track P. Beverloo 5 Expires: July 8, 2016 Google 6 January 5, 2016 8 Voluntary Application Server Identification for Web Push 9 draft-thomson-webpush-vapid-01 11 Abstract 13 An application server can voluntarily identify itself to a push 14 service using the described technique. This identification 15 information can be used by the push service to attribute requests 16 that are made by the same application server to a single entity, and 17 reduce the need for endpoint secrecy by being able to associate 18 subscriptions with an application server. An application server is 19 further able include additional information the operator of a push 20 service can use to contact the operator of the application server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 8, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 58 2. Self-Identification Alternatives . . . . . . . . . . . . . . 4 59 2.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Server-Vended Tokens . . . . . . . . . . . . . . . . . . 4 61 2.3. Client-Vended Tokens . . . . . . . . . . . . . . . . . . 5 62 2.4. Contact Information Header Field . . . . . . . . . . . . 6 63 2.5. Request Signing . . . . . . . . . . . . . . . . . . . . . 6 64 2.6. Token Binding . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Subscription Association . . . . . . . . . . . . . . . . . . 7 66 3.1. Amendments to Subscribing for Push Messages . . . . . . . 7 67 3.2. Amendments to Requesting Push Message Delivery . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The Web Push protocol [I-D.ietf-webpush-protocol] describes how an 79 application server is able to request that a push service deliver a 80 push message to a user agent. 82 As a consequence of the expected deployment architecture, there is no 83 basis for an application server to be known to a push service prior 84 to requesting delivery of a push message. By the same measure, 85 requesting the creation of a subscription for push message receipts 86 has no prior authentication. Requiring that the push service be able 87 to authenticate application servers places an unwanted constraint on 88 the interactions between user agents and application servers, who are 89 the ultimate users of a push service. That constraint would also 90 degrade the privacy-preserving properties the protocol provides. For 91 these reasons, [I-D.ietf-webpush-protocol] does not define a 92 mandatory system for authentication of application servers. 94 An unfortunate consequence of this design is that a push service is 95 exposed to a greater risk of denial of service attack. While 96 requests from application servers can be indirectly attributed to 97 user agents, this is not always efficient or even sufficient. 98 Providing more information about the application server more directly 99 to a push service allows the push service to better distinguish 100 between legitimate and bogus requests. 102 Additionally, this design also relies on endpoint secrecy as any 103 application server in possession of the endpoint is able to send 104 messages, albeit without payloads. In situations where usage of a 105 subscription can be limited to a single application server, the 106 ability to associate said subscription with the application server 107 provides could reduce the impact of a data leak. 109 This document describes a system whereby an application server can 110 volunteer information about itself to a push service. At a minimum, 111 this provides a stable identity for the application server, though 112 this could also include contact information, such as an email 113 address. 115 A consistent identity can be used by a push service to establish 116 behavioral expectations for an application server. Significant 117 deviations from an established norm can then be used to trigger 118 exception handling procedures. 120 Voluntarily-provided contact information can be used to contact an 121 application server operator in the case of exceptional situations. 123 Experience with push service deployment has shown that software 124 errors or unusual circumstances can cause large increases in push 125 message volume. Contacting the operator of the application server 126 has proven to be valuable. 128 Even in the absence of usable contact information, an application 129 server that has a well-established reputation might be given 130 preference over an unidentified application server when choosing 131 whether to discard a push message. 133 1.1. Notational Conventions 135 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 136 document. It's not shouting, when they are capitalized, they have 137 the special meaning described in [RFC2119]. 139 The terms "push message", "push service", "application server", and 140 "user agent" are used as defined in [I-D.ietf-webpush-protocol] 142 2. Self-Identification Alternatives 144 Several options have been proposed, here are some of the more 145 concrete options. 147 2.1. Certificates 149 A push service that supports application server self-identification 150 requests a client certificate from application servers. The client 151 certificate is requested during the TLS [RFC5246] handshake. 153 An application server that does not have a client certificate offers 154 no certificate in response; an application server that wishes to 155 self-identify includes a certificate. 157 The certificate that the application server offers SHOULD be self- 158 signed (see Section 3.2 of [RFC5280]). The certificate MAY contain 159 an alternative name extension (Section 4.2.1.6 of [RFC5280]) that 160 includes contact information. Of the available options, an email 161 address using the "rfc822Name" form or an HTTP [RFC7230] (or HTTPS 162 [RFC2818]) "uniformResourceIdentifier" SHOULD be included, though 163 including other options are not prohibited. 165 The offered end-entity certificate or the public key it contains 166 becomes an identifier for the application server. Push services are 167 able to reduce the data they retain for an application server, either 168 by extracting important information like the subject public key 169 information (SPKI), by hashing, or a combination. Of course, a push 170 service might choose to ignore the provided information. 172 To avoid requesting certificates from user agents, it might be 173 necessary to serve requests from user agents and requests from 174 application servers on different hostnames or port numbers. 176 2.2. Server-Vended Tokens 178 In this model, the push service vends a token to each application 179 server that requests it. That token is kept secret and used as the 180 basis for authentication. 182 This doesn't address the need for contact information, but it 183 addresses the need for a consistent application server identifier. 185 A Cookie [RFC6265] is a token of this nature. All the considerations 186 regarding the use (and misuse) of HTTP cookies apply should this 187 option be chosen. A mechanism that makes token theft more difficult, 188 such as [I-D.ietf-tokbind-https] might be needed. However that 189 suggests a separate option (see Section 2.6). 191 This information would be repeated with each request, but that 192 overhead is greatly reduced by header compression [RFC7541] in HTTP/2 193 [RFC7540]. 195 2.3. Client-Vended Tokens 197 In this model, clients generates a token that it uses to prove 198 ownership over a private key. Use of the same key over time 199 establishes a continuous identity. 201 Push message requests can be accompanied by a JSON Web Token (JWT) 202 [RFC7519]. An "aud" (Audience) claim in the token MUST include the 203 push resource URL. This binds the token to a specific push 204 subscription, but not a specific push message. As a result, the 205 token is reusable, limited by the value of the "exp" (Expiry) claim 206 in the token. An "exp" claim MUST be included. 208 The JWT is included in an Authorization header field, using an auth- 209 scheme of "WebPush". 211 Editor's Note: The definition of the "Bearer" auth-scheme in 212 [RFC6750] is almost perfect, but context would seem to indicate 213 that this is only valid for use with OAuth. 215 The corresponding public key is included in a JSON Web Key (JWK) 216 [RFC7517]. This would be included in either a newly-defined "jwk" 217 parameter of the Crypto-Key header field 218 [I-D.ietf-httpbis-encryption-encoding]; alternatively, the 219 "p256ecdsa" parameter defined in [I-D.thomson-http-content-signature] 220 could be used to transport a raw key. 222 For voluntarily-provided contact details, a separate header field 223 could be used (as in Section 2.4) or the JWT could include claims 224 about identity. For the latter, the "sub" (subject) claim could 225 include a contact URI for the application server. 227 The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. Both the JWS 228 and JWK MUST use an elliptic curve digital signature (ECDSA) key on 229 the NIST P-256 curve [FIPS186]. 231 A JWT also offers the option of including contact information as an 232 additional claim. An "iss" (Issuer) claim can include a contact URI: 233 either a "mailto:" (email) [RFC6068] or an "https:" [RFC2818] SHOULD 234 be used. 236 2.4. Contact Information Header Field 238 Contact information for an application server could be included in a 239 header field, either directly (e.g., a From header field, 240 Section 5.5.1 of [RFC7231]), or by reference (e.g., a new "contact" 241 link relation [RFC5988] that identified a vCard [RFC6350]). Note 242 that a From header field is limited to email addresses. 244 Like an server- or client-vended token (Section 2.2, Section 2.3), 245 contact information would need to be repeated, though that cost is 246 reduced with HTTP/2. 248 2.5. Request Signing 250 Signing of push message requests would allow the push service to 251 attribute requests to an application server based on an asymmetric 252 key. This could be done in any number of ways JWS [RFC7515] and HTTP 253 signatures [I-D.cavage-http-signatures] being the most likely 254 options. Note that the latter does not provide a means of conveying 255 the signing key, which would be necessary for this application. 257 Request signing shares much in common with client-vended tokens 258 Section 2.3, but it removes any possibility of token reuse in the 259 interests of security. 261 Request signing has a few shortcomings: 263 o Deciding what to sign is challenging. Signing only the body of a 264 message is not sufficient to prevent message replay attacks. 266 o Every message contains a signature, which can increase the load on 267 a server signficantly. This is especially bad if a signature 268 validation result is input to denial of service mitigation 269 decision making. 271 2.6. Token Binding 273 The mechanism proposed in [I-D.ietf-tokbind-https] can be used to 274 provide a stable identifier for application servers. This includes a 275 signature over material that is exported from the underlying TLS 276 connection. Importantly, this does not require a new signature for 277 each request: the same signature is repeated for every request, 278 HTTP/2 is again used to reduce the cost of the repeated information. 280 Token binding could be used independently of cookies. Consequently, 281 an application server would not be required to accept and store 282 cookies, though the push service would not be able to offload any 283 state as a result. 285 3. Subscription Association 287 A stable identifier for an application server - such as a public key 288 or a token - could also be used to associate a subscription with the 289 application server. 291 Subscription association reduces the reliance on endpoint secrecy by 292 requiring proof of possession to be demonstrated by an application 293 server when requesting delivery of a push message. This provides an 294 additional level of protection against leaking of the details of the 295 push subscription. 297 3.1. Amendments to Subscribing for Push Messages 299 The user agent includes the public key or token of the application 300 server when requesting the creation of a subscription. For example, 301 the Web Push API [API] could allow an application to provide a public 302 key as part of a new field on the "PushSubscriptionOptions" 303 dictionary. 305 This token might then be added to the request to create a push 306 subscription. 308 Allowing the inclusion of multiple keys when creating a subscription 309 would allow a subscription to be associated with multiple application 310 servers or application server instances. This would require more 311 state to be maintained by the push service for each subscription. 313 3.2. Amendments to Requesting Push Message Delivery 315 When a subscription has been associated with an application server, 316 the request for push message delivery MUST include proof of 317 possession for the associated private key or token that was used when 318 creating the subscription. Requests that do not contain proof of 319 possession are rejected with a 401 (Unauthorized) status code. 321 4. IANA Considerations 323 This document has no IANA actions (yet). 325 5. Security Considerations 327 TLS 1.2 [RFC5246] does not provide any confidentiality protections 328 for client certificates. A network attacker can therefore see the 329 identification information that is provided by the application 330 server. A push service MAY choose to offer confidentiality 331 protection for application server identity by initiating TLS 332 renegotiation immediately after establishing the TLS connection at 333 the cost of some additional latency. Using TLS 1.3 334 [I-D.ietf-tls-tls13] provides confidentiality protection for this 335 information without additional latency. 337 An application server might offer falsified contact information. A 338 push service operator therefore cannot use the presence of 339 unvalidated contact information as input to any security-critical 340 decision-making process. 342 Many of the alternative solutions are vulnerable to replay attacks. 343 Applying narrow limits to the period over which a replayable token 344 can be reused limits the potential value of a stolen token to an 345 attacker and can increase the difficulty of stealing a token. The 346 token binding solution, which binds tokens to a single TLS connection 347 can make tokens less reusable. 349 6. Acknowledgements 351 This document would have been much worse than it currently is if not 352 for the contributions of Benjamin Bangert, Chris Karlof, Costin 353 Manolache, and others. 355 7. References 357 7.1. Normative References 359 [FIPS186] National Institute of Standards and Technology (NIST), 360 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 361 2013. 363 [I-D.ietf-webpush-protocol] 364 Thomson, M., Damaggio, E., and B. Raymor, "Generic Event 365 Delivery Using HTTP Push", draft-ietf-webpush-protocol-02 366 (work in progress), November 2015. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 374 DOI 10.17487/RFC2818, May 2000, 375 . 377 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 378 (TLS) Protocol Version 1.2", RFC 5246, 379 DOI 10.17487/RFC5246, August 2008, 380 . 382 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 383 Housley, R., and W. Polk, "Internet X.509 Public Key 384 Infrastructure Certificate and Certificate Revocation List 385 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 386 . 388 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 389 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 390 . 392 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 393 Protocol (HTTP/1.1): Message Syntax and Routing", 394 RFC 7230, DOI 10.17487/RFC7230, June 2014, 395 . 397 7.2. Informative References 399 [API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015, 400 . 402 [I-D.cavage-http-signatures] 403 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 404 cavage-http-signatures-05 (work in progress), October 405 2015. 407 [I-D.ietf-httpbis-encryption-encoding] 408 Thomson, M., "Encrypted Content-Encoding for HTTP", draft- 409 ietf-httpbis-encryption-encoding-00 (work in progress), 410 December 2015. 412 [I-D.ietf-tls-tls13] 413 Rescorla, E., "The Transport Layer Security (TLS) Protocol 414 Version 1.3", draft-ietf-tls-tls13-11 (work in progress), 415 December 2015. 417 [I-D.ietf-tokbind-https] 418 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 419 "Token Binding over HTTP", draft-ietf-tokbind-https-02 420 (work in progress), October 2015. 422 [I-D.thomson-http-content-signature] 423 Thomson, M., "Content-Signature Header Field for HTTP", 424 draft-thomson-http-content-signature-00 (work in 425 progress), July 2015. 427 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 428 DOI 10.17487/RFC5988, October 2010, 429 . 431 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 432 DOI 10.17487/RFC6265, April 2011, 433 . 435 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 436 DOI 10.17487/RFC6350, August 2011, 437 . 439 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 440 Framework: Bearer Token Usage", RFC 6750, 441 DOI 10.17487/RFC6750, October 2012, 442 . 444 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 445 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 446 DOI 10.17487/RFC7231, June 2014, 447 . 449 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 450 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 451 2015, . 453 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 454 DOI 10.17487/RFC7517, May 2015, 455 . 457 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 458 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 459 . 461 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 462 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 463 DOI 10.17487/RFC7540, May 2015, 464 . 466 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 467 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 468 . 470 Authors' Addresses 472 Martin Thomson 473 Mozilla 475 Email: martin.thomson@gmail.com 476 Peter Beverloo 477 Google 479 Email: beverloo@google.com