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/