]> Apple, Inc.

cathieyun@gmail.com

Apple, Inc.

caw@heapingbits.net

This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the PRIVACYPASS Privacy Pass mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction describes the Privacy Pass architecture, and and describe the issuance and redemption protocols for basic Privacy Pass tokens, i.e., those computed using blind RSA signatures (as specified in ) or verifiable oblivious pseudorandom functions (as specified in ). These protocols are widely deployed in practice for a variety of applications, including anonymous authentication for protocols such as Oblivious HTTP and the Distributed Aggregation Protocol . While effective, these variants of Privacy Pass tokens are limited in that each token can only be spent once. These are often calle "one-time-use" tokens. This means that applications which wish to limit access to a given user, e.g., for the purposes of throttling or rate limiting them, must issue one token for each redemption. The Anonymous Rate-Limited Credential (ARC) protocol, as specified in , offers a more scalable approach to rate limiting. In particular, ARC credentials can be issued once and then presented (or redeemed) up to some fixed-amount of time for distinct, per-origin presentation contexts. This means that a Client will only be able to present a limited number of tokens associated with a given context. This document specifies the issuance and redemption protocols for ARC. describes motivation for this new type of token, presents an overview of the protocols, and the remainder of the document specifies the protocols themselves.

Motivation To demonstrate how ARC is useful, consider the case where a client wishes to keep its IP address private while accessing a service. The client can hide its IP address using a proxy service or a VPN. However, doing so severely limits the client's ability to access services and content, since servers might not be able to enforce their policies without a stable and unique client identifier. With one-time-use tokens, the server can verify that each client access meets a particular bar for attestation, i.e., the bar that is enforced during issuance, but cannot be used by the server to rate limit a specific client. This is because there is no mechanism in the issuance protocol to link repeated Client token requests in order to apply rate-limiting. There are several use cases for rate-limiting anonymous clients that are common on the Internet. These routinely use client IP address tracking, among other characteristics, to implement rate-limiting. One example of this use case is rate-limiting website accesses to a client to help prevent abusive behavior. Operations that are sensitive to abuse, such as account creation on a website or logging into an account, often employ rate-limiting as a defense-in-depth strategy. Additional verification can be required by these pages when a client exceeds a set rate-limit.

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. This document uses the terms Origin, Client, Issuer, and Token as defined in . Moreover, the following additional terms are used throughout this document.

• Issuer Public Key: The public key (from a private-public key pair) used by the Issuer for issuing and verifying Tokens.
• Issuer Private Key: The private key (from a private-public key pair) used by the Issuer for issuing and verifying Tokens.

Unless otherwise specified, this document encodes protocol messages in TLS notation from . Moreover, all constants are in network byte order.

Protocol Overview The issuance and redemption protocols defined in this document are built on the Anonymous Rate-Limited Credential (ARC) protocol. In contrast to the core Privacy Pass protocols which are one-time-use anonymous credentials, ARC allows clients to turn a single credential output from an issuance protocol into a fixed number of unlinkable tokens, each of which are bound to some agreed-upon public presentation context. With ARC, Clients receive TokenChallenge inputs from the redemption protocol (). If they have a valid credential for the designated Issuer, Clients can use the TokenChallenge to produce a single token for presentation. Otherwise, Clients invoke the issuance protocol to obtain a credential. This interaction is shown below.

Issuance and Redemption Overview | <----------------- TokenChallenge --------------------+ | | | | | <== Attestation ==> | | | +----------- CredentialRequest ---------->| | |<---------- CredentialResponse ----------+ | | | | | |----------- Request + Token ------------------------>| | | | | ]]>

Similar to the core Privacy Pass protocols, the TokenChallenge can be interactive or non-interactive, and per-origin or cross-origin. ARC is only compatible with deployment models where the Issuer and Origin are operated by the same entity (see ), as tokens produced from a credential are not publicly verifiable. The details of attestation are outside the scope of the issuance protocol; see for information about how attestation can be implemented in each of the relevant deployment models. The issuance and redemption protocols in this document are built on .

Configuration ARC Issuers are configured with key material used for issuance and token verification. Concretely, Issuers run the SetupServer function from to produce a private and public key, denoted skI and pkI, respectively. The Issuer Public Key ID, denoted issuer_key_id, is computed as the SHA-256 hash of the Issuer Public Key, i.e., issuer_key_id = SHA-256(pkI_serialized), where pkI_serialized is the serialized version of pkI as described in [Section 4.1 of ARC].

Token Challenge Requirements The ARC protocol uses a modified TokenChallenge structure from the one specified in . In particular, the updated TokenChallenge structure is as follows: ; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>; opaque credential_context<0..32>; } TokenChallenge; ]]> With the exception of credential_context, all fields are exactly as specified in . The credential_context field is defined as follows:

• "credential_context" is a field that is either 0 or 32 bytes, prefixed with a single octet indicating the length (either 0 or 32). If value is non-empty, it is a 32-byte value generated by the origin that allows the origin to require that clients fetch credentials bound to a specific context. Challenges with credential_context values of invalid lengths MUST be ignored.

Similar to the redemption_context field, the credential_context is used to bind information to the credential. This might be useful, for example, to enforce some expiration on the credential. Origins might do this by constructing credential_context as F(current time window), where F is a pseudorandom function. Semantically, this is equivalent to the Origin asking the Client for a token from a credential that is bound to "current time window." [[OPEN ISSUE: give more guidance about how to construct credential_context and redemption_context depending on the application's needs]] In addition to this updated TokenChallenge, the HTTP authentication challenge also SHOULD contain the following additional attribute:

• "rate-limit", which contains a JSON number indicating the presentation limit to use for ARC.

Implementation-specific steps: the client should store the Origin-provided input tokenChallenge so that when they receive a new tokenChallenge value, they can check if it has changed and which fields are different. This will inform the client's behavior - for example, if credential_context is being used to enforce an expiration on the credential, then if the credential_context has changed, this can prompt the client to request a new credential.

Credential Issuance Protocol Issuers provide an Issuer Private and Public Key, denoted skI and pkI respectively, used to produce tokens as input to the protocol. See for how these keys are generated. Clients provide the following as input to the issuance protocol:

• Issuer Request URL: A URL identifying the location to which issuance requests are sent. This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL. The value of this parameter depends on the Client configuration and deployment model. For example, in the 'Joint Origin and Issuer' deployment model, the Issuer Request URL might correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer.
• Issuer name: An identifier for the Issuer. This is typically a host name that can be used to construct HTTP requests to the Issuer.
• Issuer Public Key: pkI, with a key identifier token_key_id computed as described in .

Given this configuration and these inputs, the two messages exchanged in this protocol to produce a credential are described below.

Client-to-Issuer Request Given Origin-provided input tokenChallenge and the Issuer Public Key ID issuer_key_id, the Client first creates a credential request message using the CredentialRequest function from as follows: The Client then creates a TokenRequest structure as follows: The structure fields are defined as follows:

• "token_type" is a 2-octet integer.
• "truncated_issuer_key_id" is the least significant byte of the issuer_key_id () in network byte order (in other words, the last 8 bits of issuer_key_id). This value is truncated so that Issuers cannot use issuer_key_id as a way of uniquely identifying Clients; see and referenced information for more details.
• "encoded_request" is the Nrequest-octet request, computed as the serialization of the request value as defined in [Section 4.2.1 of ARC].

The Client then generates an HTTP POST request to send to the Issuer Request URL, with the TokenRequest as the content. The media type for this request is "application/private-credential-request". An example request for the Issuer Request URL "https://issuer.example.net/request" is shown below. ]]>

Issuer-to-Client Response Upon receipt of the request, the Issuer validates the following conditions:

• The TokenRequest contains a supported token_type equal to value 0xE5AC.
• The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of an Issuer Public Key, with corresponding secret key skI, owned by the Issuer.
• The TokenRequest.encoded_request is of the correct size (Nrequest).

If any of these conditions is not met, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the client. If these conditions are met, the Issuer then tries to deserialize TokenRequest.encoded_request according to [Section 4.2.1 of ARC], yielding request. If this fails, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the client. Otherwise, if the Issuer is willing to produce a credential for the Client, the Issuer completes the issuance flow by an issuance response as follows: The Issuer then creates a TokenResponse structured as follows: The structure fields are defined as follows:

• "encoded_response" is the Nresponse-octet encoded issuance response message, computed as the serialization of response as specified in [Section 4.2.2 of ARC].

The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-credential-response". ]]>

Credential Finalization Upon receipt, the Client handles the response and, if successful, deserializes the content values TokenResponse.encoded_response according to [Section 4.2.2 of ARC] yielding response. If deserialization fails, the Client aborts the protocol. Otherwise, the Client processes the response as follows: The Client then saves the credential structure, associated with the given Issuer Name, to use when producing Token values in response to future token challenges.

Token Redemption Protocol The token redemption protocol takes as input TokenChallenge and presentation limit values from ; the presentation limit is sent as an additional attribute within the HTTP challenge as described in . Clients use credentials from the issuance protocol in producing tokens bound to the TokenChallenge. The process for producing a token in this way, as well as verifying a resulting token, is described in the following sections.

Token Creation Given a TokenChallenge value as input, denoted challenge, a presentation limit, denoted presentationLimit, and a previously computed credential that is valid for the Issuer identifier in the challenge, denoted credential, Clients compute a credential presentation value as follows: Subsequent presentations MUST use the updated state, denoted newState. Reusing the original state will break the presentation unlinkability properties of ARC; see . The resulting Token value is then constructed as follows: The structure fields are defined as follows:

• "token_type" is a 2-octet integer, in network byte order, equal to 0xE5AC.
• "issuer_key_id" is a Nid-octet identifier for the Issuer Public Key, computed as defined in .
• "presentation_nonce" is a 32-bit encoding of the nonce output from ARC.
• "presentation" is a Npresentation-octet presentation, set to the serialized presentation value (see [Section 4.3.2 of ARC] for serialiation details).

Token Verification Given a deserialized presentation from the token, denoted presentation and obtained by deserializing a presentation according to [Section 4.3.2 of ARC], a presentation limit, denoted presentation_limit, a presentation nonce from a token, denoted nonce, and the digest of a token challenge, denoted challenge_digest, verifying a Token requires invoking the VerifyPresentation function from [Section 4.3.3 of ARC] in the following ways: This function returns True if the CredentialToken is valid, and False otherwise. Implementation-specific steps: to prevent double spending, the Origin should perform a check that the tag (presentation.tag) has not previously been seen. It then stores the tag for use in future double spending checks. To reduce the overhead of performing double spend checks, the Origin can store and look up the tags corresponding to the associated request_context and presentation_context values.

Security Considerations Privacy considerations for tokens based on deployment details, such as issuer configuration and issuer selection, are discussed in . Note that ARC requires a joint Origin and Issuer configuration given that it is privately verifiable. ARC offers Origin-Client unlinkability, Issuer-Client unlinkability, and redemption context unlinkability, as described in , with one exception. While redemption context unlinkability is achieved by re-randomizing credentials every time they are presented as tokens, there is a reduction in the anonymity set in the case of presentation nonce collisions, as detailed in [Section 7.2 of ARC].

IANA Considerations This document updates the "Privacy Pass Token Type" Registry with the following entries.

• Value: 0xE5AC
• Name: ARC (P-256)
• Token Structure: As defined in
• Token Key Encoding: Serialized as described in
• TokenChallenge Structure: As defined in
• Public Verifiability: N
• Public Metadata: N
• Private Metadata: N
• Nk: 0 (not applicable)
• Nid: 32
• Reference: This document
• Notes: None

References Normative References Apple, Inc. Apple, Inc. This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document 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 Privacy Pass tokens. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. Informative References This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. ISRG Cloudflare ISRG Independent Cloudflare There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data. Google LLC Fastly Apple Inc. Google LLC Cloudflare This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients.

Acknowledgments The authors would like to thank Tommy Pauly and the authors of for helpful discussions on rate-limited tokens.