idnits 2.17.1 draft-thomson-webpush-vapid-02.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 31, 2016) is 3007 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 (-09) exists of draft-ietf-httpbis-encryption-encoding-00 == Outdated reference: A later version (-12) exists of draft-ietf-webpush-protocol-02 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-09) exists of draft-ietf-webpush-encryption-01 -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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: August 3, 2016 Google 6 January 31, 2016 8 Voluntary Application Server Identification for Web Push 9 draft-thomson-webpush-vapid-02 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. 17 This can used to reduce the secrecy for push subscription URLs by 18 being able to restrict subscriptions to a specific application 19 server. An application server is further able include additional 20 information the operator of a push service can use to contact the 21 operator of the application server. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 3, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3 59 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 60 2. Application Server Self-Identification . . . . . . . . . . . 4 61 2.1. Application Server Contact Information . . . . . . . . . 4 62 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. WebPush Authentication Scheme . . . . . . . . . . . . . . . . 5 64 4. Public Key Representation . . . . . . . . . . . . . . . . . . 6 65 5. Subscription Restriction . . . . . . . . . . . . . . . . . . 6 66 5.1. Creating a Restricted Push Subscription . . . . . . . . . 6 67 5.2. Using Restricted Subscriptions . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. WebPush Authentication Scheme . . . . . . . . . . . . . . 8 71 7.2. p256ecdsa Parameter for Crypto-Key Header Field . . . . . 9 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The Web Push protocol [I-D.ietf-webpush-protocol] describes how an 81 application server is able to request that a push service deliver a 82 push message to a user agent. 84 As a consequence of the expected deployment architecture, there is no 85 basis for an application server to be known to a push service prior 86 to requesting delivery of a push message. By the same measure, 87 requesting the creation of a subscription for push message receipts 88 has no prior authentication. Requiring that the push service be able 89 to authenticate application servers places an unwanted constraint on 90 the interactions between user agents and application servers, who are 91 the ultimate users of a push service. That constraint would also 92 degrade the privacy-preserving properties the protocol provides. For 93 these reasons, [I-D.ietf-webpush-protocol] does not define a 94 mandatory system for authentication of application servers. 96 An unfortunate consequence of this design is that a push service is 97 exposed to a greater risk of denial of service attack. While 98 requests from application servers can be indirectly attributed to 99 user agents, this is not always efficient or even sufficient. 100 Providing more information about the application server directly to a 101 push service allows the push service to better distinguish between 102 legitimate and bogus requests. 104 Additionally, this design also relies on endpoint secrecy as any 105 application server in possession of the endpoint is able to send 106 messages, albeit without payloads. In situations where usage of a 107 subscription can be limited to a single application server, the 108 ability to associate a subscription with the application server could 109 reduce the impact of a data leak. 111 1.1. Voluntary Identification 113 This document describes a system whereby an application server can 114 volunteer information about itself to a push service. At a minimum, 115 this provides a stable identity for the application server, though 116 this could also include contact information, such as an email 117 address. 119 A consistent identity can be used by a push service to establish 120 behavioral expectations for an application server. Significant 121 deviations from an established norm can then be used to trigger 122 exception handling procedures. 124 Voluntarily-provided contact information can be used to contact an 125 application server operator in the case of exceptional situations. 127 Experience with push service deployment has shown that software 128 errors or unusual circumstances can cause large increases in push 129 message volume. Contacting the operator of the application server 130 has proven to be valuable. 132 Even in the absence of usable contact information, an application 133 server that has a well-established reputation might be given 134 preference over an unidentified application server when choosing 135 whether to discard a push message. 137 1.2. Notational Conventions 139 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 140 document. It's not shouting, when they are capitalized, they have 141 the special meaning described in [RFC2119]. 143 The terms "push message", "push service", "push subscription", 144 "application server", and "user agent" are used as defined in 145 [I-D.ietf-webpush-protocol]. 147 2. Application Server Self-Identification 149 Application servers SHOULD generate and maintain a signing key pair 150 usable with elliptic curve digital signature (ECDSA) over the P-256 151 curve [FIPS186]. Use of this key when sending push messages 152 establishes a continuous identity for the application server. 154 When requesting delivery of a push message, the application includes 155 a JSON Web Token (JWT) [RFC7519], signed using its signing key. The 156 token includes a number of claims as follows: 158 o An "aud" (Audience) claim in the token MUST include the unicode 159 serialization of the origin (Section 6.1 of [RFC6454]) of the push 160 resource URL. This binds the token to a specific push service. 161 This ensures that the token is reusable for all push resource URLs 162 that share the same origin. 164 o An "exp" (Expiry) claim MUST be included with the time after which 165 the token expires. This limits the time that a token over which a 166 token is valid. An "exp" claim MUST NOT be more than 24 hours 167 from the time of the request. 169 This JWT is included in an Authorization header field, using an auth- 170 scheme of "WebPush". A push service MAY reject a request with a 403 171 (Forbidden) status code [RFC7235] if the JWT signature or its claims 172 are invalid. 174 The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature 175 MUST use ECDSA on the NIST P-256 curve [FIPS186], that is "ES256" 176 [RFC7518]. 178 2.1. Application Server Contact Information 180 If the application server wishes to provide the JWT MAY include an 181 "sub" (Subject) claim. The "sub" claim SHOULD include a contact URI 182 for the application server as either a "mailto:" (email) [RFC6068] or 183 an "https:" [RFC2818] URI. 185 2.2. Example 187 An application server requests the delivery of a push message as 188 described in [I-D.ietf-webpush-protocol]. If the application server 189 wishes to self-identify, it includes an Authorization header field 190 with credentials that use the "WebPush" authentication scheme 191 Section 3 and a Crypto-Key header field that includes its public key 192 Section 4. 194 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 195 Host: push.example.net 196 Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omU 197 Content-Type: text/plain;charset=utf8 198 Content-Length: 36 199 Authorization: Bearer 200 eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B 201 1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx 202 0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGk 203 MlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA 204 Crypto-Key: p256ecdsa=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH 205 F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs 207 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 209 Figure 1: Requesting Push Message Delivery with JWT 211 Note that the header fields shown in Figure 1 don't include line 212 wrapping. Extra whitespace is added to meet formatting constraints. 214 This equates to a JWT with the header and body shown in Figure 2. 215 This JWT would be valid until 2016-01-21T01:53:25Z [RFC3339]. 217 header = {"typ":"JWT","alg":"ES256"} 218 body = { "aud":"https://push.example.net", 219 "exp":1453341205, 220 "sub":"mailto:push@example.com" } 222 Figure 2: Example JWT Header and Body 224 Issue: The first part of the JWT is effectively fixed. Would be it 225 acceptable to require that that segment is omitted from the header 226 field? 228 3. WebPush Authentication Scheme 230 A new "WebPush" HTTP authentication scheme [RFC7235] is defined. 231 This authentication scheme carries a signed JWT, as described in 232 Section 2. 234 This authentication scheme is for origin-server authentication only. 235 Therefore, this authentication scheme MUST NOT be used with The 236 Proxy-Authenticate or Proxy-Authorization header fields. 238 This authentication scheme does not require a challenge. Clients are 239 able to generate the Authorization header field without any 240 additional information from a server. Therefore, a challenge for 241 this authentication scheme MUST NOT be sent in a WWW-Authenticate 242 header field. 244 All unknown or unsupported parameters to "WebPush" authentication 245 credentials MUST be ignored. The "realm" parameter is ignored for 246 this authentication scheme. 248 4. Public Key Representation 250 In order for the push service to be able to validate the JWT, it 251 needs to learn the public key of the application server. A 252 "p256ecdsa" parameter is defined for the Crypto-Key header field 253 [I-D.ietf-httpbis-encryption-encoding] to carry this information. 255 The "p256ecdsa" parameter includes an elliptic curve digital 256 signature algorithm (ECDSA) public key [FIPS186] in uncompressed form 257 [X9.62] that is encoded using the URL- and filename-safe variant of 258 base-64 [RFC4648] with padding removed. 260 Note that with push message encryption [I-D.ietf-webpush-encryption], 261 this results in two values in the Crypto-Key header field, one with 262 the a "p256dh" key and another with a "p256ecdsa" key. 264 Editor's Note: JWK [RFC7517] seems like the obvious choice here. 265 However, JWK doesn't define a compact representation for public 266 keys, which complicates the representation of JWK in a header 267 field. 269 5. Subscription Restriction 271 The public key of the application server serves as a stable 272 identifier for the server. This key can be used to restrict a push 273 subscription to a specific application server. 275 Subscription restriction reduces the reliance on endpoint secrecy by 276 requiring proof of possession to be demonstrated by an application 277 server when requesting delivery of a push message. This provides an 278 additional level of protection against leaking of the details of the 279 push subscription. 281 5.1. Creating a Restricted Push Subscription 283 The user agent includes the public key of the application server when 284 requesting that a push subscription. This restricts use of the 285 resulting push subscription to application servers that are able to 286 provide proof of possession for the corresponding private key. 288 This public key is then added to the request to create a push 289 subscription as described in Section 4. The Crypto-Key header field 290 includes exactly one public key. For example: 292 POST /subscribe/ HTTP/1.1 293 Host: push.example.net 294 Crypto-Key: p256ecdsa=BBa22H8qaZ-iDMH9izb4qE72puwyvfjH2RxoQr5oiS4b 295 KImoRwJm5xK9hLrbfIik20g31z8MpLFMCMr8y2cu6gY 297 Figure 3: Example Subscribe Request 299 An application might use the Web Push API [API] to include this 300 information. For example, the API might permit an application to 301 provide a public key as part of a new field on the 302 "PushSubscriptionOptions" dictionary. 304 Editor's Note: Allowing the inclusion of multiple keys when creating 305 a subscription would allow a subscription to be associated with 306 multiple application servers or application server instances. 307 This might be more flexible, but it also would require more state 308 to be maintained by the push service for each subscription. 310 5.2. Using Restricted Subscriptions 312 When a push subscription has been associated with an application 313 server, the request for push message delivery MUST include proof of 314 possession for the associated private key or token that was used when 315 creating the push subscription. 317 A push service MUST reject a message that includes omits mandatory 318 credentials with a 401 (Unauthorized) status code. A push service 319 MAY reject a message that includes invalid credentials with a 403 320 (Forbidden) status code. Credentials are invalid if: 322 o either the authentication credentials or public key are not 323 included in the request, 325 o the signature on the JWT cannot be successfully verified using the 326 included public key, 328 o the current time is later than the time identified in the "exp" 329 (Expiry) claim or more than 24 hours before the expiry time, 331 o the origin of the push resource is not included in the "aud" 332 (Audience) claim, or 334 o the public key used to sign the doesn't match the one that was 335 included in the creation of the push message. 337 A push subscription that is not restricted to a particular key MAY 338 still validate a token that is present, except for the last check. A 339 push service MAY then reject a request if the token is found to be 340 invalid. 342 Editor's Note: In theory, since the push service was given a public 343 key, the push message request could omit the public key. On 344 balance, this keeps things simple and it allows push services to 345 compress the public key (by hashing it, for example). In any 346 case, the relatively minor space savings aren't particularly 347 important on the connection between the application server and 348 push service. 350 A push service does not need to forward the JWT or public key to the 351 user agent when delivering the push message. 353 6. Security Considerations 355 This authentication scheme is vulnerable to replay attacks if an 356 attacker can acquire a valid JWT. Applying narrow limits to the 357 period over which a replayable token can be reused limits the 358 potential value of a stolen token to an attacker and can increase the 359 difficulty of stealing a token. 361 An application server might offer falsified contact information. A 362 push service operator therefore cannot use the presence of 363 unvalidated contact information as input to any security-critical 364 decision-making process. 366 Validation of a signature on the JWT requires a non-trivial amount of 367 computation. For something that might be used to identify legitimate 368 requests under denial of service attack conditions, this is not 369 ideal. Application servers are therefore encouraged to reuse a JWT, 370 which permits the push service to cache the results of signature 371 validation. 373 7. IANA Considerations 375 7.1. WebPush Authentication Scheme 377 This registers the "WebPush" authentication scheme in the "Hypertext 378 Transfer Protocol (HTTP) Authentication Scheme Registry" established 379 in [RFC7235]. 381 Authentication Scheme Name: WebPush 382 Pointer to specification text: Section 3 of this document 384 Notes: This scheme is origin-server only and does not define a 385 challenge. 387 7.2. p256ecdsa Parameter for Crypto-Key Header Field 389 This registers a "p256ecdsa" parameter for the Crypto-Key header 390 field in the "Hypertext Transfer Protocol (HTTP) Crypto-Key 391 Parameters" established in [I-D.ietf-httpbis-encryption-encoding]. 393 Parameter Name: p256ecdsa 395 Purpose: Conveys a public key for that is used to generate an ECDSA 396 signature. 398 Reference: Section 4 of this document 400 8. Acknowledgements 402 This document would have been much worse than it currently is if not 403 for the contributions of Benjamin Bangert, Chris Karlof, Costin 404 Manolache, and others. 406 9. References 408 9.1. Normative References 410 [FIPS186] National Institute of Standards and Technology (NIST), 411 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 412 2013. 414 [I-D.ietf-httpbis-encryption-encoding] 415 Thomson, M., "Encrypted Content-Encoding for HTTP", draft- 416 ietf-httpbis-encryption-encoding-00 (work in progress), 417 December 2015. 419 [I-D.ietf-webpush-protocol] 420 Thomson, M., Damaggio, E., and B. Raymor, "Generic Event 421 Delivery Using HTTP Push", draft-ietf-webpush-protocol-02 422 (work in progress), November 2015. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 430 DOI 10.17487/RFC2818, May 2000, 431 . 433 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 434 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 435 . 437 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 438 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 439 . 441 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 442 DOI 10.17487/RFC6454, December 2011, 443 . 445 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 446 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 447 2015, . 449 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 450 DOI 10.17487/RFC7518, May 2015, 451 . 453 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 454 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 455 . 457 [X9.62] ANSI, "Public Key Cryptography For The Financial Services 458 Industry: The Elliptic Curve Digital Signature Algorithm 459 (ECDSA)", ANSI X9.62 , 1998. 461 9.2. Informative References 463 [API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015, 464 . 466 [I-D.ietf-webpush-encryption] 467 Thomson, M., "Message Encryption for Web Push", draft- 468 ietf-webpush-encryption-01 (work in progress), October 469 2015. 471 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 472 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 473 . 475 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 476 Protocol (HTTP/1.1): Authentication", RFC 7235, 477 DOI 10.17487/RFC7235, June 2014, 478 . 480 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 481 DOI 10.17487/RFC7517, May 2015, 482 . 484 Authors' Addresses 486 Martin Thomson 487 Mozilla 489 Email: martin.thomson@gmail.com 491 Peter Beverloo 492 Google 494 Email: beverloo@google.com