From b04b41442b2c06488aecce5ffb34c5d5af2044a7 Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Fri, 17 Jan 2020 16:31:00 +0100 Subject: [PATCH] Rewrite proximity section shorter and discuss benefits of physical proximity --- images/authenticator-proximity-1.svg | 972 --------------------------- images/authenticator-proximity-2.svg | 960 -------------------------- index.bs | 81 +-- 3 files changed, 28 insertions(+), 1985 deletions(-) delete mode 100644 images/authenticator-proximity-1.svg delete mode 100644 images/authenticator-proximity-2.svg diff --git a/images/authenticator-proximity-1.svg b/images/authenticator-proximity-1.svg deleted file mode 100644 index 228dae332..000000000 --- a/images/authenticator-proximity-1.svg +++ /dev/null @@ -1,972 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Produced by OmniGraffle 7.7.1 - 2018-06-26 16:26:03 +0000 - - - image/svg+xml - - - - - - - Layer 1 - - - - Relying Party - - - Server - - - - - - Authenticator - - - - - - - - - Browser - - - - - - RP JavaScript - - - Application - - - - - - - - - Malicious - - - Application - - - - - Malicious - - - Server - - - - - - - - - - - - - - 1 - - - - - - - 2 - - - - - - - 3 - - - - diff --git a/images/authenticator-proximity-2.svg b/images/authenticator-proximity-2.svg deleted file mode 100644 index 619e4288f..000000000 --- a/images/authenticator-proximity-2.svg +++ /dev/null @@ -1,960 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Produced by OmniGraffle 7.7.1 - 2018-06-26 16:26:03 +0000 - - - image/svg+xml - - - - - - - Layer 1 - - - - Relying Party Server - - - - - - Authenticator - - - - - - - - - Browser - - - - - - RP JavaScript Application - - - - - - Authenticator - - - Service Server - - - - - - - - - - Malicious user - - - - - - - - - - - 4 - - - - - - - 1 - - - - - - - 2 - - - - - - - 3 - - - - diff --git a/index.bs b/index.bs index 4b150c414..3c69572e9 100644 --- a/index.bs +++ b/index.bs @@ -5855,59 +5855,34 @@ the wrong [=credential ID=], or if an attacker intercepts and manipulates the [= (a.k.a., [=assertion=]), and thus the interaction would end in an error. -## Enforcement of credential [=scope=] restrictions ## {#sctn-client-authenticator-proximity} - -In the WebAuthn [=authenticator model=], it is generally assumed that the [=client=] communicates -directly with the [=authenticator=]. -This has the benefit that the [=client=] can enforce the [=scope=] restrictions for [=credentials=], -as illustrated in Figure . -If implementing a solution where the above assumption does not hold, -implementers SHOULD consider how this affects the [=client=]'s ability to enforce [=scope=] restrictions. - -
- -
Direct communication between [=client=] and [=authenticator=] - enables enforcement of [=credential=] [=scope=] restrictions.
-
- -In Figure , -the [=client=] and [=authenticator=] communicate directly. -If the user visits a malicious site (1), then the [=client=] can refuse to initiate an [=authentication ceremony=] -if the site's [=origin=] does not match the claimed [=RP ID=]. -On the other hand, if the malicious application uses an [=RP ID=] valid for its [=origin=], -then the [=authentication assertion=] (2) will be signed over that [=origin=] instead of the [=[RP]=]'s [=origin=], -and the [=[RP]=] can reject the mismatched [=origin=] when the malicious actor attempts -to use the [=authentication assertion=] to [=authentication|authenticate=] to the [=[RP]=] (3). - -If the [=client=] does not communicate with the [=authenticator=] directly, -then enforcing the [=scope=] restrictions might be more challenging. - -
- -
Indirect communication between [=client=] and [=authenticator=] - might allow malicious actors to bypass [=scope=] restrictions.
-
- -In Figure , - the [=client=] communicates with the [=authenticator=] indirectly via some external authenticator service (1, 2). -For example, the [=client=] might send an HTTP request to a remote server (1) -which then sends a push notification (2) to the user's mobile device, -which prompts for [=user consent=] and acts as the [=authenticator=]. -If the initial request (1) is not authenticated, -it might be possible for a malicious actor to trigger (3) the [=authenticator=] prompt (2), -receive the [=authentication assertion=] and use it to authenticate to the [=[RP]=] (4). - -In order to enforce the [=scope=] restrictions in this example, -the [=client=] would need to authenticate itself to the authenticator service (1) -before the authenticator service allows access to the user's [=authenticator=] (2). -This would ensure that the communication with the [=authenticator=] -is mediated by the user's [=client=] so that the [=client=] can enforce the [=credential=] [=scope=] restrictions. - -Designers of similar protocols SHOULD ensure that the [=client=] can still enforce [=credential=] [=scope=] restrictions -despite not communicating with the [=authenticator=] directly, -or they SHOULD use some initial channel, that is not vulnerable to [=man-in-the-middle attacks=], -to establish the means to create subsequent secure channels between the [=client=] and [=authenticator=]. -For example, by exchanging pre-shared keys over a direct physical USB connection or similar. +## Physical Proximity between Client and Authenticator ## {#sctn-client-authenticator-proximity} + +In the WebAuthn [=authenticator model=], it is generally assumed that [=roaming authenticators=] +are physically close to and communicate directly with the [=client=]. +This arrangement has some important advantages. + +The promise of physical proximity between [=client=] and [=authenticator=] +is a key strength of a [=something you have=] [=authentication factor=]. +For example, if a [=roaming authenticator=] can communicate only via USB or Bluetooth, +the limited range of these transports ensures that any malicious actor +must physically be within that range in order to interact with the [=authenticator=]. +This is not necessarily true of an [=authenticator=] that can be invoked remotely — +even if the [=authenticator=] verifies [=user present|user presence=], +users can be tricked into authorizing remotely initiated malicious requests. + +Direct communication between [=client=] and [=authenticator=] +means the [=client=] can enforce the [=scope=] restrictions for [=credentials=]. +By contrast, if the communication between [=client=] and [=authenticator=] is mediated by some third party, +then the [=client=] has to trust the third party to +enforce the [=scope=] restrictions and control access to the [=authenticator=]. +Failure to do either could result in +a malicious [=[RP]=] receiving [=authentication assertions=] valid for other [=[RPS]=], +or in a malicious user gaining access to [=authentication assertions=] for other users. + +If designing a solution where the [=authenticator=] does not need to be physically close to the [=client=], +or where [=client=] and [=authenticator=] do not communicate directly, +designers SHOULD consider how this affects the enforcement of [=scope=] restrictions +and the strength of the [=authenticator=] as a [=something you have=] authentication factor. ## Security considerations for [=authenticators=] ## {#sctn-security-considerations-authenticator}