Privacy Pass Issuance Protocol
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]