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.