]> Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America tpauly@apple.com

Google LLC

svaldez@chromium.org

Cloudflare

caw@heapingbits.net

Internet-Draft This document defines an HTTP authentication scheme that can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present an acceptable Privacy Pass token.

Introduction Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client (see ). A client possessing such a token is able to prove that it was able to get a token issued by a token issuer -- based on some check from a token issuer, such as authentication or solving a CAPTCHA -- without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens. This document defines a common HTTP authentication scheme (), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens. Clients and relying parties interact using this scheme to perform the token challenge and token redemption flow. Clients use a token issuance protocol to actually fetch tokens to redeem.

Token Architectural Components / ]]>

In addition to working with different token issuance protocols, this scheme supports optionally associating tokens with origin-chosen contexts and specific origin names. Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case. These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Unless otherwise specified, this document encodes protocol messages in TLS notation from , Section 3. This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", and "Token" as defined in . It additionally uses the following terms in more specific ways:

• Issuer key: Keying material that can be used with an issuance protocol to create a signed token.
• Token challenge: A requirement for tokens sent from an origin to a client, using the "WWW-Authenticate" HTTP header. This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name.
• Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header.

HTTP Authentication Scheme Token redemption is performed using HTTP Authentication (), with the scheme "PrivateToken". Origins challenge clients to present a token from a specific issuer (). Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin ().

Token Challenge Origins send a token challenge to clients in an "WWW-Authenticate" header with the "PrivateToken" scheme. This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. Origins that support this authentication scheme need to handle the following tasks:

1. Select which issuer to use, and configure the issuer name and token-key to include in WWW-Authenticate challenges.
2. Determine a redemption context construction to include in the TokenChallenge, as discussed in .
3. Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin names containing the origin.

The TokenChallenge message has the following structure: ; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>; } TokenChallenge; ]]> The structure fields are defined as follows:

• "token_type" is a 2-octet integer, in network byte order. This type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, . Challenges with unsupported token_type values MUST be ignored.
• "issuer_name" is a string containing the name of the issuer. This is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin. The string is prefixed with a 2-octet integer indicating the length, in network byte order.
• "redemption_context" is an optional field. If present, it allows the origin to require that clients fetch tokens bound to a specific context, as opposed to reusing tokens that were fetched for other contexts. See for example contexts that might be useful in practice. When present, this value is a 32-byte context generated by the origin. Valid lengths for this field are either 0 or 32 bytes. The field is prefixed with a single octet indicating the length. Challenges with redemption_context values of invalid lengths MUST be ignored.
• "origin_info" is an optional string containing one or more origin names, which allows a token to be scoped to a specific set of origins. The string is prefixed with a 2-octet integer indicating the length, in network byte order. If empty, any non-origin-specific token can be redeemed. If the string contains multiple origin names, they are delimited with commas "," without any whitespace.

When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:

• "challenge", which contains a base64url-encoded TokenChallenge value. Since the length of the challenge is not fixed, the base64url data MUST include padding. This MUST be unique for every 401 HTTP response to prevent replay attacks. This attribute is required for all challenges.
• "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. Since the length of the key is not fixed, the base64url data MUST include padding. This attribute MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism.
• "max-age", an optional attribute that consists of the number of seconds for which the challenge will be accepted by the origin.

Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. The header MAY also include the standard "realm" attribute, if desired. Issuance protocols MAY require other attributes. As an example, the WWW-Authenticate header could look like this: Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type. If the TokenChallenge has a token_type the client does not recognize or support, it MUST NOT parse or respond to the challenge. If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the authentication challenge is included in the list of origin names. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid. For example, clients can choose to reject challenges that list origin names for which current connection is not authoritative (according to the TLS certificate). Caching and pre-fetching of tokens is discussed in . Note that it is possible for the WWW-Authenticate header to include multiple challenges. This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts. For example, the WWW-Authenticate header could look like this: Origins should only include challenges for different types of issuance protocols with functionally equivalent properties. For instance, both issuance protocols in have the same functional properties, albeit with different mechanisms for verifying the resulting tokens during redemption. Since clients are free to choose which challenge they want to consume when presented with options, mixing multiple challenges with different functional properties for one use case is nonsensical.

Redemption Context Construction The TokenChallenge redemption context allows the origin to determine the context in which a given token can be redeemed. This value can be a unique per-request nonce, constructed from 32 freshly generated random bytes. It can also represent state or properties of the client session. Some example properties and methods for constructing the corresponding context are below. This list is not exhaustive.

• Context bound to a given time window: Construct redemption context as SHA256(current time window).
• Context bound to a client location: Construct redemption context as SHA256(client IP address prefix).
• Context bound to a given time window and location: Construct redemption context as SHA256(current time window, client IP address prefix).

An empty redemption context is not bound to any property of the client session. Preventing double spending on tokens requires the origin to keep state associated with the redemption context. The size of this state varies based on the size of the redemption context. For example, double spend state for unique, per-request redemption contexts does only needs to exist within the scope of the request connection or session. In contrast, double spend state for empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention. Origins should consider the operational complexity of this shared state before choosing to share redemption contexts. Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context.

Token Caching Clients can generate multiple tokens from a single TokenChallenge, and cache them for future use. This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoid any overhead of receiving new tokens via the issuance protocol. Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match. Note that each token has a unique client nonce, which is sent in token redemption (). If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies , or changing networks. Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client.

Token Redemption The output of the issuance protocol is a token that corresponds to the origin's challenge (see ). A token is a structure that begins with a two-octet field that indicates a token type, which MUST match the token_type in the TokenChallenge structure. The structure fields are defined as follows:

• "token_type" is a 2-octet integer, in network byte order. This value must match the value in the challenge ().
• "nonce" is a 32-octet message containing a client-generated random nonce.
• "challenge_digest" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge).
• "token_key_id" is an Nid-octet identifier for the the token authentication key. The value of this field is defined by the token_type and corresponding issuance protocol.
• "authenticator" is a Nk-octet authenticator that covers the preceding fields in the token. The value of this field is defined by the token_type and corresponding issuance protocol.

The authenticator value in the Token structure is computed over the token_type, nonce, context, and token_key_id fields. When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-encoded Token struct. Since the length of the Token struct is not fixed, the base64url data MUST include padding. All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. Clients present this Token structure to origins in a new HTTP request using the Authorization header as follows: For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce and the hash of a valid TokenChallenge. For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token. A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions. Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice. This prevents clients from "replaying" tokens for previous challenges. For context-bound tokens, this double-spend prevention can require no state or minimal state, since the context can be used to verify token uniqueness. If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response.

User Interaction When used in contexts like websites, origins that challenge clients for tokens need to consider how to optimize their interaction model to ensure a good user experience. Tokens challenges can be performed without explicit user involvement, depending on the issuance protocol. If tokens are scoped to a specific origin, there is no need for per-challenge user interaction. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated. If a client cannot use cached tokens to respond to a challenge (either because it has run out of cached tokens or the associated context is unique), the token issuance process can add user-perceivable latency. Origins need not block useful work on token authentication. Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction. If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT use more than one redemption context value for a given token type and issuer per client request. If an origin issues a large number of challenges with unique contexts, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server. In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to choose a preferred issuer or type. An origin MUST NOT assume that token challenges will always yield a valid token. Clients might experience issues running the issuance protocol, e.g., because the attester or issuer is unavailable, or clients might simply not support the requested token type. Origins SHOULD account for such operational or interoperability failures by offering clients an alternative type of challenge such as CAPTCHA for accessing a resource. To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to. In particular, clients SHOULD ignore token challenges with some non-zero probability. Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non-zero probability. Moreover, origins SHOULD include random token types in token challenges with some non-zero probability.

Security Considerations The security properties of token challenges vary depending on whether the challenge contains a redemption context or not, as well as whether the challenge is per-origin or not. For example, cross-origin tokens with empty contexts can be replayed from one party by another, as shown below.

Token Architectural Components | | Redemption ----------> / ]]>

Token challenges that include non-empty origin_info bind tokens to one or more specific origins. As described in , clients only accept such challenges from origin names listed in the origin_info string. Even if multiple origins are listed, a token can only be redeemed for an origin if the challenge has an exact match for the origin_info. For example, if "a.example.com" issues a challenge with an origin_info string of "a.example.com,b.example.com", a client could redeem a token fetched for this challenge if and only if "b.example.com" also included an origin_info string of "a.example.com,b.example.com". On the other hand, if "b.example.com" had an origin_info string of "b.example.com" or "b.example.com,a.example.com" or "a.example.com,b.example.com,c.example.com", the string would not match and the client would need to use a different token. Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past. This can make it more likely that issuance and redemption events will occur at approximately the same time. For example, if a client is challenged 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 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 T2 increases. Depending on the "max-age" token challenge attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult. For more discussion on correlation risks between token issuance and redemption, see . As discussed in , clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an origin using the redemption context state as a cookie to recognize clients. Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks. All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness.

IANA Considerations

Authentication Scheme This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established by . Authentication Scheme Name: PrivateToken Pointer to specification text: of this document

Token Type Registry IANA is requested to create a new "Privacy Pass Token Type" registry in a new "Privacy Pass Parameters" page to list identifiers for issuance protocols defined for use with the Privacy Pass token authentication scheme. These identifiers are two-byte values, so the maximum possible value is 0xFFFF = 65535. Template:

• Value: The two-byte identifier for the algorithm
• Name: Name of the issuance protocol
• Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable
• Public Metadata: A Y/N value indicating if the output tokens can contain public metadata.
• Private Metadata: A Y/N value indicating if the output tokens can contain private metadata.
• Nk: The length in bytes of an output authenticator
• Nid: The length of the token key identifier
• Reference: Where this algorithm is defined

New entries in this registry are subject to the Specification Required registration policy (). Designated experts need to ensure that the token type is sufficiently clearly defined to be used for both token issuance and redemption, and meets the common security and privacy requirements for issuance protocols defined in . This registry also will also allow provisional registrations to allow for experimentation with protocols being developed. Designated experts review, approve, and revoke provisional registrations. This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle unknown token types gracefully (this technique is inspired by ). Implemenations SHOULD select reserved values at random when including them in greased messages. Servers can include these in TokenChallenge structures, either as the only challenge when no real token type is desired, or as one challenge in a list of challenges that include real values. Clients can include these in Token structures when they are not able to present a real token response. The contents of the Token structure SHOULD be filled with random bytes when using greased values. The initial contents for this registry are defined in the table below. Token Types

Value	Name	Publicly Verifiable	Public Metadata	Private Metadata	Nk	Nid	Reference
0x0000	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x02AA	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x1132	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x2E96	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x3CD3	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x4473	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x5A63	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x6D32	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x7F3F	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x8D07	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0x916B	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0xA6A4	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0xBEAB	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0xC3F3	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0xDA42	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0xE944	RESERVED	N/A	N/A	N/A	N/A	N/A	This document
0xF057	RESERVED	N/A	N/A	N/A	N/A	N/A	This document

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References LIP Fastly Cloudflare This document specifies the architectural framework for constructing secure and anonymity-preserving instantiations of the Privacy Pass protocol. It provides recommendations on how the protocol ecosystem should be constructed to ensure the privacy of clients, and the security of all participating entities. Google LLC Mozilla Google LLC Apple, Inc This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. LIP Fastly Cloudflare This document specifies the architectural framework for constructing secure and anonymity-preserving instantiations of the Privacy Pass protocol. It provides recommendations on how the protocol ecosystem should be constructed to ensure the privacy of clients, and the security of all participating entities. This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. Brave Software Brave Software Cloudflare Google LLC Cloudflare This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable, and another that produces tokens that are publicly verifiable. The privately verifiable issuance protocol optionally supports public metadata during the issuance flow.

Test Vectors This section includes test vectors for the challenge and redemption functionalities described in and . Each test vector lists the following values:

• token_type: The type of token issuance protocol, a value from . For these test vectors, token_type is 0x0002, corresponding to the issuance protocol in .
• issuer_name: The name of the issuer in the TokenChallenge structure, represented as a hexadecimal string.
• redemption_context: The redemption context in the TokenChallenge structure, represented as a hexadecimal string.
• origin_info: The origin info in the TokenChallenge structure, represented as a hexadecimal string.
• nonce: The nonce in the Token structure, represented as a hexadecimal string.
• token_key: The public token-key, encoded based on the corresponding token type, represented as a hexadecimal string.
• token_authenticator_input: The values in the Token structure used to compute the Token authenticator value, represented as a hexadecimal string.
• token_authenticator: The output Token authenticator which verifies under token_key, represented as a hexadecimal string.

Test vectors are provided for each of the following TokenChallenge configurations:

• TokenChallenge with a single origin and non-empty redemption context
• TokenChallenge with a single origin and empty redemption context
• TokenChallenge with an empty origin and redemption context
• TokenChallenge with an empty origin and redemption context
• TokenChallenge with an empty origin and non-empty redemption context
• TokenChallenge with a multiple origins and non-empty redemption context

These test vectors are below.