rfc9577v4.txt		rfc9577.txt
	Internet Engineering Task Force (IETF) T. Pauly		Internet Engineering Task Force (IETF) T. Pauly
	Request for Comments: 9577 Apple Inc.		Request for Comments: 9577 Apple Inc.
	Category: Standards Track S. Valdez		Category: Standards Track S. Valdez
	ISSN: 2070-1721 Google LLC		ISSN: 2070-1721 Google LLC
	C. A. Wood		C. A. Wood
	Cloudflare		Cloudflare
	May 2024		June 2024
	The Privacy Pass HTTP Authentication Scheme		The Privacy Pass HTTP Authentication Scheme
	Abstract		Abstract
	This document defines an HTTP authentication scheme for Privacy Pass,		This document defines an HTTP authentication scheme for Privacy Pass,
	a privacy-preserving authentication mechanism used for authorization.		a privacy-preserving authentication mechanism used for authorization.
	The authentication scheme specified in this document can be used by		The authentication scheme specified in this document can be used by
	Clients to redeem Privacy Pass tokens with an Origin. It can also be		Clients to redeem Privacy Pass tokens with an Origin. It can also be
	used by Origins to challenge Clients to present Privacy Pass tokens.		used by Origins to challenge Clients to present Privacy Pass tokens.
	skipping to change at line 348 ¶		skipping to change at line 348 ¶
	share redemption contexts. Failure to successfully synchronize this		share redemption contexts. Failure to successfully synchronize this
	state and use it for double-spend prevention can allow Clients to		state and use it for double-spend prevention can allow Clients to
	redeem tokens to one Origin that were issued after an interaction		redeem tokens to one Origin that were issued after an interaction
	with another Origin that shares the context.		with another Origin that shares the context.
	2.1.2. Sending Token Challenges		2.1.2. Sending Token Challenges
	When used in an authentication challenge, the "PrivateToken" scheme		When used in an authentication challenge, the "PrivateToken" scheme
	uses the following parameters:		uses the following parameters:
	* "challenge", which contains a base64url TokenChallenge value,		* challenge, which contains a base64url TokenChallenge value,
	encoded per [RFC4648]. This document follows the default padding		encoded per [RFC4648]. This document follows the default padding
	behavior described in Section 3.2 of [RFC4648], so the base64url		behavior described in Section 3.2 of [RFC4648], so the base64url
	value MUST include padding. As an authentication parameter (auth-		value MUST include padding. As an authentication parameter (auth-
	param from [HTTP], Section 11.2), the value can be either a token		param from [HTTP], Section 11.2), the value can be either a token
	or a quoted-string and might be required to be a quoted-string if		or a quoted-string and might be required to be a quoted-string if
	the base64url string includes "=" characters. This parameter is		the base64url string includes "=" characters. This parameter is
	required for all challenges.		required for all challenges.
	* "token-key", which contains a base64url encoding of the public key		* token-key, which contains a base64url encoding of the public key
	for use with the issuance protocol indicated by the challenge.		for use with the issuance protocol indicated by the challenge.
	See [ISSUANCE] for more information about how this public key is		See [ISSUANCE] for more information about how this public key is
	used by the issuance protocols described in that specification.		used by the issuance protocols described in that specification.
	The encoding of the public key is determined by the token type;		The encoding of the public key is determined by the token type;
	see Section 6.2. As with "challenge", the base64url value MUST		see Section 6.2. As with challenge, the base64url value MUST
	include padding. As an authentication parameter (auth-param from		include padding. As an authentication parameter (auth-param from
	[HTTP], Section 11.2), the value can be either a token or a		[HTTP], Section 11.2), the value can be either a token or a
	quoted-string and might be required to be a quoted-string if the		quoted-string and might be required to be a quoted-string if the
	base64url string includes "=" characters. This parameter MAY be		base64url string includes "=" characters. This parameter MAY be
	omitted in deployments where Clients are able to retrieve the		omitted in deployments where Clients are able to retrieve the
	Issuer key using an out-of-band mechanism.		Issuer key using an out-of-band mechanism.
	* "max-age", which is an optional parameter that consists of the		* max-age, which is an optional parameter that consists of the
	number of seconds for which the challenge will be accepted by the		number of seconds for which the challenge will be accepted by the
	Origin.		Origin.
	The header field MAY also include the standard realm parameter, if		The header field MAY also include the standard realm parameter, if
	desired. Issuance protocols MAY define other parameters, some of		desired. Issuance protocols MAY define other parameters, some of
	which might be required. Clients MUST ignore parameters in		which might be required. Clients MUST ignore parameters in
	challenges that are not defined for the issuance protocol		challenges that are not defined for the issuance protocol
	corresponding to the token type in the challenge.		corresponding to the token type in the challenge.
	As an example, the WWW-Authenticate header field could look like		As an example, the WWW-Authenticate header field could look like
	skipping to change at line 525 ¶		skipping to change at line 525 ¶
	The authenticator value in the token structure is computed over the		The authenticator value in the token structure is computed over the
	token_type, nonce, challenge_digest, and token_key_id fields. A		token_type, nonce, challenge_digest, and token_key_id fields. A
	token is considered valid if token verification succeeds; see		token is considered valid if token verification succeeds; see
	Section 2.2.3 for details about verifying the token and its		Section 2.2.3 for details about verifying the token and its
	authenticator value.		authenticator value.
	2.2.2. Sending Tokens		2.2.2. Sending Tokens
	When used for Client authorization, the "PrivateToken" authentication		When used for Client authorization, the "PrivateToken" authentication
	scheme defines one parameter, "token", which contains the base64url-		scheme defines one parameter, token, which contains the base64url-
	encoded token structure. As with the challenge parameters		encoded token structure. As with the challenge parameters
	(Section 2.1), the base64url value MUST include padding. As an		(Section 2.1), the base64url value MUST include padding. As an
	authentication parameter (auth-param from [HTTP], Section 11.2), the		authentication parameter (auth-param from [HTTP], Section 11.2), the
	value can be either a token or a quoted-string and might be required		value can be either a token or a quoted-string and might be required
	to be a quoted-string if the base64url string includes "="		to be a quoted-string if the base64url string includes "="
	characters. All unknown or unsupported parameters to "PrivateToken"		characters. All unknown or unsupported parameters to "PrivateToken"
	authentication credentials MUST be ignored.		authentication credentials MUST be ignored.
	Clients present this token structure to Origins in a new HTTP request		Clients present this token structure to Origins in a new HTTP request
	using the Authorization header field as follows:		using the Authorization header field as follows:
	skipping to change at line 721 ¶		skipping to change at line 721 ¶
	for discussion about safety considerations for 0-RTT HTTP data.		for discussion about safety considerations for 0-RTT HTTP data.
	5.3. Reflection Attacks		5.3. Reflection Attacks
	The security properties of token challenges vary, depending on		The security properties of token challenges vary, depending on
	whether the challenge contains a redemption context or not, as well		whether the challenge contains a redemption context or not, as well
	as whether the challenge is a per-Origin challenge or not. For		as whether the challenge is a per-Origin challenge or not. For
	example, cross-Origin tokens with empty contexts can be reflected		example, cross-Origin tokens with empty contexts can be reflected
	from one party by another, as shown below.		from one party by another, as shown below.
	+--------+ +----------+ +--------+		+--------+ +----------+ +--------+
	| Origin | | Attacker | | Client |		| Origin | | Attacker | | Client |
	+---+----+ +----+-----+ +---+----+		+---+----+ +----+-----+ +---+----+
	| | |		| | |
	+-- TokenChallenge -->| |		+--- TokenChallenge -->| |
	| +-- (reflect challenge) ->|		| +-- (reflect challenge) -->|
	| |<-------- token ---------+		| |<-------- Token ----------+
	|<-- (reflect token) -+ |		|<-- (reflect token) --+ |
	| |		| | |
	Figure 2: Reflection Attack Example		Figure 2: Reflection Attack Example
	5.4. Token Exhaustion Attacks		5.4. Token Exhaustion Attacks
	When a Client holds cross-Origin tokens with empty contexts, it is		When a Client holds cross-Origin tokens with empty contexts, it is
	possible for any Origin in the cross-Origin set to deplete that		possible for any Origin in the cross-Origin set to deplete that
	Client's set of tokens. To prevent this from happening, tokens can		Client's set of tokens. To prevent this from happening, tokens can
	be scoped to single Origins (with non-empty origin_info) such that		be scoped to single Origins (with non-empty origin_info) such that
	they can only be redeemed for a single Origin. Alternatively, if		they can only be redeemed for a single Origin. Alternatively, if
	skipping to change at line 772 ¶		skipping to change at line 772 ¶
	Context-bound token challenges require Clients to obtain matching		Context-bound token challenges require Clients to obtain matching
	tokens when challenged, rather than presenting a token that was		tokens when challenged, rather than presenting a token that was
	obtained from a different context in the past. This can make it more		obtained from a different context in the past. This can make it more
	likely that issuance and redemption events will occur at		likely that issuance and redemption events will occur at
	approximately the same time. For example, if a Client is challenged		approximately the same time. For example, if a Client is challenged
	for a token with a unique context at time T1 and then subsequently		for a token with a unique context at time T1 and then subsequently
	obtains a token at time T2, a colluding Issuer and Origin can link		obtains a token at time T2, a colluding Issuer and Origin can link
	this to the same Client if T2 is unique to the Client. This		this to the same Client if T2 is unique to the Client. This
	linkability is less feasible as the number of issuance events at time		linkability is less feasible as the number of issuance events at time
	T2 increases. Depending on the "max-age" token challenge parameter,		T2 increases. Depending on the max-age token challenge parameter,
	Clients MAY try to add delay to the time between being challenged and		Clients MAY try to add delay to the time between being challenged and
	redeeming a token to make this sort of linkability more difficult.		redeeming a token to make this sort of linkability more difficult.
	For more discussion on correlation risks between token issuance and		For more discussion on correlation risks between token issuance and
	redemption, see Section 6.3 of [ARCHITECTURE].		redemption, see Section 6.3 of [ARCHITECTURE].
	5.6. Cross-Context Linkability Attacks		5.6. Cross-Context Linkability Attacks
	As discussed in Section 2.1, Clients SHOULD discard any context-bound		As discussed in Section 2.1, Clients SHOULD discard any context-bound
	tokens upon flushing cookies or changing networks, to prevent an		tokens upon flushing cookies or changing networks, to prevent an
	Origin from using the redemption context state as a cookie to		Origin from using the redemption context state as a cookie to
	skipping to change at line 812 ¶		skipping to change at line 812 ¶
	defined for use with the Privacy Pass token authentication scheme.		defined for use with the Privacy Pass token authentication scheme.
	These identifiers are 2-byte values, so the maximum possible value is		These identifiers are 2-byte values, so the maximum possible value is
	0xFFFF = 65535.		0xFFFF = 65535.
	New registrations need to list the following attributes:		New registrations need to list the following attributes:
	Value: The 2-byte identifier for the algorithm.		Value: The 2-byte identifier for the algorithm.
	Name: Name of the issuance protocol.		Name: Name of the issuance protocol.
	Token Structure: The contents of the token structure; see		Token Structure: The contents of the token structure; see
	Section 2.2.		Section 2.2.
	Token Key Encoding: The encoding of the "token-key" parameter; see		Token Key Encoding: The encoding of the token-key parameter; see
	Section 2.1.2.		Section 2.1.2.
	TokenChallenge Structure: The contents of the TokenChallenge		TokenChallenge Structure: The contents of the TokenChallenge
	structure; see Section 2.1.		structure; see Section 2.1.
	Publicly Verifiable: A Y/N value indicating if the output tokens		Publicly Verifiable: A Y/N value indicating if the output tokens
	have the public verifiability property; see Section 3.5 of		have the public verifiability property; see Section 3.5 of
	[ARCHITECTURE] for more details about this property.		[ARCHITECTURE] for more details about this property.
	Public Metadata: A Y/N value indicating if the output tokens can		Public Metadata: A Y/N value indicating if the output tokens can
	contain public metadata; see Section 3.5 of [ARCHITECTURE] for		contain public metadata; see Section 3.5 of [ARCHITECTURE] for
	more details about this property.		more details about this property.
	Private Metadata: A Y/N value indicating if the output tokens can		Private Metadata: A Y/N value indicating if the output tokens can
	skipping to change at line 883 ¶		skipping to change at line 883 ¶
	Change Controller: IETF		Change Controller: IETF
	Reference: RFC 9577		Reference: RFC 9577
	Notes: None		Notes: None
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[ARCHITECTURE]		[ARCHITECTURE]
	Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy		Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
	Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, May		Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
	2024, <https://www.rfc-editor.org/info/rfc9576>.		2024, <https://www.rfc-editor.org/info/rfc9576>.
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	[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,
	skipping to change at line 928 ¶		skipping to change at line 928 ¶
	[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	7.2. Informative References		7.2. Informative References
	[COOKIES] Bingler, S., Ed., West, M., Ed., and J. Wilander, Ed.,		[COOKIES] Bingler, S., Ed., West, M., Ed., and J. Wilander, Ed.,
	"Cookies: HTTP State Management Mechanism", Work in		"Cookies: HTTP State Management Mechanism", Work in
	Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-		Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-
	13, 15 November 2023,		14, 2 May 2024, <https://datatracker.ietf.org/doc/html/
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		draft-ietf-httpbis-rfc6265bis-14>.
	rfc6265bis-13>.
	[ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,		[ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
	"Privacy Pass Issuance Protocols", RFC 9578,		"Privacy Pass Issuance Protocols", RFC 9578,
	DOI 10.17487/RFC9578, May 2024,		DOI 10.17487/RFC9578, June 2024,
	<https://www.rfc-editor.org/info/rfc9578>.		<https://www.rfc-editor.org/info/rfc9578>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early		[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
	Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September		Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
	2018, <https://www.rfc-editor.org/info/rfc8470>.		2018, <https://www.rfc-editor.org/info/rfc8470>.
End of changes. 12 change blocks.
	22 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.48.