Privacy Pass Issuance Protocol
draft-ietf-privacypass-protocol-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (privacypass WG) | |
|---|---|---|---|
| Authors | Sofia Celi , Alex Davidson , Armando Faz-Hernández , Steven Valdez , Christopher A. Wood | ||
| Last updated | 2022-01-31 | ||
| Replaces | draft-davidson-pp-protocol | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-privacypass-protocol-02
Network Working Group S. Celi
Internet-Draft Cloudflare
Intended status: Informational A. Davidson
Expires: 4 August 2022 Brave Software
A. Faz-Hernandez
Cloudflare
S. Valdez
Google LLC
C.A. Wood
Cloudflare
31 January 2022
Privacy Pass Issuance Protocol
draft-ietf-privacypass-protocol-02
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 August 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Celi, et al. Expires 4 August 2022 [Page 1]
Internet-Draft PP Issuance January 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Issuance Protocol for Privately Verifiable Tokens with Public
Metadata . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 4
3.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 5
3.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Issuer Configuration . . . . . . . . . . . . . . . . . . 6
4. Issuance Protocol for Publicly Verifiable Tokens . . . . . . 7
4.1. Client-to-Issuer Request . . . . . . . . . . . . . . . . 7
4.2. Issuer-to-Client Response . . . . . . . . . . . . . . . . 9
4.3. Finalization . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Issuer Configuration . . . . . . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Token Type . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. "message/token-request" media type . . . . . . . . . 10
6.2.2. "message/token-response" media type . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The Privacy Pass protocol provides a privacy-preserving authorization
mechanism. In essence, the protocol allows clients to provide
cryptographic tokens that prove nothing other than that they have
been created by a given server in the past
[I-D.ietf-privacypass-architecture].
This document describes the issuance protocol for Privacy Pass. It
specifies two variants: one that is privately verifiable based on the
oblivious pseudorandom function from [OPRF], and one that is publicly
verifiable based on the blind RSA signature scheme [BLINDRSA].
Celi, et al. Expires 4 August 2022 [Page 2]
Internet-Draft PP Issuance January 2022
This document DOES NOT cover the architectural framework required for
running and maintaining the Privacy Pass protocol in the Internet
setting. In addition, it DOES NOT cover the choices that are
necessary for ensuring that client privacy leaks do not occur. Both
of these considerations are covered in
[I-D.ietf-privacypass-architecture].
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used throughout this document.
* Client: An entity that provides authorization tokens to services
across the Internet, in return for authorization.
* Issuer: A service produces Privacy Pass tokens to clients.
* Private Key: The secret key used by the Issuer for issuing tokens.
* Public Key: The public key used by the Issuer for issuing and
verifying tokens.
We assume that all protocol messages are encoded into raw byte format
before being sent across the wire.
3. Issuance Protocol for Privately Verifiable Tokens with Public
Metadata
The Privacy Pass issuance protocol is a two message protocol that
takes as input a challenge from the redemption protocol and produces
a token, as shown in the figure below.
Origin Client Issuer
(pkI, info) (skI, pkI, info)
+------------------------------------\
Challenge ----> TokenRequest -------------> |
| (evaluate) |
Token <----+ <--------------- TokenResponse |
\------------------------------------/
Issuers provide a Private and Public Key, denoted skI and pkI,
respectively, used to produce tokens as input to the protocol. See
Section 3.4 for how this key pair is generated.
Celi, et al. Expires 4 August 2022 [Page 3]
Internet-Draft PP Issuance January 2022
Clients provide the following as input to the issuance protocol:
* Issuer name, identifying 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 key_id computed as
described in Section 3.4.
* Challenge value challenge, an opaque byte string. For example,
this might be provided by the redemption protocol in
[HTTP-Authentication].
Both Client and Issuer also share a common public string called info.
Given this configuration and these inputs, the two messages exchanged
in this protocol are described below.
3.1. Client-to-Issuer Request
The Client first creates a verifiable context as follows:
client_context = SetupVerifiableClient(0x0004, pkI)
Here, 0x0004 is the two-octet identifier corresponding to the
OPRF(P-384, SHA-384) ciphersuite in [OPRF].
The Client then creates an issuance request message for a random
value nonce using the input challenge and Issuer key identifier as
follows:
nonce = random(32)
context = SHA256(challenge)
token_input = concat(0x0001, nonce, context, key_id)
blind, blinded_message = client_context.Blind(nonce)
The Client then creates a TokenRequest structured as follows:
struct {
uint16_t token_type = 0x0001;
uint8_t token_key_id;
uint8_t blinded_msg[Nk];
} TokenRequest;
The structure fields are defined as follows:
* "token_type" is a 2-octet integer, which matches the type in the
challenge.
Celi, et al. Expires 4 August 2022 [Page 4]
Internet-Draft PP Issuance January 2022
* "token_key_id" is the least significant byte of the key_id.
* "blinded_msg" is the Nk-octet request defined above.
The Client then generates an HTTP POST request to send to the Issuer,
with the TokenRequest as the body. The media type for this request
is "message/token-request". An example request is shown below, where
Nk = 48.
:method = POST
:scheme = https
:authority = issuer.net
:path = /token-request
accept = message/token-response
cache-control = no-cache, no-store
content-type = message/token-request
content-length = 50
<Bytes containing the TokenRequest>
Upon receipt of the request, the Issuer validates the following
conditions:
* The TokenRequest contains a supported token_type
* The TokenRequest.token_key_id corresponds to a key ID of a Public
Key owned by the issuer.
* The TokenRequest.blinded_msg is of the correct size
If any of these conditions is not met, the Issuer MUST return an HTTP
400 error to the Client, which will forward the error to the client.
3.2. Issuer-to-Client Response
If the Issuer is willing to produce a token token to the Client, the
Issuer completes the issuance flow by computing a blinded response as
follows:
server_context = SetupVerifiableServer(0x0004, skI, pkI)
evaluated_msg, proof = server_context.Evaluate(skI,
TokenRequest.blinded_message, info)
The Issuer then creates a TokenResponse structured as follows:
Celi, et al. Expires 4 August 2022 [Page 5]
Internet-Draft PP Issuance January 2022
struct {
uint8_t evaluated_msg[Nk];
uint8_t proof[Ns+Ns];
} TokenResponse;
The structure fields "evaluated_msg" and "proof" are as computed
above, where Ns is as defined in [OPRF], Section 4.
The Issuer generates an HTTP response with status code 200 whose body
consists of TokenResponse, with the content type set as "message/
token-response".
:status = 200
content-type = message/token-response
content-length = 144
<Bytes containing the TokenResponse>
3.3. Finalization
Upon receipt, the Client handles the response and, if successful,
processes the body as follows:
authenticator = client_context.Finalize(context, blind, pkI,
evaluated_msg, blinded_msg, info)
If this succeeds, the Client then constructs a Token as follows:
struct {
uint16_t token_type = 0x0001
uint8_t nonce[32];
uint8_t context[32];
uint8_t key_id[32];
uint8_t authenticator[Nk];
} Token;
Otherwise, the Client aborts the protocol.
3.4. Issuer Configuration
Issuers are configured with Private and Public Key pairs, each
denoted skI and pkI, respectively, used to produce tokens. Each key
pair MUST be generated as follows:
(skI, pkI) = GenerateKeyPair()
The key identifier for this specific key pair, denoted key_id, is
computed as follows:
Celi, et al. Expires 4 August 2022 [Page 6]
Internet-Draft PP Issuance January 2022
key_id = SHA256(0x0001 || SerializeElement(pkI))
4. Issuance Protocol for Publicly Verifiable Tokens
This section describes a variant of the issuance protocol in
Section 3 for producing publicly verifiable tokens. It differs from
the previous variant in two important ways:
1. The output tokens are publicly verifiable by anyone with the
Issuer public key; and
2. The issuance protocol does not admit public or private metadata
to bind additional context to tokens.
Otherwise, this variant is nearly identical. In particular, Issuers
provide a Private and Public Key, denoted skI and pkI, respectively,
used to produce tokens as input to the protocol. See Section 4.4 for
how this key pair is generated.
Clients provide the following as input to the issuance protocol:
* Issuer name, identifying 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 key_id computed as
described in Section 4.4.
* Challenge value challenge, an opaque byte string. For example,
this might be provided by the redemption protocol in
[HTTP-Authentication].
Given this configuration and these inputs, the two messages exchanged
in this protocol are described below.
4.1. Client-to-Issuer Request
The Client first creates an issuance request message for a random
value nonce using the input challenge and Issuer key identifier as
follows:
nonce = random(32)
context = SHA256(challenge)
token_input = concat(0x0002, nonce, context, key_id)
blinded_msg, blind_inv = rsabssa_blind(pkI, token_input)
The Client then creates a TokenRequest structured as follows:
Celi, et al. Expires 4 August 2022 [Page 7]
Internet-Draft PP Issuance January 2022
struct {
uint16_t token_type = 0x0002
uint8_t token_key_id;
uint8_t blinded_msg[Nk];
} TokenRequest;
The structure fields are defined as follows:
* "token_type" is a 2-octet integer, which matches the type in the
challenge.
* "token_key_id" is the least significant byte of the key_id.
* "blinded_msg" is the Nk-octet request defined above.
The Client then generates an HTTP POST request to send to the Issuer,
with the TokenRequest as the body. The media type for this request
is "message/token-request". An example request is shown below, where
Nk = 512.
:method = POST
:scheme = https
:authority = issuer.net
:path = /token-request
accept = message/token-response
cache-control = no-cache, no-store
content-type = message/token-request
content-length = 514
<Bytes containing the TokenRequest>
Upon receipt of the request, the Issuer validates the following
conditions:
* The TokenRequest contains a supported token_type.
* The TokenRequest.token_key_id corresponds to a key ID of a Public
Key owned by the issuer.
* The TokenRequest.blinded_msg is of the correct size.
If any of these conditions is not met, the Issuer MUST return an HTTP
400 error to the Client, which will forward the error to the client.
Celi, et al. Expires 4 August 2022 [Page 8]
Internet-Draft PP Issuance January 2022
4.2. Issuer-to-Client Response
If the Issuer is willing to produce a token token to the Client, the
Issuer completes the issuance flow by computing a blinded response as
follows:
blind_sig = rsabssa_blind_sign(skI, TokenRequest.blinded_rmsg)
The Issuer generates an HTTP response with status code 200 whose body
consists of blind_sig, with the content type set as "message/token-
response".
:status = 200
content-type = message/token-response
content-length = 512
<Bytes containing the TokenResponse>
4.3. Finalization
Upon receipt, the Client handles the response and, if successful,
processes the body as follows:
authenticator = rsabssa_finalize(pkI, nonce, blind_sig, blind_inv)
If this succeeds, the Client then constructs a Token as described in
[HTTP-Authentication] as follows:
struct {
uint16_t token_type = 0x0002
uint8_t nonce[32];
uint8_t context[32];
uint8_t key_id[32];
uint8_t authenticator[Nk];
} Token;
Otherwise, the Client aborts the protocol.
4.4. Issuer Configuration
Issuers are configured with Private and Public Key pairs, each
denoted skI and pkI, respectively, used to produce tokens. Each key
pair MUST be generated as as a valid 4096-bit RSA private key
according to [TODO]. The key identifier for a keypair (skI, pkI),
denoted key_id, is computed as SHA256(encoded_key), where encoded_key
is a DER-encoded SubjectPublicKeyInfo object carrying pkI.
Celi, et al. Expires 4 August 2022 [Page 9]
Internet-Draft PP Issuance January 2022
5. Security considerations
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in [OPRF] and blind RSA protocol defnied in
[BLINDRSA]. All security considerations described in the VOPRF
document also apply in the Privacy Pass use-case. Considerations
related to broader privacy and security concerns in a multi-Client
and multi-Issuer setting are deferred to the Architecture document
[I-D.ietf-privacypass-architecture].
6. IANA considerations
6.1. Token Type
This document updates the "Token Type" Registry with the following
values.
+======+=============+============+========+========+===+===========+
|Value | Name | Publicly |Public |Private |Nk | Reference |
| | | Verifiable |Metadata|Metadata| | |
+======+=============+============+========+========+===+===========+
|0x0001| OPRF(P-384, | N |Y |N |48 | Section 3 |
| | SHA-384) | | | | | |
+------+-------------+------------+--------+--------+---+-----------+
|0x0002| Blind RSA, | Y |N |N |512| Section 4 |
| | 4096 | | | | | |
+------+-------------+------------+--------+--------+---+-----------+
Table 1: Token Types
6.2. Media Types
This specification defines the following protocol messages, along
with their corresponding media types:
* TokenRequest: "message/token-request"
* TokenResponse: "message/token-response"
The definition for each media type is in the following subsections.
6.2.1. "message/token-request" media type
Type name: message
Subtype name: token-request
Required parameters: N/A
Celi, et al. Expires 4 August 2022 [Page 10]
Internet-Draft PP Issuance January 2022
Optional parameters: None
Encoding considerations: only "8bit" or "binary" is permitted
Security considerations: see Section 5
Interoperability considerations: N/A
Published specification: this specification
Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information: Magic number(s): N/A
Deprecated alias names for this type: N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: see Aut
hors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IESG
6.2.2. "message/token-response" media type
Type name: message
Subtype name: access-token-response
Required parameters: N/A
Optional parameters: None
Encoding considerations: only "8bit" or "binary" is permitted
Security considerations: see Section 5
Interoperability considerations: N/A
Celi, et al. Expires 4 August 2022 [Page 11]
Internet-Draft PP Issuance January 2022
Published specification: this specification
Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information: Magic number(s): N/A
Deprecated alias names for this type: N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: see Aut
hors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IESG
7. Normative References
[BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind
Signatures", Work in Progress, Internet-Draft, draft-irtf-
cfrg-rsa-blind-signatures-02, 2 August 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
rsa-blind-signatures-02>.
[HTTP-Authentication]
"The Privacy Pass HTTP Authentication Scheme", n.d.,
<https://datatracker.ietf.org/doc/html/draft-pauly-
privacypass-auth-scheme-00>.
[I-D.ietf-privacypass-architecture]
Davidson, A. and C. A. Wood, "Privacy Pass Architectural
Framework", Work in Progress, Internet-Draft, draft-ietf-
privacypass-architecture-01, 22 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-architecture-01>.
[OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) using
Prime-Order Groups", Work in Progress, Internet-Draft,
Celi, et al. Expires 4 August 2022 [Page 12]
Internet-Draft PP Issuance January 2022
draft-irtf-cfrg-voprf-08, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
voprf-08>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://doi.org/10.17487/RFC2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://doi.org/10.17487/RFC8174>.
Appendix A. Acknowledgements
The authors of this document would like to acknowledge the helpful
feedback and discussions from Benjamin Schwartz, Joseph Salowey,
Sofia Celi, and Tara Whalen.
Authors' Addresses
Sofía Celi
Cloudflare
Lisbon
Portugal
Email: sceli@cloudflare.com
Alex Davidson
Brave Software
Lisbon
Portugal
Email: alex.davidson92@gmail.com
Armando Faz-Hernandez
Cloudflare
101 Townsend St
San Francisco,
United States of America
Email: armfazh@cloudflare.com
Celi, et al. Expires 4 August 2022 [Page 13]
Internet-Draft PP Issuance January 2022
Steven Valdez
Google LLC
Email: svaldez@chromium.org
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco,
United States of America
Email: caw@heapingbits.net
Celi, et al. Expires 4 August 2022 [Page 14]