idnits 2.17.00 (12 Aug 2021) /tmp/idnits51008/draft-private-access-tokens-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '32' on line 952 == Missing Reference: 'Nk' is mentioned on line 951, but not defined == Missing Reference: 'Ne' is mentioned on line 1264, but not defined == Missing Reference: 'Np' is mentioned on line 949, but not defined == Missing Reference: 'Ns' is mentioned on line 1266, but not defined == Outdated reference: A later version (-03) exists of draft-irtf-cfrg-rsa-blind-signatures-02 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-rsa-blind-signatures (ref. 'BLINDSIG') == Outdated reference: draft-irtf-cfrg-hpke has been published as RFC 9180 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') == Outdated reference: A later version (-09) exists of draft-irtf-cfrg-voprf-08 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-voprf (ref. 'VOPRF') == Outdated reference: A later version (-04) exists of draft-ietf-privacypass-protocol-01 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hendrickson 3 Internet-Draft Google LLC 4 Intended status: Standards Track J. Iyengar 5 Expires: 28 April 2022 Fastly 6 T. Pauly 7 Apple Inc. 8 S. Valdez 9 Google LLC 10 C.A. Wood 11 Cloudflare 12 25 October 2021 14 Private Access Tokens 15 draft-private-access-tokens-01 17 Abstract 19 This document defines a protocol for issuing and redeeming privacy- 20 preserving access tokens. These tokens can adhere to an issuance 21 policy, allowing a service to limit access according to the policy 22 without tracking client identity. 24 Discussion Venues 26 This note is to be removed before publishing as an RFC. 28 Source for this draft and an issue tracker can be found at 29 https://github.com/tfpauly/privacy-proxy. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 28 April 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1.1. Rate-limited Access . . . . . . . . . . . . . . . . . 4 67 1.1.2. Client Geo-Location . . . . . . . . . . . . . . . . . 5 68 1.1.3. Private Client Authentication . . . . . . . . . . . . 5 69 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 70 1.3. Properties and Requirements . . . . . . . . . . . . . . . 7 71 1.4. Client Identity . . . . . . . . . . . . . . . . . . . . . 9 72 1.5. User Interaction . . . . . . . . . . . . . . . . . . . . 10 73 2. Notation and Terminology . . . . . . . . . . . . . . . . . . 10 74 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4. Token Challenge and Redemption Protocol . . . . . . . . . . . 13 76 4.1. Token Challenge . . . . . . . . . . . . . . . . . . . . . 14 77 4.2. Token Redemption . . . . . . . . . . . . . . . . . . . . 15 78 5. Issuance Protocol . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1. State Requirements . . . . . . . . . . . . . . . . . . . 17 80 5.1.1. Client State . . . . . . . . . . . . . . . . . . . . 17 81 5.1.2. Mediator State . . . . . . . . . . . . . . . . . . . 18 82 5.1.3. Issuer State . . . . . . . . . . . . . . . . . . . . 19 83 5.2. Issuance HTTP Headers . . . . . . . . . . . . . . . . . . 19 84 5.3. Client-to-Mediator Request . . . . . . . . . . . . . . . 20 85 5.4. Mediator-to-Issuer Request . . . . . . . . . . . . . . . 23 86 5.5. Issuer-to-Mediator Response . . . . . . . . . . . . . . . 24 87 5.6. Mediator-to-Client Response . . . . . . . . . . . . . . . 25 88 5.7. Encrypting Origin Names . . . . . . . . . . . . . . . . . 26 89 5.8. Non-Interactive Schnorr Proof of Knowledge . . . . . . . 27 90 6. Instantiating Uses Cases . . . . . . . . . . . . . . . . . . 28 91 6.1. Rate-limited Access . . . . . . . . . . . . . . . . . . . 28 92 6.2. Client Geo-Location . . . . . . . . . . . . . . . . . . . 29 93 6.3. Private Client Authentication . . . . . . . . . . . . . . 29 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 95 7.1. Client Identity . . . . . . . . . . . . . . . . . . . . . 30 96 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 97 7.3. Channel Security . . . . . . . . . . . . . . . . . . . . 30 98 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 99 8.1. Client Token State and Origin Tracking . . . . . . . . . 30 100 8.2. Origin Verification . . . . . . . . . . . . . . . . . . . 31 101 8.3. Client Identification with Unique Keys . . . . . . . . . 31 102 8.4. Collusion Among Different Entities . . . . . . . . . . . 32 103 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 32 104 9.1. Origin Key Rollout . . . . . . . . . . . . . . . . . . . 32 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 106 10.1. Authentication Scheme . . . . . . . . . . . . . . . . . 32 107 10.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 33 108 10.3. Media Types . . . . . . . . . . . . . . . . . . . . . . 33 109 10.3.1. "message/access-token-request" media type . . . . . 33 110 10.3.2. "message/access-token-response" media type . . . . . 34 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 113 11.2. Informative References . . . . . . . . . . . . . . . . . 36 114 Appendix A. Related Work: Privacy Pass . . . . . . . . . . . . . 36 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 117 1. Introduction 119 Servers commonly use passive and persistent identifiers associated 120 with clients, such as IP addresses or device identifiers, for 121 enforcing access and usage policies. For example, a server might 122 limit the amount of content an IP address can access over a given 123 time period (referred to as a "metered paywall"), or a server might 124 rate-limit access from an IP address to prevent fraud and abuse. 125 Servers also commonly use the client's IP address as a strong 126 indicator of the client's geographic location to limit access to 127 services or content to a specific geographic area (referred to as 128 "geofencing"). 130 However, passive and persistent client identifiers can be used by any 131 entity that has access to it without the client's express consent. A 132 server can use a client's IP address or its device identifier to 133 track client activity. A client's IP address, and therefore its 134 location, is visible to all entities on the path between the client 135 and the server. These entities can trivially track a client, its 136 location, and servers that the client visits. 138 A client that wishes to keep its IP address private can hide its IP 139 address using a proxy service or a VPN. However, doing so severely 140 limits the client's ability to access services and content, since 141 servers might not be able to enforce their policies without a stable 142 and unique client identifier. 144 This document describes an architecture for Private Access Tokens 145 (PATs), using RSA Blind Signatures as defined in [BLINDSIG], as an 146 explicit replacement for these passive client identifiers. These 147 tokens are privately issued to clients upon request and then redeemed 148 by servers in such a way that the issuance and redemption events for 149 a given token are unlinkable. 151 At first glance, using PATs in lieu of passive identifiers for policy 152 enforcement suggests that some entity needs to know both the client's 153 identity and the server's policy, and such an entity would be 154 trivially able to track a client and its activities. However, with 155 appropriate mediation and separation between the parties involved in 156 the issuance and the redemption protocols, it is possible to 157 eliminate this information concentration without any functional 158 regressions. This document describes such a protocol. 160 The relationship of this work to Privacy Pass 161 ([I-D.ietf-privacypass-protocol]) is discussed in Appendix A. 163 1.1. Motivation 165 This section describes classes of use cases where an origin would 166 traditionally use a stable and unique client identifier for enforcing 167 attribute-based policy. Hiding these identifiers from origins would 168 therefore require an alternative for origins to continue enforcing 169 their policies. Using the Privacy Address Token architecture for 170 addressing these use cases is described in Section 6. 172 1.1.1. Rate-limited Access 174 An origin provides rate-limited access to content to a client over a 175 fixed period of time. The origin does not need to know the client's 176 identity, but needs to know that a requesting client has not exceeded 177 the maximum rate set by the origin. 179 One example of this use case is a metered paywall, where an origin 180 limits the number of page requests to each unique user over a period 181 of time before the user is required to pay for access. The origin 182 typically resets this state periodically, say, once per month. For 183 example, an origin may serve ten (major content) requests in a month 184 before a paywall is enacted. Origins may want to differentiate quick 185 refreshes from distinct accesses. 187 Another example of this use case is rate-limiting page accesses to a 188 client to help prevent fraud. Operations that are sensitive to 189 fraud, such as account creation on a website, often employ rate- 190 limiting as a defense in depth strategy. Captchas or additional 191 verification can be required by these pages when a client exceeds a 192 set rate-limit. 194 Origins routinely use client IP addresses for this purpose. 196 1.1.2. Client Geo-Location 198 An origin provides access to or customizes content based on the geo- 199 location of the client. The origin does not need to know the 200 client's identity, but needs to know the geo-location, with some 201 level of accuracy, for providing service. 203 A specific example of this use case is "geo-fencing", where an origin 204 restricts the available content it can serve based on the client's 205 geographical region. 207 Origins almost exclusively use client IP addresses for this purpose. 209 1.1.3. Private Client Authentication 211 An origin provides access to content for clients that have been 212 authorized by a delegated or known mediator. The origin does not 213 need to know the client's identity. 215 A specific example of this use case is a federated service that 216 authorizes users for access to specific sites, such as a federated 217 news service or a federated video streaming service. The origin 218 trusts the federator to authorize users and needs proof that the 219 federator authorized a particular user, but it does not need the 220 user's identity to provide access to content. 222 Origins could currently redirect clients to a federator for 223 authentication, but origins could then track the client's federator 224 user ID or the client's IP address across accesses. 226 1.2. Architecture 228 At a high level, the PAT architecture seeks to solve the following 229 problem: in the absence of a stable Client identifier, an Origin 230 needs to verify the identity of a connecting Client and enforce 231 access policies for the incoming Client. To accomplish this, the PAT 232 architecture employs four functional components: 234 1. Client: requests a PAT from an Issuer and presents it to a Origin 235 for access to the Origin's service. 237 2. Mediator: authenticates a Client, using information such as its 238 IP address, an account name, or a device identifier. Anonymizes 239 a Client to an Issuer and relays information between an 240 anonymized Client and an Issuer. 242 3. Issuer: issues PATs to an anonymized Client on behalf of an 243 Origin. Anonymizes an Origin to a Mediator and enforces the 244 Origin's policy. 246 4. Origin: directs a Client to an Issuer with a challenge and 247 enables access to content or services to the Client upon 248 verification of any PAT sent in response by the Client. 250 In the PAT architecture, these four components interact as follows. 252 An Origin designates a trusted Issuer to issue tokens for it. The 253 Origin then redirects any incoming Clients to the Issuer for policy 254 enforcement, expecting the Client to return with a proof from the 255 Issuer that the Origin's policy has been enforced for this Client. 257 The Client employs a trusted Mediator through which it communicates 258 with the Issuer for this proof. The Mediator performs three 259 important functions: 261 * authenticate and associate the Client with a stable identifier; 263 * maintain issuance state for the Client and relay it to the Issuer; 264 and 266 * anonymize the Client and mediate communication between the Client 267 and the Issuer. 269 When a Mediator-anonymized Client requests a token from an Issuer, 270 the Issuer enforces the Origin's policies based on the received 271 Client issuance state and Origin policy. Issuers know the Origin's 272 policies and enforce them on behalf of the Origin. An example policy 273 is: "Limit 10 accesses per Client". More examples and their use 274 cases are discussed in Section 6. The Issuer does not learn the 275 Client's true identity. 277 Finally, the Origin provides access to content or services to a 278 Client upon verifying a PAT presented by the Client. Verification of 279 this token serves as proof that the Client meets the Origin's 280 policies as enforced by the delegated Issuer with the help of a 281 Mediator. The Origin can then provide any services or content gated 282 behind these policies to the Client. 284 Figure 1 shows the components of the PAT architecture described in 285 this document. Protocol details follow in Section 4 and Section 5. 287 Client Mediator Issuer Origin 289 <---------------------------------------- Challenge \ 290 | 291 +--------------------------------------------\ | 292 | TokenRequest ---> | | 293 | (validate) | | 294 | (attach state) | | 295 | TokenRequest ---> | | PAT 296 | (validate) | PAT | Challenge/ 297 | (evaluate) | Issuance | Response 298 | <--- TokenResponse | Flow | Flow 299 | (evaluate) | | 300 | (update state) | | 301 | <--- TokenResponse | | 302 ---------------------------------------------/ | 303 | 304 Response -------------------------------------- > / 306 Figure 1: PAT Architectural Components 308 1.3. Properties and Requirements 310 In this architecture, the Mediator, Issuer, and Origin each have 311 partial knowledge of the Client's identity and actions, and each 312 entity only knows enough to serve its function (see Section 2 for 313 more about the pieces of information): 315 * The Mediator knows the Client's identity and learns the Client's 316 public key (CLIENT_KEY), the Issuer being targeted (ISSUER_NAME), 317 the period of time for which the Issuer's policy is valid 318 (ISSUER_POLICY_WINDOW), and the number of tokens issued to a given 319 Client for the claimed Origin in the given policy window. The 320 Mediator does not know the identity of the Origin the Client is 321 trying to access (ORIGIN_ID), but knows a Client-anonymized 322 identifier for it (ANON_ORIGIN_ID). 324 * The Issuer knows the Origin's secret (ORIGIN_SECRET) and policy 325 about client access, and learns the Origin's identity 326 (ORIGIN_NAME) and the number of previous tokens issued to the 327 Client (as communicated by the Mediator) during issuance. The 328 Issuer does not learn the Client's identity. 330 * The Origin knows the Issuer to which it will delegate an incoming 331 Client (ISSUER_NAME), and can verify that any tokens presented by 332 the Client were signed by the Issuer. The Origin does not learn 333 which Mediator was used by a Client for issuance. 335 Since an Issuer enforces policies on behalf of Origins, a Client is 336 required to reveal the Origin's identity to the delegated Issuer. It 337 is a requirement of this architecture that the Mediator not learn the 338 Origin's identity so that, despite knowing the Client's identity, a 339 Mediator cannot track and concentrate information about Client 340 activity. 342 An Issuer expects a Mediator to verify its Clients' identities 343 correctly, but an Issuer cannot confirm a Mediator's efficacy or the 344 Mediator-Client relationship directly without learning the Client's 345 identity. Similarly, an Origin does not know the Mediator's 346 identity, but ultimately relies on the Mediator to correctly verify 347 or authenticate a Client for the Origin's policies to be correctly 348 enforced. An Issuer therefore chooses to issue tokens to only known 349 and reputable Mediators; the Issuer can employ its own methods to 350 determine the reputation of a Mediator. 352 A Mediator is expected to employ a stable Client identifier, such as 353 an IP address, a device identifier, or an account at the Mediator, 354 that can serve as a reasonable proxy for a user with some creation 355 and maintenance cost on the user. 357 For the Issuance protocol, a Client is expected to create and 358 maintain stable and explicit secrets for time periods that are on the 359 scale of Issuer policy windows. Changing these secrets arbitrarily 360 during a policy window can result in token issuance failure for the 361 rest of the policy window; see Section 5.1.1 for more details. A 362 Client can use a service offered by its Mediator or a third-party to 363 store these secrets, but it is a requirement of the PAT architecture 364 that the Mediator not be able to learn these secrets. 366 The privacy guarantees of the PAT architecture, specifically those 367 around separating the identity of the Client from the names of the 368 Origins that it accesses, are based on the expectation that there is 369 not collusion between the entities that know about Client identity 370 and those that know about Origin identity. Clients choose and share 371 information with Mediators, and Origins choose and share policy with 372 Issuers; however, the Mediator is generally expected to not be 373 colluding with Issuers or Origins. If this occurs, it can become 374 possible for a Mediator to learn or infer which Origins a Client is 375 accessing, or for an Origin to learn or infer the Client identity. 376 For further discussion, see Section 8.4. 378 1.4. Client Identity 380 The PAT architecture does not enforce strong constraints around the 381 definition of a Client identity and allows it to be defined entirely 382 by a Mediator. If a user can create an arbitrary number of Client 383 identities that are accepted by one or more Mediators, a malicious 384 user can easily abuse the system to defeat the Issuer's ability to 385 enforce per-Client policies. 387 These multiple identities could be fake or true identities. 389 A Mediator alone is responsible for detecting and weeding out fake 390 Client identities in the PAT architecture. An Issuer relies on a 391 Mediator's reputation; as explained in Section 1.3, the correctness 392 of the architecture hinges on Issuers issuing tokens to only known 393 and reputable Mediators. 395 Users have multiple true identities on the Internet however, and as a 396 result, it seems possible for a user to abuse the system without 397 having to create fake identities. For instance, a user could use 398 multiple Mediators, authenticating with each one using a different 399 true identity. 401 The PAT architecture offers no panacea against this potential abuse. 402 We note however that the usages of PATs will cause the ecosystem to 403 evolve and offer practical mitigations, such as: 405 * An Issuer can learn the properties of a Mediator - specifically, 406 which stable Client identifier is authenticated by the Mediator - 407 to determine whether the Mediator is acceptable for an Origin. 409 * An Origin can choose an Issuer based on the types of Mediators 410 accepted by the Issuer, or the Origin can communicate its 411 constraints to the designated Issuer. 413 * An Origin can direct a user to a specific Issuer based on client 414 properties that are visible. For instance, properties that are 415 observable in the HTTP User Agent string. 417 * The number of true Mediator-authenticated identities for a user is 418 expected to be small, and therefore likely to be small enough to 419 not matter for certain use cases. For instance, when PATs are 420 used to prevent fraud by rate-limiting Clients (as described in 421 Section 1.1.1), an Origin might be tolerant of the potential 422 amplification caused by an attacking user's access to multiple 423 true identities with Issuer-trusted Mediators. 425 1.5. User Interaction 427 When used in contexts like websites, origin servers that challenge 428 clients for Private Access Tokens need to consider how to optimize 429 their interaction model to ensure a good user experience. 431 Private Access Tokens are designed to be used without explicit user 432 involvement. Since tokens are only valid for a single origin and in 433 response to a specific challenge, there is no need for a user to 434 manage a limited pool of tokens across origins. The information that 435 is available to an origin upon token redemption is limited to the 436 fact that this is a client that passed a Mediator's checks and has 437 not exceeded the per-origin limit defined by an Issuer. Generally, 438 if a user is willing to use Private Access Tokens with a particular 439 origin (or all origins), there is no need for per-challenge user 440 interaction. Note that the Issuance flow may separately involve user 441 interaction if the Mediator needs to authenticate the Client. 443 Since tokens are issued using a separate connection through a 444 Mediator to an Issuer, the process of issuance can add user- 445 perceivable latency. Origins SHOULD NOT block useful work on token 446 authentication. Instead, token authentication can be used in similar 447 ways to CAPTCHA validation today, but without the need for user 448 interaction. If issuance is taking a long time, a website could show 449 an indicator that it is waiting, or fall back to another method of 450 user validation. 452 If an origin is requesting an unexpected number of tokens, such as 453 requesting token authentication more than once for a single website 454 load, it can indicate that the server is not functioning correctly, 455 or is trying to attack or overload the client or issuance servers. 456 In such cases, the client SHOULD ignore redundant token challengers, 457 or else alert the user. 459 2. Notation and Terminology 461 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 462 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 463 "OPTIONAL" in this document are to be interpreted as described in 464 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 465 capitals, as shown here. 467 Unless said otherwise, this document encodes protocol messages in TLS 468 notation from [TLS13], Section 3. 470 This draft includes pseudocode that uses the functions and 471 conventions defined in [HPKE]. 473 Encoding an integer to a sequence of bytes in network byte order is 474 described using the function "encode(n, v)", where "n" is the number 475 of bytes and "v" is the integer value. The function "len()" returns 476 the length of a sequence of bytes. 478 The following terms are defined to refer to the different pieces of 479 information passed through the system: 481 ISSUER_NAME: The Issuer Name identifies which Issuer is able to 482 provide tokens for a Client. The Client sends the Issuer Name to 483 the Mediator so the Mediator know where to forward requests. Each 484 Issuer is associated with a specific ISSUER_POLICY_WINDOW. 486 ISSUER_POLICY_WINDOW: The period over which an Issuer will track 487 access policy, defined in terms of seconds and represented as a 488 uint64. The state that the Mediator keeps for a Client is 489 specific to a policy window. The effective policy window for a 490 specific Client starts when the Client first sends a request 491 associated with an Issuer. 493 ORIGIN_TOKEN_KEY: The public key used when generating and verifying 494 Private Access Tokens. Each Origin Token Key is unique to a 495 single Origin. The corresponding private key is held by the 496 Issuer. 498 ISSUER_KEY: The public key used to encrypt values such as 499 ORIGIN_NAME in requests from Clients to the Issuer, so that 500 Mediators cannot learn the ORIGIN_NAME value. Each ISSUER_KEY is 501 used across all requests on the Issuer, for different Origins. 503 ORIGIN_NAME: The name of the Origin that requests and verifies 504 Private Access Tokens. 506 ANON_ORIGIN_ID: An identifier that is generated by the Client and 507 marked on requests to the Mediator, which represents a specific 508 Origin anonymously. The Client generates a stable ANON_ORIGIN_ID 509 for each ORIGIN_NAME, to allow the Mediator to count token access 510 without learning the ORIGIN_NAME. 512 CLIENT_KEY: A public key chosen by the Client and shared only with 513 the Mediator. 515 CLIENT_SECRET: The secret key used by the Client during token 516 issuance, whose public key (CLIENT_KEY) is shared with the 517 Mediator. 519 ORIGIN_SECRET: The secret key used by the Issuer during token 520 issuance, whose public key is not shared with anyone. 522 ANON_ISSUER_ORIGIN_ID: An identifier that is generated by Issuer 523 based on an ORIGIN_SECRET that is per-Client and per-Origin. See 524 Section 5.6 for details of derivation. 526 3. Configuration 528 Issuers MUST provide three parameters for configuration: 530 1. ISSUER_KEY: a KeyConfig as defined in [OHTTP] to use when 531 encrypting the ORIGIN_NAME in issuance requests. This parameter 532 uses resource media type "application/ohttp-keys". 534 2. ISSUER_POLICY_WINDOW: a uint64 of seconds as defined in 535 Section 2. 537 3. ISSUER_REQUEST_URI: a Private Access Token request URL for 538 generating access tokens. For example, an Issuer URL might be 539 https://issuer.example.net/access-token-request. This parameter 540 uses resource media type "text/plain". 542 These parameters can be obtained from an Issuer via a directory 543 object, which is a JSON object whose field names and values are raw 544 values and URLs for the parameters. 546 +======================+==========================================+ 547 | Field Name | Value | 548 +======================+==========================================+ 549 | issuer-key | ISSUER_KEY resource URL as a JSON string | 550 +----------------------+------------------------------------------+ 551 | issuer-policy-window | ISSUER_POLICY_WINDOW as a JSON number | 552 +----------------------+------------------------------------------+ 553 | issuer-request-uri | ISSUER_REQUEST_URI resource URL as a | 554 | | JSON string | 555 +----------------------+------------------------------------------+ 557 Table 1 559 As an example, the Issuer's JSON directory could look like: 561 { 562 "issuer-key": "https://issuer.example.net/key", 563 "issuer-token-window": 86400, 564 "issuer-request-uri": "https://issuer.example.net/access-token-request" 565 } 567 Mediators MUST provide a single parameter for configuration, 568 MEDIATOR_REQUEST_URI, wich is Private Access Token request URL for 569 proxying protocol messages to Issuers. For example, a Mediator URL 570 might be https://mediator.example.net/relay-access-token-request. 571 Similar to Issuers, Mediators make this parameter available by a 572 directory object with the following contents: 574 +======================+===================================+ 575 | Field Name | Value | 576 +======================+===================================+ 577 | mediator-request-uri | MEDIATOR_REQUEST_URI resource URL | 578 +----------------------+-----------------------------------+ 580 Table 2 582 As an example, the Mediator's JSON dictionary could look like: 584 { 585 "mediator-request-uri": "https://mediator.example.net/relay-access-token-request." 586 } 588 Issuer and Mediator directory resources have the media type 589 "application/json" and are located at the well-known location /.well- 590 known/private-access-tokens-directory. 592 4. Token Challenge and Redemption Protocol 594 This section describes the interactive protocol for the token 595 challenge and redemption flow between a Client and an Origin. 597 Token redemption is performed using HTTP Authentication ([RFC7235]), 598 with the scheme "PrivateAccessToken". Origins challenge Clients to 599 present a unique, single-use token from a specific Issuer. Once a 600 Client has received a token from that Issuer, it presents the token 601 to the Origin. 603 Token redemption only requires Origins to verify token signatures 604 computed using the Blind Signature protocol from [BLINDSIG]. Origins 605 are not required to implement the complete Blind Signature protocol. 606 (In contrast, token issuance requires Clients and Issuers to 607 implement the Blind Signature protocol, as described in Section 5.) 609 4.1. Token Challenge 611 Origins send a token challenge to Clients in an "WWW-Authenticate" 612 header with the "PrivateAccessToken" scheme. This challenge includes 613 a TokenChallenge message, along with information about what keys to 614 use when requesting a token from the Issuer. 616 The TokenChallenge message has the following structure: 618 struct { 619 uint8_t version; 620 opaque origin_name<1..2^16-1>; 621 opaque issuer_name<1..2^16-1>; 622 opaque redemption_nonce[32]; 623 } TokenChallenge; 625 The structure fields are defined as follows: 627 * "version" is a 1-octet integer. This document defines version 1. 629 * "origin_name" is a string containing the name of the Origin 630 (ORIGIN_NAME). 632 * "issuer_name" is a string containing the name of the Issuer 633 (ISSUER_NAME). 635 * "redemption_nonce" is a fresh 32-byte nonce generated for each 636 redemption request. 638 When used in an authentication challenge, the "PrivateAccessToken" 639 scheme uses the following attributes: 641 * "challenge", which contains a base64url-encoded [RFC4648] 642 TokenChallenge value. This MUST be unique for every 401 HTTP 643 response to prevent replay attacks. 645 * "token-key", which contains a base64url encoding of the 646 SubjectPublicKeyInfo object for use with the RSA Blind Signature 647 protocol (ORIGIN_TOKEN_KEY). 649 * "issuer-key", which contains a base64url encoding of a KeyConfig 650 as defined in [OHTTP] to use when encrypting the ORIGIN_NAME in 651 issuance requests (ISSUER_KEY). 653 * "max-age", an optional attribute that consists of the number of 654 seconds for which the challenge will be accepted by the Origin. 656 Origins MAY also include the standard "realm" attribute, if desired. 658 As an example, the WWW-Authenticate header could look like this: 660 WWW-Authenticate: PrivateAccessToken challenge=abc..., token-key=123..., 661 issuer-key=456... 663 Upon receipt of this challenge, a Client uses the message and keys in 664 the Issuance protocol (see Section 5). If the TokenChallenge has a 665 version field the Client does not recognize or support, it MUST NOT 666 parse or respond to the challenge. This document defines version 1, 667 which indicates use of private tokens based on RSA Blind Signatures 668 [BLINDSIG], and determines the rest of the structure contents. 670 Note that it is possible for the WWW-Authenticate header to include 671 multiple challenges, in order to allow the Client to fetch a batch of 672 multiple tokens for future use. 674 For example, the WWW-Authenticate header could look like this: 676 WWW-Authenticate: PrivateAccessToken challenge=abc..., token-key=123..., 677 issuer-key=456..., PrivateAccessToken challenge=def..., token-key=234..., 678 issuer-key=567... 680 4.2. Token Redemption 682 The output of the issuance protocol is a token that corresponds to 683 the Origin's challenge (see Section 4.1). A token is a structure 684 that begins with a single byte that indicates a version, which MUST 685 match the version in the TokenChallenge structure. 687 struct { 688 uint8_t version; 689 uint8_t token_key_id[32]; 690 uint8_t message[32]; 691 uint8_t signature[Nk]; 692 } Token; 694 The structure fields are defined as follows: 696 * "version" is a 1-octet integer. This document defines version 1. 698 * "token_key_id" is a collision-resistant hash that identifies the 699 ORIGIN_TOKEN_KEY used to produce the signature. This is generated 700 as SHA256(public_key), where public_key is a DER-encoded 701 SubjectPublicKeyInfo object carrying the public key. 703 * "message" is a 32-octet message containing the hash of the 704 original TokenChallenge, SHA256(TokenChallenge). This message is 705 signed by the signature, 707 * "signature" is a Nk-octet RSA Blind Signature that covers the 708 message. For version 1, Nk is indicated by size of the Token 709 structure and may be 256, 384, or 512. These correspond to RSA 710 2048, 3072, and 4096 bit keys. Clients implementing version 1 711 MUST support signature sizes with Nk of 512 and 256. 713 When used for client authorization, the "PrivateAccessToken" 714 authentication scheme defines one parameter, "token", which contains 715 the base64url-encoded Token struct. All unknown or unsupported 716 parameters to "PrivateAccessToken" authentication credentials MUST be 717 ignored. 719 Clients present this Token structure to Origins in a new HTTP request 720 using the Authorization header as follows: 722 Authorization: PrivateAccessToken token=abc... 724 Origins verify the token signature using the corresponding policy 725 verification key from the Issuer, and validate that the message 726 matches the hash of a TokenChallenge it previously issued and is 727 still valid, SHA256(TokenChallenge), and that the version of the 728 Token matches the version in the TokenChallenge. The TokenChallenge 729 MAY be bound to a specific HTTP session with Client, but Origins can 730 also accept tokens for valid challenges in new sessions. 732 If a Client's issuance request fails with a 401 error, as described 733 in Section 5.4, the Client MUST react to the challenge as if it could 734 not produce a valid Authorization response. 736 5. Issuance Protocol 738 This section describes the Issuance protocol for a Client to request 739 and receive a token from an Issuer. Token issuance involves a 740 Client, Mediator, and Issuer, with the following steps: 742 1. The Client sends a token request to the Mediator, encrypted using 743 an Issuer-specific key 745 2. The Mediator validates the request and proxies the request to the 746 Issuer 748 3. The Issuer decrypts the request and sends a response back to the 749 Mediator 751 4. The Mediator verifies the response and proxies the response to 752 the Client 754 The Issuance protocol has a number of underlying cryptographic 755 dependencies for operation: 757 * [HPKE], for encrypting information in transit between Client and 758 Issuer across the Mediator. 760 * RSA Blind Signatures [BLINDSIG], for issuing and constructing 761 Tokens as described in Section 4.2. 763 * Prime Order Groups (POGs), for computing stable mappings between 764 (Client, Origin) pairs. This document uses notation described in 765 [VOPRF], Section 2.1, and, in particular, the functions 766 RandomScalar(), Generator(), SerializeScalar(), 767 SerializeElement(), and HashToScalar(). 769 * Non-Interactive proof-of-knowledge (POK), as described in 770 Section 5.8, for verifying correctness of Client requests. 772 Clients and Issuers are required to implement all of these 773 dependencies, whereas Mediators are required to implement POG and POK 774 support. 776 5.1. State Requirements 778 The Issuance protocol requires each participating endpoint to 779 maintain some necessary state, as described in this section. 781 5.1.1. Client State 783 A Client is required to have the following information, derived from 784 a given TokenChallenge: 786 * Origin name (ORIGIN_NAME), a URI referring to the Origin 787 [RFC6454]. This is the value of TokenChallenge.origin_name. 789 * Origin token public key (ORIGIN_TOKEN_KEY), a blind signature 790 public key corresponding to the Origin identified by 791 TokenChallenge.origin_name. 793 * Issuer public key (ISSUER_KEY), a public key used to encrypt 794 requests corresponding to the Issuer identified by 795 TokenChallenge.issuer_name. 797 Clients maintain a stable CLIENT_ID that they use for all 798 communication with a specific Mediator. CLIENT_ID is a public key, 799 where the corresponding private key CLIENT_SECRET is known only to 800 the client. 802 If the client loses this (CLIENT_ID, CLIENT_SECRET), they may 803 generate a new tuple. The mediator will enforce if a client is 804 allowed to use this new CLIENT_ID. See #mediator-state for details 805 on this enforcement. 807 Clients also need to be able to generate an ANON_ORIGIN_ID value that 808 corresponds to the ORIGIN_NAME, to send in requests to the Mediator. 810 ANON_ORIGIN_ID MUST be a stable and unpredictable 32-byte value 811 computed by the Client. Clients MUST NOT change this value across 812 token requests for the same ORIGIN_NAME. Doing so will result in 813 token issuance failure (specifically, when a Mediator rejects a 814 request upon detecting two ANON_ORIGIN_ID values that map to the same 815 Origin). 817 One possible mechanism for implementing this identifier is for the 818 Client to store a mapping between the ORIGIN_NAME and a randomly 819 generated ANON_ORIGIN_ID for future requests. Alternatively, the 820 Client can compute a PRF keyed by a per-client secret (CLIENT_SECRET) 821 over the ORIGIN_NAME, e.g., ANON_ORIGIN_ID = 822 HKDF(secret=CLIENT_SECRET, salt="", info=ORIGIN_NAME). 824 5.1.2. Mediator State 826 A Mediator is required to maintain state for every authenticated 827 Client. The mechanism of identifying a Client is specific to each 828 Mediator, and is not defined in this document. As examples, the 829 Mediator could use device-specific certificates or account 830 authentication to identify a Client. 832 Mediators must enforce that Clients don't change their CLIENT_ID 833 frequently, to ensure Clients can't regularily evade the per-client 834 policy as seen by the issuer. Mediators MUST NOT allow Clients to 835 change their CLIENT_ID more than once within a policy window, or in 836 the subsequent policy window after a previous CLIENT_ID change. 837 Alternative schemes where the mediator stores the encrypted 838 (CLIENT_ID, CLIENT_SECRET) tuple on behalf of the client are possble 839 but not described here. 841 Mediators are expected to know the ISSUER_POLICY_WINDOW for any 842 ISSUER_NAME to which they allow access. This information can be 843 retrieved using the URIs defined in Section 3. 845 For each Client-Issuer pair, a Mediator maintains a policy window 846 start and end time for each Issuer from which a Client requests a 847 token. 849 For each tuple of (CLIENT_ID, ANON_ORIGIN_ID, policy window), the 850 Mediator maintains the following state: 852 * A counter of successful tokens issued 854 * Whether or not a previous request was rejected by the Issuer 856 * The last received ANON_ISSUER_ORIGIN_ID value for this 857 ANON_ORIGIN_ID, if any 859 5.1.3. Issuer State 861 Issuers maintain a stable ORIGIN_SECRET that they use in calculating 862 values returned to the Mediator for each origin. If this value 863 changes, it will open up a possibility for Clients to request extra 864 tokens for an Origin without being limited, within a policy window. 866 Issuers are expected to have the private key that corresponds to 867 ISSUER_KEY, which allows them to decrypt the ORIGIN_NAME values in 868 requests. 870 Issuers also need to know the set of valid ORIGIN_TOKEN_KEY public 871 keys and corresponding private key, for each ORIGIN_NAME that is 872 served by the Issuer. Origins SHOULD update their view of the 873 ORIGIN_TOKEN_KEY regularly to ensure that Client requests do not fail 874 after ORIGIN_TOKEN_KEY rotation. 876 5.2. Issuance HTTP Headers 878 The Issuance protocol defines four new HTTP headers that are used in 879 requests and responses between Clients, Mediators, and Issuers (see 880 Section 10.2). 882 The "Sec-Token-Origin" is an Item Structured Header [RFC8941]. Its 883 value MUST be a Byte Sequence. This header is sent both on Client- 884 to-Mediator requests (Section 5.3) and on Issuer-to-Mediator 885 responses (Section 5.5). Its ABNF is: 887 Sec-Token-Origin = sf-binary 889 The "Sec-Token-Client" is an Item Structured Header [RFC8941]. Its 890 value MUST be a Byte Sequence. This header is sent on Client-to- 891 Mediator requests (Section 5.3), and contains the bytes of 892 CLIENT_KEY. Its ABNF is: 894 Sec-Token-Client = sf-binary 896 The "Sec-Token-Nonce" is an Item Structured Header [RFC8941]. Its 897 value MUST be a Byte Sequence. This header is sent on Client-to- 898 Mediator requests (Section 5.3), and contains a per-request nonce 899 value. Its ABNF is: 901 Sec-Token-Nonce = sf-binary 903 The "Sec-Token-Count" is an Item Structured Header [RFC8941]. Its 904 value MUST be an Integer. This header is sent on Mediator-to-Issuer 905 requests (Section 5.3), and contains the number of times a Client has 906 previously received a token for an Origin. Its ABNF is: 908 Sec-Token-Count = sf-integer 910 5.3. Client-to-Mediator Request 912 The Client and Mediator MUST use a secure and Mediator-authenticated 913 HTTPS connection. They MAY use mutual authentication or mechanisms 914 such as TLS certificate pinning, to mitigate the risk of channel 915 compromise; see Section 7 for additional about this channel. 917 Issuance begins by Clients hashing the TokenChallenge to produce a 918 token input as message = SHA256(challenge), and then blinding message 919 as follows: 921 blinded_req, blind_inv = rsabssa_blind(ORIGIN_TOKEN_KEY, message) 923 The Client MUST use a randomized variant of RSABSSA in producing this 924 signature with a salt length of at least 32 bytes. 926 The Client uses CLIENT_SECRET to generate proof of its request. 928 blind = RandomScalar() 929 blind_key = blind * CLIENT_SECRET 930 blind_generator = blind * Generator() 931 key_proof = SchnorrProof(CLIENT_SECRET, blind_key, blind_generator) 933 The Client then transforms this proof into "mapping_nonce", 934 "mapping_key", "mapping_generator", and "mapping_proof". 936 mapping_nonce = SerializeScalar(blind) 937 mapping_key = SerializeElement(blind_key) 938 mapping_generator = SerializeElement(blind_generator) 939 mapping_proof = SerializeProof(key_proof) 941 The Client then constructs a Private Access Token request using 942 mapping_key, mapping_generator, mapping_proof, blinded_req, and 943 origin information. 945 struct { 946 uint8_t version; 947 uint8_t mapping_generator[Ne]; 948 uint8_t mapping_key[Ne]; 949 uint8_t mapping_proof[Np]; 950 uint8_t token_key_id; 951 uint8_t blinded_req[Nk]; 952 uint8_t name_key_id[32]; 953 uint8_t encrypted_origin_name<1..2^16-1>; 954 } AccessTokenRequest; 956 The structure fields are defined as follows: 958 * "version" is a 1-octet integer, which matches the version in the 959 TokenChallenge. This document defines version 1. 961 * "mapping_generator", "mapping_key", and "mapping_proof" are 962 computed as described above. 964 * "token_key_id" is the least significant byte of the 965 ORIGIN_TOKEN_KEY key ID, which is generated as SHA256(public_key), 966 where public_key is a DER-encoded SubjectPublicKeyInfo object 967 carrying ORIGIN_TOKEN_KEY. 969 * "blinded_req" is the Nk-octet request defined above. 971 * "name_key_id" is a collision-resistant hash that identifies the 972 ISSUER_KEY public key, generated as SHA256(KeyConfig). 974 * "encrypted_origin_name" is an encrypted structure that contains 975 ORIGIN_NAME, calculated as described in Section 5.7. 977 The Client then generates an HTTP POST request to send through the 978 Mediator to the Issuer, with the AccessTokenRequest as the body. The 979 media type for this request is "message/access-token-request". The 980 Client includes the "Sec-Token-Origin" header, whose value is 981 ANON_ORIGIN_ID; the "Sec-Token-Client" header, whose value is 982 CLIENT_KEY; and the "Sec-Token-Nonce" header, whose value is 983 mapping_nonce. The Client sends this request to the Mediator's proxy 984 URI. An example request is shown below, where Nk = 512. 986 :method = POST 987 :scheme = https 988 :authority = issuer.net 989 :path = /access-token-request 990 accept = message/access-token-response 991 cache-control = no-cache, no-store 992 content-type = message/access-token-request 993 content-length = 512 994 sec-token-origin = ANON_ORIGIN_ID 995 sec-token-client = CLIENT_KEY 996 sec-token-nonce = mapping_nonce 998 1000 If the Mediator detects a version in the AccessTokenRequest that it 1001 does not recognize or support, it MUST reject the request with an 1002 HTTP 400 error. 1004 The Mediator also checks to validate that the name_key_id in the 1005 client's AccessTokenRequest matches a known ISSUER_KEY public key for 1006 the Issuer. For example, the Mediator can fetch this key using the 1007 API defined in Section 3. This check is done to help ensure that the 1008 Client has not been given a unique key that could allow the Issuer to 1009 fingerprint or target the Client. If the key does not match, the 1010 Mediator rejects the request with an HTTP 400 error. Note that 1011 Mediators need to be careful in cases of key rotation; see Section 8. 1013 The Mediator finally checks to ensure that the 1014 AccessTokenRequest.mapping_proof is valid for the given CLIENT_KEY; 1015 see Section 5.8 for verification details. If the index is invalid, 1016 the Mediator rejects the request with an HTTP 400 error. 1018 If the Mediator accepts the request, it will look up the state stored 1019 for this Client. It will look up the count of previously generate 1020 tokens for this Client using the same ANON_ORIGIN_ID. See 1021 Section 5.1.2 for more details. 1023 If the Mediator has stored state that a previous request for this 1024 ANON_ORIGIN_ID was rejected by the Issuer in the current policy 1025 window, it SHOULD reject the request without forwarding it to the 1026 Issuer. 1028 If the Mediator detects this Client has changed their CLIENT_ID more 1029 frequently than allowed as described in #mediator-state, it SHOULD 1030 reject the request without forwarding it to the Issuer. 1032 5.4. Mediator-to-Issuer Request 1034 The Mediator and the Issuer MUST use a secure and Issuer- 1035 authenticated HTTPS connection. Also, Issuers MUST authenticate 1036 Mediators, either via mutual TLS or another form of application-layer 1037 authentication. They MAY additionally use mechanisms such as TLS 1038 certificate pinning, to mitigate the risk of channel compromise; see 1039 Section 7 for additional about this channel. 1041 Before copying and forwarding the Client's AccessTokenRequest request 1042 to the Issuer, the Mediator adds a header that includes the count of 1043 previous tokens as "Sec-Token-Count". The Mediator MAY also add 1044 additional context information, but MUST NOT add information that 1045 will uniquely identify a Client. 1047 :method = POST 1048 :scheme = https 1049 :authority = issuer.net 1050 :path = /access-token-request 1051 accept = message/access-token-response 1052 cache-control = no-cache, no-store 1053 content-type = message/access-token-request 1054 content-length = 512 1055 sec-token-count = 3 1057 1059 Upon receipt of the forwarded request, the Issuer validates the 1060 following conditions: 1062 * The "Sec-Token-Count" header is present 1064 * The AccessTokenRequest contains a supported version 1066 * For version 1, the AccessTokenRequest.name_key_id corresponds to 1067 the ID of the ISSUER_KEY held by the Issuer 1069 * For version 1, the AccessTokenRequest.encrypted_origin_name can be 1070 decrypted using the Issuer's private key (the private key 1071 associated with ISSUER_KEY), and matches an ORIGIN_NAME that is 1072 served by the Issuer 1074 * For version 1, the AccessTokenRequest.blinded_req is of the 1075 correct size 1077 * For version 1, the AccessTokenRequest.token_key_id corresponds to 1078 an ID of an ORIGIN_TOKEN_KEY for the corresponding ORIGIN_NAME 1080 If any of these conditions is not met, the Issuer MUST return an HTTP 1081 400 error to the Mediator, which will forward the error to the 1082 client. 1084 If the request is valid, the Issuer then can use the value from "Sec- 1085 Token-Count" to determine if the Client is allowed to receive a token 1086 for this Origin during the current policy window. If the Issuer 1087 refuses to issue more tokens, it responds with an HTTP 429 (Too Many 1088 Requests) error to the Mediator, which will forward the error to the 1089 client. 1091 The Issuer determines the correct ORIGIN_TOKEN_KEY by using the 1092 decrypted ORIGIN_NAME value and AccessTokenRequest.token_key_id. If 1093 there is no ORIGIN_TOKEN_KEY whose truncated key ID matches 1094 AccessTokenRequest.token_key_id, the Issuer MUST return an HTTP 401 1095 error to Mediator, which will forward the error to the client. The 1096 Mediator learns that the client's view of the Origin key was invalid 1097 in the process. 1099 5.5. Issuer-to-Mediator Response 1101 If the Issuer is willing to give a token to the Client, the Issuer 1102 verifies the token request using "mapping_generator", "mapping_key", 1103 and "mapping_proof": 1105 valid = SchnorrVerify(mapping_generator, mapping_key, mapping_proof) 1107 If this fails, the Issuer rejects the request with a 400 error. 1108 Otherwise, the Issuer decrypts 1109 AccessTokenRequest.encrypted_origin_name to discover "origin". If 1110 this fails, the Issuer rejects the request with a 400 error. The 1111 Issuer then evaluates the mapping over the ORIGIN_SECRET pertaining 1112 to the origin for this issuer: 1114 mapping_input = DeserializeElement(AccessTokenRequest.mapping_key) 1115 index = ORIGIN_SECRET * mapping_input 1116 mapping_index = SerializeElement(index) 1118 If DeserializeElement fails, or if AccessTokenRequest.mapping_key is 1119 the identity element, the Issuer rejects the request with a 400 1120 error. 1122 The Issuer completes the issuance flow by computing a blinded 1123 response as follows: 1125 blind_sig = rsabssa_blind_sign(skP, AccessTokenRequest.blinded_req) 1126 skP is the private key corresponding to ORIGIN_TOKEN_KEY, known only 1127 to the Issuer. 1129 The Issuer generates an HTTP response with status code 200 whose body 1130 consists of blind_sig, with the content type set as "message/access- 1131 token-response" and the mapping_tag set in the "Sec-Token-Origin" 1132 header. 1134 :status = 200 1135 content-type = message/access-token-response 1136 content-length = 512 1137 sec-token-origin = mapping_index 1139 1141 5.6. Mediator-to-Client Response 1143 Upon receipt of a successful response from the Issuer, the Mediator 1144 extracts the "Sec-Token-Origin" header, and uses the value to 1145 determine ANON_ISSUER_ORIGIN_ID. 1147 index = DeserializeElement(mapping_index) 1148 nonce = DeserializeScalar(mapping_nonce) 1149 ANON_ISSUER_ORIGIN_ID = (nonce^(-1)) * index 1151 If the "Sec-Token-Origin" is missing, or if the same 1152 ANON_ISSUER_ORIGIN_ID was previously received in a response for a 1153 different ANON_ORIGIN_ID within the same policy window, the Mediator 1154 MUST drop the token and respond to the client with an HTTP 400 1155 status. If there is not an error, the ANON_ISSUER_ORIGIN_ID is 1156 stored alongside the state for the ANON_ORIGIN_ID. 1158 For all other cases, the Mediator forwards all HTTP responses 1159 unmodified to the Client as the response to the original request for 1160 this issuance. 1162 When the Mediator detects successful token issuance, it MUST 1163 increment the counter in its state for the number of tokens issued to 1164 the Client for the ANON_ORIGIN_ID. 1166 Upon receipt, the Client handles the response and, if successful, 1167 processes the body as follows: 1169 sig = rsabssa_finalize(ORIGIN_TOKEN_KEY, nonce, blind_sig, blind_inv) 1171 If this succeeds, the Client then constructs a Private Access Token 1172 as described in Section 4.1 using the token input message and output 1173 sig. 1175 5.7. Encrypting Origin Names 1177 Given a KeyConfig (ISSUER_KEY), Clients produce encrypted_origin_name 1178 and authenticate all other contents of the AccessTokenRequest using 1179 the following values: 1181 * the key identifier from the configuration, keyID, with the 1182 corresponding KEM identified by kemID, the public key from the 1183 configuration, pkI, and; 1185 * a selected combination of KDF, identified by kdfID, and AEAD, 1186 identified by aeadID. 1188 Beyond the key configuration inputs, Clients also require the 1189 AccessTokenRequest inputs. Together, these are used to encapsulate 1190 ORIGIN_NAME (origin_name) and produce ENCRYPTED_ORIGIN_NAME 1191 (encrypted_origin) as follows: 1193 1. Compute an [HPKE] context using pkI, yielding context and 1194 encapsulation key enc. 1196 2. Construct associated data, aad, by concatenating the values of 1197 keyID, kemID, kdfID, aeadID, and all other values of the 1198 AccessTokenRequest structure. 1200 3. Encrypt (seal) request with aad as associated data using context, 1201 yielding ciphertext ct. 1203 4. Concatenate the values of aad, enc, and ct, yielding an 1204 Encapsulated Request enc_request. 1206 Note that enc is of fixed-length, so there is no ambiguity in parsing 1207 this structure. 1209 In pseudocode, this procedure is as follows: 1211 enc, context = SetupBaseS(pkI, "AccessTokenRequest") 1212 aad = concat(encode(1, keyID), 1213 encode(2, kemID), 1214 encode(2, kdfID), 1215 encode(2, aeadID), 1216 encode(1, version), 1217 encode(Ne, mapping_generator), 1218 encode(Ne, mapping_key), 1219 encode(Np, mapping_proof), 1220 encode(1, token_key_id), 1221 encode(Nk, blinded_req), 1222 encode(32, name_key_id)) 1223 ct = context.Seal(aad, origin_name) 1224 encrypted_origin_name = concat(enc, ct) 1226 Issuers reverse this procedure to recover ORIGIN_NAME by computing 1227 the AAD as described above and decrypting encrypted_origin_name with 1228 their private key skI, the private key corresponding to pkI. In 1229 pseudocode, this procedure is as follows: 1231 enc, ct = parse(encrypted_origin_name) 1232 aad = concat(encode(1, keyID), 1233 encode(2, kemID), 1234 encode(2, kdfID), 1235 encode(2, aeadID), 1236 encode(1, version), 1237 encode(Ne, mapping_generator), 1238 encode(Ne, mapping_key), 1239 encode(Np, mapping_proof), 1240 encode(1, token_key_id), 1241 encode(Nk, blinded_req), 1242 encode(32, name_key_id)) 1243 enc, context = SetupBaseR(enc, skI, "AccessTokenRequest") 1244 origin_name, error = context.Open(aad, ct) 1246 5.8. Non-Interactive Schnorr Proof of Knowledge 1248 Each Issuance request requires evaluation and verification of a 1249 Schnorr proof-of-knowledge. Given input secret "secret" and two 1250 elements, "base" and "target", generation of this proof (u, c, z), 1251 denoted SchnorrProof(secret, base, target), works as follows: 1253 r = RandomScalar() 1254 u = r * base 1255 c = HashToScalar(SerializeElement(base) || 1256 SerializeElement(target) || 1257 SerializeElement(mask), 1258 dst = "PrivateAccessTokensProof") 1259 z = r + (c * secret) 1261 The proof is encoded by serializing (u, c, z) as follows: 1263 struct { 1264 uint8_t u[Ne]; 1265 uint8_t c[Ns]; 1266 uint8_t z[Ns]; 1267 } Proof; 1269 The size of this structure is Np = Ne + 2*Ns bytes. 1271 Verification of a proof (u, c, z), denoted SchnorrVerify(base, 1272 target, proof), works as follows: 1274 c = HashToScalar(SerializeElement(base) || 1275 SerializeElement(target) || 1276 SerializeElement(mask), 1277 dst = "PrivateAccessTokensProof") 1278 expected_left = base * z 1279 expected_right = u + (target * c) 1281 The proof is considered valid if expected_left is the same as 1282 expected_right. 1284 6. Instantiating Uses Cases 1286 This section describes various instantiations of this protocol to 1287 address use cases described in Section 1.1. 1289 6.1. Rate-limited Access 1291 To instantiate this case, the site acts as an Origin and registers a 1292 "bounded token" policy with the Issuer. In this policy, the Issuer 1293 enforces a fixed number of tokens that it will allow a Client to 1294 request for a single ORIGIN_NAME. 1296 Origins request tokens from Clients and, upon successful redemption, 1297 the Origin knows the Client was able to request a token for the given 1298 ORIGIN_NAME within its budget. Failure to present a token can be 1299 interpreted as a signal that the client's token budget was exceeded. 1301 Clients can redeem a token from a specific challenge up to the max- 1302 age in the challenge. Servers can choose to issue many challenges in 1303 a single HTTP 401 response, providing the client with many challenge 1304 nonces which can be used to redeem tokens over a longer period of 1305 time. 1307 6.2. Client Geo-Location 1309 To instantiate this use case, the Issuer has an issuing key pair per 1310 geographic region, i.e., each region has a unique policy key. When 1311 verifying the key for the Client request, the Mediator obtains the 1312 per-region key from the Issuer based on the Client's perceived 1313 location. During issuance, the Mediator checks that this key matches 1314 that of the Client's request. If it matches, the Mediator forwards 1315 the request to complete issuance. The number of key pairs is then 1316 the cross product of the number of Origins that require per-region 1317 keys and the number of regions. 1319 During redemption, Clients present their geographic location to 1320 Origins in a "Sec-CH-Geohash" header. Origins use this to obtain the 1321 appropriate policy verification key. Origins request tokens from 1322 Clients and, upon successful redemption, the Origin knows the Client 1323 obtained a token for the given ORIGIN_NAME in the specified region. 1325 6.3. Private Client Authentication 1327 To instantiate this case, the site acts as an Origin and registers an 1328 "unlimited token" policy with the Issuer. In this policy, the Issuer 1329 does not enforce any limit on the number of tokens a given user will 1330 obtain. 1332 Origins request tokens from Clients and, upon successful redemption, 1333 the Origin knows the Client was able to request a token for the given 1334 ORIGIN_NAME tuple. As a result, the Origin knows this is an 1335 authentic client. 1337 7. Security Considerations 1339 This section discusses security considerations for the protocol. 1341 [OPEN ISSUE: discuss trust model] 1343 7.1. Client Identity 1345 The HTTPS connection between Client and Mediator is minimally 1346 Mediator-authenticated. Mediators can also require Client 1347 authentication if they wish to restrict Private Access Token proxying 1348 to trusted or otherwise authenticated Clients. Absent some form of 1349 Client authentication, Mediators can use other per-Client information 1350 for the client identifier mapping, such as IP addresses. 1352 7.2. Denial of Service 1354 Requesting and verifying a Private Access Token is more expensive 1355 than checking an implicit signal, such as an IP address, especially 1356 since malicious clients can generate garbage Private Access Tokens 1357 and for Origins to work. However, similar DoS vectors already exist 1358 for Origins, e.g., at the underlying TLS layer. 1360 7.3. Channel Security 1362 An attacker that can act as an intermediate between Mediator and 1363 Issuer communication can influence or disrupt the ability for the 1364 Issuer to correctly rate-limit token issuance. All communication 1365 channels use server-authenticated HTTPS. Some connections, e.g., 1366 between a Mediator and an Issuer, require mutual authentication 1367 between both endpoints. Where appropriate, endpoints MAY use further 1368 enhancements such as TLS certificate pinning to mitigate the risk of 1369 channel compromise. 1371 An attacker that can intermediate the channel between Client and 1372 Origin can observe a TokenChallenge, and can view a Token being 1373 presented for authentication to an Origin. Scoping the 1374 TokenChallenge nonce to the Client HTTP session prevents Tokens being 1375 collected in one session and then presented to the Origin in another. 1376 Note that an Origin cannot distinguish between a connection to a 1377 single Client and a connection to an attacker intermediating multiple 1378 Clients. Thus, it is possible for an attacker to collect and later 1379 present Tokens from multiple clients over the same Origin session. 1381 8. Privacy Considerations 1383 8.1. Client Token State and Origin Tracking 1385 Origins SHOULD only generate token challenges based on client action, 1386 such as when a user loads a website. Clients SHOULD ignore token 1387 challenges if an Origin tries to force the client to present tokens 1388 multiple times without any new client-initiated action. Failure to 1389 do so can allow malicious origins to track clients across contexts. 1390 Specifically, an origin can abuse per-user token limits for tracking 1391 by assigning each new client a random token count and observing 1392 whether or not the client can successfully redeem that many tokens in 1393 a given context. If any token redemption fails, then the origin 1394 learns information about how many tokens that client had previously 1395 been issued. 1397 By rejecting repeated or duplicative challenges within a single 1398 context, the origin only learns a single bit of information: whether 1399 or not the client had any token quota left in the given policy 1400 window. 1402 8.2. Origin Verification 1404 Private Access Tokens are defined in terms of a Client authenticating 1405 to an Origin, where the "origin" is used as defined in [RFC6454]. In 1406 order to limit cross-origin correlation, Clients MUST verify that the 1407 origin_name presented in the TokenChallenge structure (Section 4.1) 1408 matches the origin that is providing the HTTP authentication 1409 challenge, where the matching logic is defined for same-origin 1410 policies in [RFC6454]. Clients MAY further limit which 1411 authentication challenges they are willing to respond to, for example 1412 by only accepting challenges when the origin is a web site to which 1413 the user navigated. 1415 8.3. Client Identification with Unique Keys 1417 Client activity could be linked if an Origin and Issuer collude to 1418 have unique keys targeted at specific Clients or sets of Clients. 1420 To mitigate the risk of a targeted ISSUER_KEY, the Mediator can 1421 observe and validate the name_key_id presented by the Client to the 1422 Issuer. As described in Section 5, Mediators MUST validate that the 1423 name_key_id in the Client's AccessTokenRequest matches a known public 1424 key for the Issuer. The Mediator needs to support key rotation, but 1425 ought to disallow very rapid key changes, which could indicate that 1426 an Origin is colluding with an Issuer to try to rotate the key for 1427 each new Client in order to link the client activity. 1429 To mitigate the risk of a targeted ORIGIN_TOKEN_KEY, the protocol 1430 expects that an Issuer has only a single valid public key for signing 1431 tokens at a time. The Client does not present the name_key_id of the 1432 token public key to the Issuer, but instead expects the Issuer to 1433 infer the correct key based on the information the Issuer knows, 1434 specifically the origin_name itself. 1436 8.4. Collusion Among Different Entities 1438 Collusion among the different entities in the PAT architecture can 1439 result in violation of the Client's privacy. 1441 Issuers and Mediators should be run by mutually distinct 1442 organizations to limit information sharing. A single entity running 1443 an issuer and mediator for a single redemption can view the origins 1444 being accessed by a given client. Running the issuer and mediator in 1445 this 'single issuer/mediator' fashion reduces the privacy promises to 1446 those of the [I-D.ietf-privacypass-protocol]; see Appendix A for more 1447 discussion. This may be desirable for a redemption flow that is 1448 limited to specific issuers and mediators, but should be avoided 1449 where hiding origins from the mediator is desirable. 1451 If a Mediator and Origin are able to collude, they can correlate a 1452 client's identity and origin access patterns through timestamp 1453 correlation. The timing of a request to an Origin and subsequent 1454 token issuance to a Mediator can reveal the Client identity (as known 1455 to the Mediator) to the Origin, especially if repeated over multiple 1456 accesses. 1458 9. Deployment Considerations 1460 9.1. Origin Key Rollout 1462 Issuers SHOULD generate a new (ORIGIN_TOKEN_KEY, ORIGIN_SECRET) 1463 regularly, and SHOULD maintain old and new secrets to allow for 1464 graceful updates. The RECOMMENDED rotation interval is two times the 1465 length of the policy window for that information. During generation, 1466 issuers must ensure the token_key_id (the 8-bit prefix of 1467 SHA256(ORIGIN_TOKEN_KEY)) is different from all other token_key_id 1468 values for that origin currently in rotation. One way to ensure this 1469 uniqueness is via rejection sampling, where a new key is generated 1470 until its token_key_id is unique among all currently in rotation for 1471 the origin. 1473 10. IANA Considerations 1475 10.1. Authentication Scheme 1477 This document registers the "PrivateAccessToken" authentication 1478 scheme in the "Hypertext Transfer Protocol (HTTP) Authentication 1479 Scheme Registry" established by [RFC7235]. 1481 Authentication Scheme Name: PrivateAccessToken 1483 Pointer to specification text: Section 4.1 of this document 1485 10.2. HTTP Headers 1487 This document registers four new headers for use on the token 1488 issuance path in the "Permanent Message Header Field Names" 1489 . 1491 +-------------------+----------+--------+---------------+ 1492 | Header Field Name | Protocol | Status | Reference | 1493 +-------------------+----------+--------+---------------+ 1494 | Sec-Token-Origin | http | std | This document | 1495 +-------------------+----------+--------+---------------+ 1496 | Sec-Token-Client | http | std | This document | 1497 +-------------------+----------+--------+---------------+ 1498 | Sec-Token-Nonce | http | std | This document | 1499 +-------------------+----------+--------+---------------+ 1500 | Sec-Token-Count | http | std | This document | 1501 +-------------------+----------+--------+---------------+ 1503 Figure 2: Registered HTTP Header 1505 10.3. Media Types 1507 This specification defines the following protocol messages, along 1508 with their corresponding media types: 1510 * AccessTokenRequest Section 5: "message/access-token-request" 1512 * AccessTokenResponse Section 5: "message/access-token-response" 1514 The definition for each media type is in the following subsections. 1516 10.3.1. "message/access-token-request" media type 1518 Type name: message 1520 Subtype name: access-token-request 1522 Required parameters: N/A 1524 Optional parameters: None 1526 Encoding considerations: only "8bit" or "binary" is permitted 1528 Security considerations: see Section 5 1530 Interoperability considerations: N/A 1532 Published specification: this specification 1533 Applications that use this media type: N/A 1535 Fragment identifier considerations: N/A 1537 Additional information: Magic number(s): N/A 1539 Deprecated alias names for this type: N/A 1541 File extension(s): N/A 1543 Macintosh file type code(s): N/A 1545 Person and email address to contact for further information: see Aut 1546 hors' Addresses section 1548 Intended usage: COMMON 1550 Restrictions on usage: N/A 1552 Author: see Authors' Addresses section 1554 Change controller: IESG 1556 10.3.2. "message/access-token-response" media type 1558 Type name: message 1560 Subtype name: access-token-response 1562 Required parameters: N/A 1564 Optional parameters: None 1566 Encoding considerations: only "8bit" or "binary" is permitted 1568 Security considerations: see Section 5 1570 Interoperability considerations: N/A 1572 Published specification: this specification 1574 Applications that use this media type: N/A 1576 Fragment identifier considerations: N/A 1578 Additional information: Magic number(s): N/A 1580 Deprecated alias names for this type: N/A 1581 File extension(s): N/A 1583 Macintosh file type code(s): N/A 1585 Person and email address to contact for further information: see Aut 1586 hors' Addresses section 1588 Intended usage: COMMON 1590 Restrictions on usage: N/A 1592 Author: see Authors' Addresses section 1594 Change controller: IESG 1596 11. References 1598 11.1. Normative References 1600 [BLINDSIG] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind 1601 Signatures", Work in Progress, Internet-Draft, draft-irtf- 1602 cfrg-rsa-blind-signatures-02, 2 August 2021, 1603 . 1606 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 1607 "Hybrid Public Key Encryption", Work in Progress, 1608 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 1609 . 1612 [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 1613 Progress, Internet-Draft, draft-thomson-http-oblivious-02, 1614 24 August 2021, . 1617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1618 Requirement Levels", BCP 14, RFC 2119, 1619 DOI 10.17487/RFC2119, March 1997, 1620 . 1622 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1623 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1624 . 1626 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1627 DOI 10.17487/RFC6454, December 2011, 1628 . 1630 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1631 Protocol (HTTP/1.1): Authentication", RFC 7235, 1632 DOI 10.17487/RFC7235, June 2014, 1633 . 1635 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1636 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1637 May 2017, . 1639 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 1640 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 1641 . 1643 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1644 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1645 . 1647 [VOPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. 1648 Wood, "Oblivious Pseudorandom Functions (OPRFs) using 1649 Prime-Order Groups", Work in Progress, Internet-Draft, 1650 draft-irtf-cfrg-voprf-08, 25 October 2021, 1651 . 1654 11.2. Informative References 1656 [I-D.ietf-privacypass-protocol] 1657 Celi, S., Davidson, A., and A. Faz-Hernandez, "Privacy 1658 Pass Protocol Specification", Work in Progress, Internet- 1659 Draft, draft-ietf-privacypass-protocol-01, 22 February 1660 2021, . 1663 Appendix A. Related Work: Privacy Pass 1665 Private Access Tokens has many similarities to the existing Privacy 1666 Pass protocol ([I-D.ietf-privacypass-protocol]). Both protocols 1667 allow clients to redeem signed tokens while not allowing linking 1668 between token issuance and token redemption. 1670 There are several important differences between the protocols, 1671 however: 1673 * Private Access Tokens uses per-origin tokens that support rate- 1674 limiting policies. Each token can only be used with a specific 1675 origin in accordance with a policy defined for that origin. This 1676 allows origins to implement metered paywalls or mechanisms that 1677 that limit the actions a single client can perform. Per-origin 1678 tokens also ensure that one origin cannot consume all of a 1679 client's tokens, so there is less need for clients to manage when 1680 they are willing to present tokens to origins. 1682 * Private Access Tokens employ an online challenge (Section 4.1) 1683 during token redemption. This ensures that tokens cannot be 1684 harvested and stored for use later. This also removes the need 1685 for preventing double spending or employing token expiry 1686 techniques, such as frequent signer rotation or expiry-encoded 1687 public metadata. 1689 * Private Access Tokens use a publically verifiable signature 1690 [BLINDSIG] to optimize token verification at the origin by 1691 avoiding a round trip to the issuer/mediator. 1693 Authors' Addresses 1695 Scott Hendrickson 1696 Google LLC 1698 Email: scott@shendrickson.com 1700 Jana Iyengar 1701 Fastly 1703 Email: jri@fastly.com 1705 Tommy Pauly 1706 Apple Inc. 1707 One Apple Park Way 1708 Cupertino, California 95014, 1709 United States of America 1711 Email: tpauly@apple.com 1713 Steven Valdez 1714 Google LLC 1716 Email: svaldez@chromium.org 1718 Christopher A. Wood 1719 Cloudflare 1721 Email: caw@heapingbits.net