From a8f0053263363ba306008c1f3e93035025edfd7c Mon Sep 17 00:00:00 2001 From: chriswood Date: Thu, 3 Aug 2023 18:06:53 -0400 Subject: [PATCH 1/4] Origin guidance --- draft-ietf-privacypass-auth-scheme.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/draft-ietf-privacypass-auth-scheme.md b/draft-ietf-privacypass-auth-scheme.md index 68a26b0b..d0b50974 100644 --- a/draft-ietf-privacypass-auth-scheme.md +++ b/draft-ietf-privacypass-auth-scheme.md @@ -125,13 +125,8 @@ same client. In deployment scenarios where origins send token challenges to request tokens, origins ought to expect at most one request containing a token from the client in reaction to a particular challenge. -Origins SHOULD minimize the number of challenges sent on a particular client -session, such as a unique TLS session between a client and origin -(referred to as the "redemption context" in {{ARCHITECTURE}}). Clients can -have implementation-specific policy to minimize the number of tokens that -can be retrieved by origins, so origins are advised to only request tokens -when necessary within a single session. See {{interaction}} for more discussion -on how to optimize token challenges to improve the user experience. +The rest of this section describes the token challenge and redemption interactions +in more detail. ## Token Challenge {#challenge} @@ -221,7 +216,9 @@ challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. This parameter is required for all challenges. - "token-key", which contains a base64url encoding of the public key for -use with the issuance protocol indicated by the challenge. The encoding of +use with the issuance protocol indicated by the challenge. See {{ISSUANCE}} +for more information about how this public key is used by the issuance protocols +in that specification. The encoding of the public key is determined by the token type; see {{token-types}}. As with "challenge", the base64url value MUST include padding. As an Authentication Parameter (`auth-param` from {{!RFC9110, Section 11.2}}), the @@ -425,6 +422,14 @@ When used in contexts like websites, origins that challenge clients for tokens need to consider how to optimize their interaction model to ensure a good user experience. +Origins SHOULD minimize the number of challenges sent on a particular client +session, such as a unique TLS session between a client and origin +(referred to as the "redemption context" in {{ARCHITECTURE}}). Similarly, clients +SHOULD have some implementation-specific policy to minimize the number of tokens +that can be retrieved by origins. One possible implementation of this policy is +to bound the number of token challenges a given origin can provide for a given +session. + Tokens challenges can be performed without explicit user involvement, depending on the issuance protocol. If tokens are scoped to a specific origin, there is no need for per-challenge user interaction. Note that the issuance @@ -470,7 +475,7 @@ either do not support tokens or are unable to fetch tokens at a particular time can present the user with the puzzle. To mitigate the risk of deployments becoming dependent on tokens, clients and -servers SHOULD grease their behavior unless explicitly configured not to. In +origins SHOULD grease their behavior unless explicitly configured not to. In particular, clients SHOULD ignore token challenges with some non-zero probability. Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non-zero probability. Moreover, origins SHOULD include From e133f8d38c42cda8d4d2545c3f6be783d4eefa6d Mon Sep 17 00:00:00 2001 From: chriswood Date: Thu, 3 Aug 2023 18:22:10 -0400 Subject: [PATCH 2/4] Update origin guidance around blocking behavior --- draft-ietf-privacypass-auth-scheme.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/draft-ietf-privacypass-auth-scheme.md b/draft-ietf-privacypass-auth-scheme.md index d0b50974..254dc32c 100644 --- a/draft-ietf-privacypass-auth-scheme.md +++ b/draft-ietf-privacypass-auth-scheme.md @@ -436,14 +436,15 @@ there is no need for per-challenge user interaction. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated. -If a client cannot use cached tokens to respond to a challenge (either because -it has run out of cached tokens or the associated context is unique), the token +If a client cannot use cached tokens to respond to a challenge, either because +it has run out of cached tokens or the associated context is unique, the token issuance process can add user-perceivable latency. Origins need not block -useful work on token authentication. Instead, token authentication can be used -in similar ways to CAPTCHA validation today, but without the need for user -interaction. If issuance is taking a long time, a website could show an -indicator that it is waiting, or fall back to another method of user -validation. +useful work such as loading the contents of a web page on token authentication. +Instead, token authentication can be used in similar ways to CAPTCHA validation +today, wherein validation sometimes proceeds alongside useful work, e.g., when +loading contents of a web page, but without the need for user interaction. +If issuance is taking a long time, an origin could fall back to another method +of user validation. An origin MUST NOT use more than one redemption context value for a given token type and issuer per client request. If an origin issues a large number of From be3ec9082373f35a59a4005b5da083a754244370 Mon Sep 17 00:00:00 2001 From: chriswood Date: Thu, 3 Aug 2023 18:28:02 -0400 Subject: [PATCH 3/4] Clarify fallback consequences, and make grease behavior for clients --- draft-ietf-privacypass-auth-scheme.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/draft-ietf-privacypass-auth-scheme.md b/draft-ietf-privacypass-auth-scheme.md index 254dc32c..52a2429a 100644 --- a/draft-ietf-privacypass-auth-scheme.md +++ b/draft-ietf-privacypass-auth-scheme.md @@ -462,8 +462,10 @@ An origin MUST NOT assume that token challenges will always yield a valid token. Clients might experience issues running the issuance protocol, e.g., because the attester or issuer is unavailable, or clients might simply not support the requested token type. Origins SHOULD account for such operational -or interoperability failures by offering clients an alternative type of -challenge such as CAPTCHA for accessing a resource. +or interoperability failures by offering clients a fallback challenge such +as CAPTCHA for accessing a resource. Failure to provide a fallback will likely +mean that some clients fail authentication and cannot perform the desired +action, such as loading a web page or accessing some other resource. For example, consider a scenario in which the client is a web browser, and the origin can accept either a token or a solution to a puzzle intended to @@ -478,10 +480,13 @@ time can present the user with the puzzle. To mitigate the risk of deployments becoming dependent on tokens, clients and origins SHOULD grease their behavior unless explicitly configured not to. In particular, clients SHOULD ignore token challenges with some non-zero -probability. Likewise, origins SHOULD randomly choose to not challenge clients -for tokens with some non-zero probability. Moreover, origins SHOULD include -random token types, from the Reserved list of "greased" types (defined in -{{token-types}}), with some non-zero probability. +probability. From the origin's perspective, ignoring a token challenge is +indistinguishable from the issuance protocol failing for arbitrary reasons +(excluding what can be inferred from latency between the client and origin interaction). +Likewise, origins SHOULD randomly choose to not challenge clients for tokens +with some non-zero probability. Moreover, origins SHOULD include random token +types, from the Reserved list of "greased" types (defined in {{token-types}}), +with some non-zero probability. # Security Considerations {#sec-considerations} From 823c433fe0839c3fc64e1a0992f4f64e07a2d92e Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Wed, 9 Aug 2023 05:31:49 -0400 Subject: [PATCH 4/4] Update draft-ietf-privacypass-auth-scheme.md Co-authored-by: Tommy Pauly --- draft-ietf-privacypass-auth-scheme.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-privacypass-auth-scheme.md b/draft-ietf-privacypass-auth-scheme.md index 52a2429a..eb348906 100644 --- a/draft-ietf-privacypass-auth-scheme.md +++ b/draft-ietf-privacypass-auth-scheme.md @@ -440,10 +440,10 @@ If a client cannot use cached tokens to respond to a challenge, either because it has run out of cached tokens or the associated context is unique, the token issuance process can add user-perceivable latency. Origins need not block useful work such as loading the contents of a web page on token authentication. -Instead, token authentication can be used in similar ways to CAPTCHA validation -today, wherein validation sometimes proceeds alongside useful work, e.g., when -loading contents of a web page, but without the need for user interaction. -If issuance is taking a long time, an origin could fall back to another method +Instead, token authentication can be used in similar ways to existing CAPTCHA +validation flows, wherein validation sometimes proceeds alongside useful work, +e.g., when loading contents of a web page, but without the need for user interaction. +If issuance is taking a long time, an origin can fall back to another method of user validation. An origin MUST NOT use more than one redemption context value for a given token