draft-ietf-webpush-vapid-00.txt   draft-ietf-webpush-vapid-01.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track P. Beverloo Intended status: Standards Track P. Beverloo
Expires: October 9, 2016 Google Expires: December 31, 2016 Google
April 7, 2016 June 29, 2016
Voluntary Application Server Identification for Web Push Voluntary Application Server Identification for Web Push
draft-ietf-webpush-vapid-00 draft-ietf-webpush-vapid-01
Abstract Abstract
An application server can voluntarily identify itself to a push An application server can voluntarily identify itself to a push
service using the described technique. This identification service using the described technique. This identification
information can be used by the push service to attribute requests information can be used by the push service to attribute requests
that are made by the same application server to a single entity. that are made by the same application server to a single entity.
This can used to reduce the secrecy for push subscription URLs by This can used to reduce the secrecy for push subscription URLs by
being able to restrict subscriptions to a specific application being able to restrict subscriptions to a specific application
server. An application server is further able include additional server. An application server is further able to include additional
information the operator of a push service can use to contact the information that the operator of a push service can use to contact
operator of the application server. the operator of the application server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2016. This Internet-Draft will expire on December 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Application Server Self-Identification . . . . . . . . . . . 4 2. Application Server Self-Identification . . . . . . . . . . . 4
2.1. Application Server Contact Information . . . . . . . . . 4 2.1. Application Server Contact Information . . . . . . . . . 4
2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. WebPush Authentication Scheme . . . . . . . . . . . . . . . . 5 3. WebPush Authentication Scheme . . . . . . . . . . . . . . . . 5
4. Public Key Representation . . . . . . . . . . . . . . . . . . 6 4. Public Key Representation . . . . . . . . . . . . . . . . . . 6
5. Subscription Restriction . . . . . . . . . . . . . . . . . . 6 5. Subscription Restriction . . . . . . . . . . . . . . . . . . 6
5.1. Creating a Restricted Push Subscription . . . . . . . . . 7 5.1. Creating a Restricted Push Subscription . . . . . . . . . 7
5.2. Using Restricted Subscriptions . . . . . . . . . . . . . 7 5.2. Using Restricted Subscriptions . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. WebPush Authentication Scheme . . . . . . . . . . . . . . 9 7.1. WebPush Authentication Scheme . . . . . . . . . . . . . . 8
7.2. p256ecdsa Parameter for Crypto-Key Header Field . . . . . 9 7.2. p256ecdsa Parameter for Crypto-Key Header Field . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Web Push protocol [I-D.ietf-webpush-protocol] describes how an The Web Push protocol [I-D.ietf-webpush-protocol] describes how an
application server is able to request that a push service deliver a application server is able to request that a push service deliver a
push message to a user agent. push message to a user agent.
As a consequence of the expected deployment architecture, there is no As a consequence of the expected deployment architecture, there is no
basis for an application server to be known to a push service prior basis for an application server to be known to a push service prior
to requesting delivery of a push message. By the same measure, to requesting delivery of a push message. Requiring that the push
requesting the creation of a subscription for push message receipts service be able to authenticate application servers places an
has no prior authentication. Requiring that the push service be able unwanted constraint on the interactions between user agents and
to authenticate application servers places an unwanted constraint on application servers, who are the ultimate users of a push service.
the interactions between user agents and application servers, who are That constraint would also degrade the privacy-preserving properties
the ultimate users of a push service. That constraint would also the protocol provides. For these reasons,
degrade the privacy-preserving properties the protocol provides. For [I-D.ietf-webpush-protocol] does not define a mandatory system for
these reasons, [I-D.ietf-webpush-protocol] does not define a authentication of application servers.
mandatory system for authentication of application servers.
An unfortunate consequence of this design is that a push service is An unfortunate consequence of this design is that a push service is
exposed to a greater risk of denial of service attack. While exposed to a greater risk of denial of service attack. While
requests from application servers can be indirectly attributed to requests from application servers can be indirectly attributed to
user agents, this is not always efficient or even sufficient. user agents, this is not always efficient or even sufficient.
Providing more information about the application server directly to a Providing more information about the application server directly to a
push service allows the push service to better distinguish between push service allows the push service to better distinguish between
legitimate and bogus requests. legitimate and bogus requests.
Additionally, this design also relies on endpoint secrecy as any Additionally, this design also relies on endpoint secrecy as any
skipping to change at page 4, line 11 skipping to change at page 4, line 7
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document. It's not shouting, when they are capitalized, they have document. It's not shouting, when they are capitalized, they have
the special meaning described in [RFC2119]. the special meaning described in [RFC2119].
The terms "push message", "push service", "push subscription", The terms "push message", "push service", "push subscription",
"application server", and "user agent" are used as defined in "application server", and "user agent" are used as defined in
[I-D.ietf-webpush-protocol]. [I-D.ietf-webpush-protocol].
2. Application Server Self-Identification 2. Application Server Self-Identification
Application servers SHOULD generate and maintain a signing key pair Application servers that wish to self-identity generate and maintain
usable with elliptic curve digital signature (ECDSA) over the P-256 a signing key pair. This key pair MUST be usable with elliptic curve
curve [FIPS186]. Use of this key when sending push messages digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of
establishes a continuous identity for the application server. this key when sending push messages establishes an identity for the
application server that is consistent across multiple messages.
When requesting delivery of a push message, the application includes When requesting delivery of a push message, the application includes
a JSON Web Token (JWT) [RFC7519], signed using its signing key. The a JSON Web Token (JWT) [RFC7519], signed using its signing key. The
token includes a number of claims as follows: token includes a number of claims as follows:
o An "aud" (Audience) claim in the token MUST include the unicode o An "aud" (Audience) claim in the token MUST include the unicode
serialization of the origin (Section 6.1 of [RFC6454]) of the push serialization of the origin (Section 6.1 of [RFC6454]) of the push
resource URL. This binds the token to a specific push service. resource URL. This binds the token to a specific push service.
This ensures that the token is reusable for all push resource URLs This ensures that the token is reusable for all push resource URLs
that share the same origin. that share the same origin.
skipping to change at page 5, line 9 skipping to change at page 5, line 7
An application server requests the delivery of a push message as An application server requests the delivery of a push message as
described in [I-D.ietf-webpush-protocol]. If the application server described in [I-D.ietf-webpush-protocol]. If the application server
wishes to self-identify, it includes an Authorization header field wishes to self-identify, it includes an Authorization header field
with credentials that use the "WebPush" authentication scheme with credentials that use the "WebPush" authentication scheme
Section 3 and a Crypto-Key header field that includes its public key Section 3 and a Crypto-Key header field that includes its public key
Section 4. Section 4.
POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net Host: push.example.net
Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omU
Content-Type: text/plain;charset=utf8 Content-Type: text/plain;charset=utf8
Content-Length: 36 Content-Length: 36
Authorization: Bearer Authorization: WebPush
eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B
1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx 1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx
0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGk 0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGk
MlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA MlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA
Crypto-Key: p256ecdsa=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH Crypto-Key: p256ecdsa=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
Figure 1: Requesting Push Message Delivery with JWT Figure 1: Requesting Push Message Delivery with JWT
Note that the header fields shown in Figure 1 don't include line Note that the header fields shown in Figure 1 don't include line
wrapping. Extra whitespace is added to meet formatting constraints. wrapping. Extra whitespace is added to meet formatting constraints.
This equates to a JWT with the header and body shown in Figure 2. The value of the Authorization header field is a base64url-encoded
This JWT would be valid until 2016-01-21T01:53:25Z [RFC3339]. JWT with the header and body shown in Figure 2. This JWT would be
valid until 2016-01-21T01:53:25Z [RFC3339].
header = {"typ":"JWT","alg":"ES256"} header = {"typ":"JWT","alg":"ES256"}
body = { "aud":"https://push.example.net", body = { "aud":"https://push.example.net",
"exp":1453341205, "exp":1453341205,
"sub":"mailto:push@example.com" } "sub":"mailto:push@example.com" }
Figure 2: Example JWT Header and Body Figure 2: Example JWT Header and Body
Issue: The first part of the JWT is effectively fixed. Would be it
acceptable to require that that segment is omitted from the header
field?
3. WebPush Authentication Scheme 3. WebPush Authentication Scheme
A new "WebPush" HTTP authentication scheme [RFC7235] is defined. A new "WebPush" HTTP authentication scheme [RFC7235] is defined.
This authentication scheme carries a signed JWT, as described in This authentication scheme carries a signed JWT, as described in
Section 2. Section 2.
This authentication scheme is for origin-server authentication only. This authentication scheme is for origin-server authentication only.
Therefore, this authentication scheme MUST NOT be used with The Therefore, this authentication scheme MUST NOT be used with the
Proxy-Authenticate or Proxy-Authorization header fields. Proxy-Authenticate or Proxy-Authorization header fields.
This authentication scheme does not require a challenge. Clients are This authentication scheme does not require a challenge. Clients are
able to generate the Authorization header field without any able to generate the Authorization header field without any
additional information from a server. Therefore, a challenge for additional information from a server. Therefore, a challenge for
this authentication scheme MUST NOT be sent in a WWW-Authenticate this authentication scheme MUST NOT be sent in a WWW-Authenticate
header field. header field.
All unknown or unsupported parameters to "WebPush" authentication All unknown or unsupported parameters to "WebPush" authentication
credentials MUST be ignored. The "realm" parameter is ignored for credentials MUST be ignored. The "realm" parameter is ignored for
skipping to change at page 6, line 29 skipping to change at page 6, line 23
"p256ecdsa" parameter is defined for the Crypto-Key header field "p256ecdsa" parameter is defined for the Crypto-Key header field
[I-D.ietf-httpbis-encryption-encoding] to carry this information. [I-D.ietf-httpbis-encryption-encoding] to carry this information.
The "p256ecdsa" parameter includes an elliptic curve digital The "p256ecdsa" parameter includes an elliptic curve digital
signature algorithm (ECDSA) public key [FIPS186] in uncompressed form signature algorithm (ECDSA) public key [FIPS186] in uncompressed form
[X9.62] that is encoded using the URL- and filename-safe variant of [X9.62] that is encoded using the URL- and filename-safe variant of
base-64 [RFC4648] with padding removed. base-64 [RFC4648] with padding removed.
Note that with push message encryption [I-D.ietf-webpush-encryption], Note that with push message encryption [I-D.ietf-webpush-encryption],
this results in two values in the Crypto-Key header field, one with this results in two values in the Crypto-Key header field, one with
the a "p256dh" key and another with a "p256ecdsa" key. the a "dh" key and another with a "p256ecdsa" key.
Some implementations permit the same P-256 key to be used for signing Some implementations permit the same P-256 key to be used for signing
and key exchange. An application server MUST select a different and key exchange. An application server MUST select a different
private key for the key exchange (i.e., "p256dh") and signing (i.e., private key for the key exchange (i.e., "dh") and signing (i.e.,
"p256ecdsa"). Though a push service is not obligated to check either "p256ecdsa"). Though a push service is not obligated to check either
parameter, it SHOULD reject push messages that have identical values parameter for every push message, a push service SHOULD reject push
for these parameters with a 400 (Bad Request) status code. messages that have identical values for these parameters with a 400
(Bad Request) status code.
Editor's Note: JWK [RFC7517] seems like the obvious choice here. Editor's Note: JWK [RFC7517] seems like the obvious choice here.
However, JWK doesn't define a compact representation for public However, JWK doesn't define a compact representation for public
keys, which complicates the representation of JWK in a header keys, which complicates the representation of JWK in a header
field. field.
5. Subscription Restriction 5. Subscription Restriction
The public key of the application server serves as a stable The public key of the application server serves as a stable
identifier for the server. This key can be used to restrict a push identifier for the server. This key can be used to restrict a push
skipping to change at page 7, line 30 skipping to change at page 7, line 28
Crypto-Key: p256ecdsa=BBa22H8qaZ-iDMH9izb4qE72puwyvfjH2RxoQr5oiS4b Crypto-Key: p256ecdsa=BBa22H8qaZ-iDMH9izb4qE72puwyvfjH2RxoQr5oiS4b
KImoRwJm5xK9hLrbfIik20g31z8MpLFMCMr8y2cu6gY KImoRwJm5xK9hLrbfIik20g31z8MpLFMCMr8y2cu6gY
Figure 3: Example Subscribe Request Figure 3: Example Subscribe Request
An application might use the Web Push API [API] to include this An application might use the Web Push API [API] to include this
information. For example, the API might permit an application to information. For example, the API might permit an application to
provide a public key as part of a new field on the provide a public key as part of a new field on the
"PushSubscriptionOptions" dictionary. "PushSubscriptionOptions" dictionary.
Editor's Note: Allowing the inclusion of multiple keys when creating Note: Allowing the inclusion of multiple keys when creating a
a subscription would allow a subscription to be associated with subscription would allow a subscription to be associated with
multiple application servers or application server instances. multiple application servers or application server instances.
This might be more flexible, but it also would require more state This might be more flexible, but it also would require more state
to be maintained by the push service for each subscription. to be maintained by the push service for each subscription.
5.2. Using Restricted Subscriptions 5.2. Using Restricted Subscriptions
When a push subscription has been associated with an application When a push subscription has been associated with an application
server, the request for push message delivery MUST include proof of server, the request for push message delivery MUST include proof of
possession for the associated private key or token that was used when possession for the associated private key that was used when creating
creating the push subscription. the push subscription.
A push service MUST reject a message that omits mandatory credentials A push service MUST reject a message that omits mandatory credentials
with a 401 (Unauthorized) status code. A push service MAY reject a with a 401 (Unauthorized) status code. A push service MAY reject a
message that includes invalid credentials with a 403 (Forbidden) message that includes invalid credentials with a 403 (Forbidden)
status code. Credentials are invalid if: status code. Credentials are invalid if:
o either the authentication credentials or public key are not o either the authentication credentials or public key are not
included in the request, included in the request,
o the signature on the JWT cannot be successfully verified using the o the signature on the JWT cannot be successfully verified using the
skipping to change at page 8, line 17 skipping to change at page 8, line 14
o the current time is later than the time identified in the "exp" o the current time is later than the time identified in the "exp"
(Expiry) claim or more than 24 hours before the expiry time, (Expiry) claim or more than 24 hours before the expiry time,
o the origin of the push resource is not included in the "aud" o the origin of the push resource is not included in the "aud"
(Audience) claim, or (Audience) claim, or
o the public key used to sign the JWT doesn't match the one that was o the public key used to sign the JWT doesn't match the one that was
included in the creation of the push message. included in the creation of the push message.
A push subscription that is not restricted to a particular key MAY Note: In theory, since the push service was given a public key, the
still validate a token that is present, except for the last check. A push message request could omit the public key. On balance,
push service MAY then reject a request if the token is found to be requiring the key keeps things simple and it allows push services
invalid. to compress the public key (by hashing it, for example). In any
case, the relatively minor space savings aren't particularly
Editor's Note: In theory, since the push service was given a public important on the connection between the application server and
key, the push message request could omit the public key. On push service.
balance, requiring the key keeps things simple and it allows push
services to compress the public key (by hashing it, for example).
In any case, the relatively minor space savings aren't
particularly important on the connection between the application
server and push service.
A push service does not need to forward the JWT or public key to the A push service MUST NOT forward the JWT or public key to the user
user agent when delivering the push message. agent when delivering the push message.
6. Security Considerations 6. Security Considerations
This authentication scheme is vulnerable to replay attacks if an This authentication scheme is vulnerable to replay attacks if an
attacker can acquire a valid JWT. Applying narrow limits to the attacker can acquire a valid JWT. Applying narrow limits to the
period over which a replayable token can be reused limits the period over which a replayable token can be reused limits the
potential value of a stolen token to an attacker and can increase the potential value of a stolen token to an attacker and can increase the
difficulty of stealing a token. difficulty of stealing a token.
An application server might offer falsified contact information. A An application server might offer falsified contact information. A
skipping to change at page 10, line 7 skipping to change at page 9, line 46
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013. 2013.
[I-D.ietf-httpbis-encryption-encoding] [I-D.ietf-httpbis-encryption-encoding]
Thomson, M., "Encrypted Content-Encoding for HTTP", draft- Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
ietf-httpbis-encryption-encoding-01 (work in progress), ietf-httpbis-encryption-encoding-01 (work in progress),
March 2016. March 2016.
[I-D.ietf-webpush-protocol] [I-D.ietf-webpush-protocol]
Thomson, M., Damaggio, E., and B. Raymor, "Generic Event Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
Delivery Using HTTP Push", draft-ietf-webpush-protocol-04 Delivery Using HTTP Push", draft-ietf-webpush-protocol-06
(work in progress), March 2016. (work in progress), June 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
 End of changes. 20 change blocks. 
55 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/