Privacy Pass with Token Binding Extension

Introduction Privacy Pass provides an anonymous authorization architecture based on privacy-preserving authentication mechanisms , and it consists of the issuance protocol and the redemption protocol. In the issuance protocol , a Client can interact with a token Issuer to obtain Privacy Pass tokens after completing some authentication successfully, where the tokens are generated by the Issuer using the Issuer Private Key. In the redemption protocol , the Client holding such a token can prove to an Origin that it is authorized by the Issuer to access the Origin's protected resources, without allowing the Origin (even with the Issuer) to link it with the issuance flow. However, Privacy Pass tokens pertain to bearer tokens, and any party in possession of Privacy Pass tokens can also access to the protected resources. Therefore, attackers can take advantage of this by exporting Privacy Pass tokens from a user's machines or application connections, presenting them to the application server (the Origin), and impersonating the legitimate user. The token binding extension for the Privacy Pass protocol is to prevent such attacks by cryptographically binding a Privacy Pass token to the user agent (the Client) generated one-time public key and requiring the Client presenting the token to additionally prove possession of the corresponding private key. In addition, this extension does not introduce additional cryptographic primitives, and only uses the primitives (such as Schnorr NIZKP in and RSA signature in ) currently utilized in the issuance protocol to generate the one-time public-private keypair as well as generate and verify the binding proof. Specifically, we choose the Schnorr NIZKP to achieve token binding for both privately verifiable tokens and publicly verifiable tokens because of the following reasons: 1) the keypair of the Schnorr NIZKP can be generated from a secure seed, which is not supported by the RSA signature; 2) the keypair generation of the Schnorr NIZKP is much faster than that of the RSA signature. Because the keypair is only used one time, a more lightweight proving is to directly present the one-time private key to the Origin, which is so not a zero-knowledge proof, and its verification procedure needs to compute the corresponding one-time public key and verify the bound token. At a high level, Privacy Pass with token binding extension proceeds as follows. First, a Client generates a one-time public-private keypair probably within a secure hardware module, such as a Trusted Platform Module (TPM) and a Trusted Execution Environment (TEE). Then, the client concatenates the token input and the public key to obtain a bound token input, blinds the bound token input, and generates a TokenRequest similar to Section and Section of . After finalizing the issuance protocol successfully, the client will obtain a Privacy Pass bound token. Lastly, when spending the token, the client needs to use the private key to generate a binding proof, which is used to prove possession of the private key corresponding to the public key included in the bound token input. After receiving the token, the public key and the binding proof, the Origin not only needs to verify the token bound with the public key but also needs to verify the binding proof using the bound public key. In addition, if there is a channel (e.g., TLS , HPKE ) between the Client and the Origin, then a secret value exported from the channel can be used as an additional input in the Schnorr NIZK proof generation to support the property of channel binding, which guarantees that the token and the binding proof for one channel that obtained by an attacker cannot be used in another channel. As a result, if an attacker attempts to export and replay a Privacy Pass bound token, it also needs to use the Client's private key that corresponds to the token's bound public key. But this is hard to do if the private key is specially protected in a secure hardware module.

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 . This document uses terms "Origin", "Client", "Issuer", "Issuance", "Redemption", "Token challenge", "Token request", "Token response" and "Token" as defined in , and also uses the terms "Issuer key", "Token redemption" as defined in as well as the terms "Issuer Public Key", "Issuer Private Key" as defined in .

Issuance Protocol with Token Binding Extension This section describes the issuance protocol with token binding extension, which includes two types of issuance protocol: one for privately verifiable tokens and another for publicly verifiable tokens.

Token Binding for Privately Verifiable Token Issuance This section uses notation described in , including SerializeElement, DeserializeElement, and DeserializeScalar. The constants Ne and Ns are defined in , and the constant Nk is defined in .

Client-to-Issuer Request The Client first generates a context as follows: Here, pkI denotes the Issuer Public Key defined in . "P384-SHA384" is the identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite defined in . SetupVOPRFClient is defined in . The Client then generates a random 32-byte nonce and creates a token_input as follows: Here, the challenge is an opaque string, and might be provided by the redemption protocol described in . The 2 bytes value 0x8001 represents the token type of VOPRF(P-384, SHA-384) with Token Binding (P-384, SHA-384), where the latter ciphersuite (P-384, SHA-384) will be used for token binding. The token_key_id is a key identifier of the Issuer Public Key pkI, which is computed as described in . The Client generates an ephemeral public-private keypair (pkE, skE) in the group of elliptic curve P-384, where pkE and skE are of Ne-byte length and Ns-byte length, respectively, and the constants Ne = 49 and Ns = 48 are defined in . A RECOMMENDED method for generating ephemeral keypairs is as follows: Here, the long-term seed is probably generated within a secure hardware module and can be used to protect multiple tokens (or a batch of tokens), and the DeriveKeyPair function is defined in . After that, the Client creates a bound_token_input and blinds it as follows: Here, the Blind function is defined in Section and Section of . If the Blind function fails, the Client aborts the protocol. The Client stores the bound_token_input, blind and blinded_element values locally for use when finalizing the issuance protocol to produce a token (as described in ). The Client creates a TokenRequest structured as follows, where structure fields are defined in . The Client then generates an HTTP POST request to send to the Issuer Request URL, with the TokenRequest as the content. Please refer to for an example request.

Issuer-to-Client Response This section is the same as , except that the token type value is 0x8001.

Finalization Upon receipt, the Client handles the response and, if successful, deserializes the values TokenResponse.evaluate_msg and TokenResponse.evaluate_proof, and obtains evaluated_element and proof as follows. If deserialization of either value fails, the Client aborts the protocol. Otherwise, the Client processes the response as follows: Here, the Finalize function is defined in . If this succeeds, the Client creates a token as follows: If the Finalize function fails, the Client aborts the protocol; otherwise it stores the token and its corresponding one-time public key binding_pkE.

Token Binding for Publicly Verifiable Token Issuance This section uses the SerializeElement notation defined in . The constant Nk is defined in .

Client-to-Issuer Request The Client first generates a random 32-byte nonce and creates a token_input as follows: Here, the challenge is an opaque string, and might be provided by the redemption protocol described in . The 2 bytes value 0x8002 represents the token type of Blind RSA (2048-bit) with Token Binding (P-256, SHA-256), where the latter ciphersuite (P-256, SHA-256) will be used for token binding. The token_key_id is a key identifier of the Issuer Public Key pkI, which is computed as described in . The Client generates an ephemeral public-private keypair (pkE, skE) in the group of elliptic curve P-256, where pkE and skE are of Ne-byte length and Ns-byte length, respectively, and the constants Ne = 33 and Ns = 32 are defined in . A RECOMMENDED method for generating ephemeral keypairs is as follows: Here, the long-term seed is probably generated within a secure hardware module and can be used to protect multiple tokens (or a batch of tokens), and the DeriveKeyPair function is defined in . After that, the Client creates a bound_token_input and blinds it as follows: Here, pkI denotes the Issuer Public Key defined in . The PrepareIdentity and Blind functions are defined in Section and Section of , respectively. If the Blind function fails, the Client aborts the protocol. The Client stores the bound_token_input and blind_inv values locally for use when finalizing the issuance protocol to produce a token (as described in ). The Client creates a TokenRequest structured as follows, where structure fields are defined in . The Client then generates an HTTP POST request to send to the Issuer Request URL, with the TokenRequest as the content. Please refer to for an example request.

Issuer-to-Client Response This section is the same as , except that the token type value is 0x8002.

Finalization Upon receipt, the Client handles the response and, if successful, processes the content as follows: Here, the Finalize function is defined in . If this succeeds, the Client creates a token as follows: If the Finalize function fails, the Client aborts the protocol; otherwise it stores the token and its corresponding one-time public key binding_pkE.

Redemption Protocol with Token Binding Extension This section describes the redemption protocol with token binding extension, which includes two types of redemption protocol: one for privately verifiable tokens and another for publicly verifiable tokens.

Token Binding for Privately Verifiable Token Redemption This section uses notation described in , including Generator, RandomScalar, HashToScalar, SerializeElement and DeserializeElement, and SerializeScalar and DeserializeScalar.

Token Binding Generation The Client first creates a proof_input as follows: This document defines three variants for channel binding, and the following one-byte values will be used to distinguish between types: Channel Binding Types

Type	Value
no_channel_binding	0x00
tls_channel_binding	0x01
hpke_channel_binding	0x02

The meaning of the above types and the corresponding channel_binding_secret are described as follows:

The "no_channel_binding" type means that no channel binding is used in the token binding generation, then the channel_binding_secret is a 0-byte value.
The "tls_channel_binding" type means that a TLS channel binding is used in the token binding generation, then the channel_binding_secret is a 32-byte value. The computations of this secret are defined in for TLS 1.2 and in for TLS 1.3, respectively, and the corresponding inputs are defined in .
The "hpke_channel_binding" type means that a HPKE channel binding is used in the token binding generation, then the channel_binding_secret is a 32-byte value. This secret is generated according to , and it is defined as follows, where the Context.Export interface is defined in .

The Client then generates a binding_proof as follows, which is to prove possession of the private key skE corresponding to the previously bound public key pkE: Here, the HashToScalar function is based on SHA-384, and the private key skE MAY be recovered from the long-term seed and the Token.nonce as follows. Here, the DeriveKeyPair function defined in is used to derive only skE. The Client creates a TokenBinding structured as follows: If the "no_channel_binding" type is used, then the token binding can also be generated in another more lightweight way without Schnorr NIZK proof generation and verification. Note that the keypair (skE, pkE) is only used once for a Privacy Pass bound token, so the Client can directly present the one-time private key skE to the Origin to prove possession of this key, and thus it is not a zero-knowledge proof. In this case, the first Ns-byte value of the binding_proof field is set to SerializeScalar(skE) and the second Ns-byte value of this field is set to all zero bytes, and the binding_pkE field is set to zero-length string since the one-time public key pkE can be recovered from the one-time private key skE.

Sending Token and Token Binding When used for Client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-encoded Token structure. This document defines a new parameter, "token_binding", which contains the base64url-encoded TokenBinding structure. This document follows the default padding behavior described in , so the base64url value MUST include padding. The Client presents the Token structure and the TokenBinding structure to the Origin in a new HTTP request using the Authorization header field as follows:

Token and Token Binding Verification Upon receipt, the Origin needs to verify both the token and the token binding, and if any one of verifications fails, this authorization request will be rejected. For the token type of VOPRF(P-384, SHA-384) with Token Binding (P-384, SHA-384) (0x8001), verifying a token requires creating a VOPRF context using the Issuer Private Key, evaluating the bound token input, and comparing the result against the token authenticator value. Here, the SetupVOPRFServer and Evaluate functions are defined in Section and Section of , respectively. Verifying a token binding requires checking that TokenBinding.binding_proof is a valid Schnorr NIZK proof using the TokenBinding.binding_pkE, where the HashToScalar function is based on SHA-384. If the "no_channel_binding" type is used and the token binding is generated without using Schnorr NIZKP, then a token binding is implicitly verified in the above token verification, where the binding_pkE is computed as follows.

Token Binding for Publicly Verifiable Token Redemption This section uses notation described in , including Generator, RandomScalar, HashToScalar, SerializeElement and DeserializeElement, and SerializeScalar and DeserializeScalar.

Token Binding Generation The Client first creates a proof_input as follows: Here, the channel_binding_type and the channel_binding_secret fields are defined in . The Client then generates a binding_proof as follows, which is to prove possession of the private key skE corresponding to the previously bound public key pkE: Here, the HashToScalar function is based on SHA-256, and the private key skE MAY be recovered from the long-term seed and the Token.nonce as follows. Here, the DeriveKeyPair function defined in is used to derive only skE. The Client creates a TokenBinding structured as follows: If the "no_channel_binding" type is used, then the token binding can also be generated by using the same lightweight way as in , thus is omitted here.

Sending Token and Token Binding As an example, the Client presents the Token structure and the TokenBinding structure to the Origin in a new HTTP request using the Authorization header field as follows:

Token and Token Binding Verification Upon receipt, the Origin needs to verify both the token and the token binding, and if any one of verifications fails, this authorization request will be rejected. For the token type of Blind RSA (2048-bit) with Token Binding (P-256, SHA-256) (0x8002), verifying a token requires checking that Token.authenticator is a valid RSA signature over the bound token input using the Issuer Public Key. Here, the RSASSA-PSS-VERIFY function is defined in , using SHA-384 as the hash function, MGF1 with SHA-384 as the Probabilistic Signature Scheme (PSS) mask generation function (MGF), and a 48-byte salt length (sLen). Verifying a token binding requires checking that TokenBinding.binding_proof is a valid Schnorr NIZK proof using the TokenBinding.binding_pkE, where the HashToScalar function is based on SHA-256. If the "no_channel_binding" type is used and the token binding is generated without using Schnorr NIZKP, then a token binding is implicitly verified in the above token verification, where the binding_pkE is computed as follows.

IANA Considerations This document defines two new token types "0x8001" and "0x8002" with the following contents, and requests that IANA add the two values to the "Privacy Pass Token Types" Registry defined in . Note that Token Binding, Ne, Ns are newly added fields, where the latter two MUST be provided if Token Binding is Y, or not applicable (N/A) otherwise.

Token Type VOPRF(P-384, SHA-384) with Token Binding (P-384, SHA-384) Value: 0x8001 Name: VOPRF(P-384, SHA-384) with Token Binding (P-384, SHA-384) Token Structure: As defined in . Token Key Encoding: Serialized using SerializeElement (). TokenChallenge Structure: As defined in . Publicly Verifiable: N Public Metadata: N Private Metadata: N Nk: 48 Nid: 32 Token Binding: Y Ne: 49 Ns: 48 Change controller: IETF Reference: This document, Notes: None

Token Type Blind RSA (2048-bit) with Token Binding (P-256, SHA-256) Value: 0x8002 Name: Blind RSA (2048-bit) with Token Binding (P-256, SHA-256) Token Structure: As defined in . Token Key Encoding: Serialized as a DER-encoded SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID . TokenChallenge Structure: As defined in . Publicly Verifiable: Y Public Metadata: N Private Metadata: N Nk: 256 Nid: 32 Token Binding: Y Ne: 33 Ns: 32 Change controller: IETF Reference: This document, Notes: None