Merge pull request #829 from emlun/issue-576-rp-no-attestation

Add RP conformance section on ignoring attestation

index.bs

@@ -147,6 +147,11 @@ spec: FIDO-Registry; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-ps-2017
     type: dfn
         text: Section 3.6.2; url: public-key-representation-formats
 
+spec: RFC4949; urlPrefix: https://tools.ietf.org/html/rfc4949
+    type: dfn
+        text: leap of faith; url: page-182
+        text: man-in-the-middle attack; url: page-186
+
 
 </pre> <!-- class=anchors -->
 
@@ -290,7 +295,9 @@ external hardware, or a combination of both.
 
 ## [RPS] ## {#conforming-relying-parties}
 
-A [=[RP]=] MUST behave as described in [[#rp-operations]] to obtain the security benefits offered by this specification.
+A [=[RP]=] MUST behave as described in [[#rp-operations]] to obtain all the security benefits offered by this specification. See
+[[#sctn-rp-benefits]] for further discussion of this.
+
 
 ## All Conformance Classes ## {#conforming-all-classes}
 
@@ -4757,6 +4764,49 @@ RogueList when performing ECDAA-Verify (see section 3.6 in [[!FIDOEcdaaAlgorithm
 [[FIDOMetadataService]] provides one way to access such information.
 
 
+## Security Benefits for [RPS] ## {#sctn-rp-benefits}
+
+The main benefits offered to [=[RPS]=] by this specification include:
+
+1. Users and accounts can be secured using widely compatible, easy-to-use multi-factor authentication.
+1. The [=[RP]=] does not need to provision [=authenticator=] hardware to its users. Instead, each user can independently obtain
+    any conforming [=authenticator=] and use that same [=authenticator=] with any number of [=[RPS]=]. The [=[RP]=] can optionally
+    enforce requirements on [=authenticators=]' security properties by inspecting the [=attestation statements=] returned from the
+    [=authenticators=].
+1. [=Registration=] and [=authentication=] [=ceremonies=] are resistant to [=man-in-the-middle attacks=].
+1. The [=[RP]=] can automatically support multiple types of [=user verification=] - for example PIN, biometrics and/or future
+    methods - with little or no code change, and can let each user decide which they prefer to use via their choice of
+    [=authenticator=].
+1. The [=[RP]=] does not need to store additional secrets in order to gain the above benefits.
+
+As stated in the [[#conforming-relying-parties|Conformance]] section, the [=[RP]=] MUST behave as described in [[#rp-operations]]
+to obtain all of the above security benefits. However, one notable use case that departs slightly from this is described in the
+next section.
+
+
+### Considerations for Self and None Attestation Types and Ignoring Attestation ### {#sctn-no-attestation-security-attestation}
+
+When [[#registering-a-new-credential|registering a new credential]], the [=[RP]=] MAY choose to accept an [=attestation
+statement=] of [[#sctn-attestation-types|type]] [=self attestation|Self=] or [=no attestation statement|None=], or to not verify
+the [=attestation statement=]. In all of these cases the [=[RP]=] loses much of benefit (3) listed above, but retains the other
+benefits.
+
+In these cases it is possible for a [=man-in-the-middle attack|man-in-the-middle attacker=] - for example, a malicious [=client=]
+or script - to replace the [=credential public key=] to be registered, and subsequently tamper with future [=authentication
+assertions=] bound for the same [=[RP]=] and passing through the same attacker. Accepting these [[#sctn-attestation-types|types]]
+of [=attestation statements=] therefore constitutes a [=leap of faith=]. In cases where [=registration=] was accomplished
+securely, subsequent [=authentication=] [=ceremonies=] remain resistant to [=man-in-the-middle attacks=], i.e., benefit (3) is
+retained. Note, however, that such an attack would be easy to detect and very difficult to maintain, since any [=authentication=]
+[=ceremony=] that the same attacker does not or cannot tamper with would always fail.
+
+The [=[RP]=] SHOULD consider the above in its threat model when deciding its policy on what [[#sctn-attestation-types|attestation
+types]] to accept or whether to ignore [=attestation=].
+
+Note: The default [[#sctn-attestation-types|attestation type]] is [=None=], since the above issues will likely not be a major
+concern in most [=[RPS]=]' threat models. For example, the [=man-in-the-middle attack=] described above is more difficult than a
+[=man-in-the-middle attack=] against a [=[RP]=] that only uses conventional password authentication.
+
+
 ## credentialId Unsigned ## {#credentialIdSecurity}
 
 The [=credential ID=] is not signed.