Skip to content

Commit

Permalink
Divide security/privacy considerations into subsections by audience (#…
Browse files Browse the repository at this point in the history 
…1298)

* Divide security/privacy considerations into subsections by audience

Fixes #1039

* Add editor comment about <span> for old anchor

* Move RP security consideration out from authenticators section
  • Loading branch information
@emlun @equalsJeffH
emlun authored and equalsJeffH committed Sep 20, 2019
1 parent 32c216c commit 8ed793f
Showing 1 changed file with 88 additions and 57 deletions.
145 changes: 88 additions & 57 deletions index.bs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5769,23 +5769,24 @@ At this time, this specification does not feature detailed security consideratio
Also, the [[FIDOAuthnrSecReqs]] document suite provides useful information about [=authenticator=] security characteristics.

The below subsections comprise the current Web Authentication-specific security considerations.
They are divided by audience;
general security considerations are direct subsections of this section,
while security considerations specifically for [=authenticator=], [=client=] and [=[RP]=] implementers
are grouped into respective subsections.


## Cryptographic Challenges ## {#sctn-cryptographic-challenges}
## Credential ID Unsigned ## {#sctn-credentialIdSecurity}

As a cryptographic protocol, Web Authentication is dependent upon randomized challenges
to avoid replay attacks. Therefore, the values of both {{PublicKeyCredentialCreationOptions}}.{{PublicKeyCredentialCreationOptions/challenge}} and {{PublicKeyCredentialRequestOptions}}.{{PublicKeyCredentialRequestOptions/challenge}} MUST be randomly generated
by [=[RPS]=] in an environment they trust (e.g., on the server-side), and the
returned {{CollectedClientData/challenge}} value in the client's
response MUST match what was generated. This SHOULD be done in a fashion that does not rely
upon a client's behavior, e.g., the Relying Party SHOULD store the challenge temporarily
until the operation is complete. Tolerating a mismatch will compromise the security
of the protocol.
The [=credential ID=] is not signed.
This is not a problem because all that would happen if an [=authenticator=] returns
the wrong [=credential ID=], or if an attacker intercepts and manipulates the [=credential ID=], is that the [=[WRP]=] would not look up the correct
[=credential public key=] with which to verify the returned signed [=authenticator data=]
(a.k.a., [=assertion=]), and thus the interaction would end in an error.

In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD
therefore be at least 16 bytes long.

## Attestation Security Considerations ## {#sctn-attestation-security-considerations}
## Security considerations for [=authenticators=] <span id="sctn-attestation-security-considerations"></span> ## {#sctn-security-considerations-authenticator}
<!-- Note: the above <span> is there to preserve the #sctn-attestation-security-considerations anchor although the section it was
tied to has been removed. The section had no text of its own and served only to group the following two subsections together. -->

### Attestation Certificate Hierarchy ### {#sctn-cert-hierarchy}

Expand All @@ -5811,20 +5812,38 @@ manufactured [=[WAA]s=], if the exposure was due to a firmware flaw. (The proces
scope for this specification.) If the [=[WAA]=] manufacturer does not have this capability, then it may not be
possible for [=[RPS]=] to trust any further attestation statements from the affected [=[WAA]s=].

If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [=[RP]=]'s policy
requires rejecting the registration/authentication request in these situations, then it is RECOMMENDED that the [=[RP]=] also
un-registers (or marks with a trust level equivalent to "[=self attestation=]") [=public key credentials=] that were registered
after the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus RECOMMENDED
that [=[RPS]=] remember intermediate attestation CA certificates during Authenticator registration in order to un-register
related [=public key credentials=] if the registration was performed after revocation of such certificates.

If an [=ECDAA=] attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked
authenticators) maintained by the related ECDAA-Issuer. The [=[RP]=] SHOULD verify whether an authenticator belongs to the
RogueList when performing ECDAA-Verify (see section 3.6 in [[!FIDOEcdaaAlgorithm]]). For example, the FIDO Metadata Service
[[FIDOMetadataService]] provides one way to access such information.
authenticators) maintained by the related ECDAA-Issuer.

See also the related security consideration for [=[RPS]=] in [[#sctn-revoked-attestation-certificates]].


## Security considerations for [=clients=] ## {#sctn-security-considerations-client}

### Browser Permissions Framework and Extensions ### {#sctn-browser-permissions-framework-extensions}

## Security Benefits for [WRPS] ## {#sctn-rp-benefits}
Web Authentication API implementations SHOULD leverage the browser permissions framework as much as possible when obtaining user
permissions for certain extensions. An example is the location extension (see [[#sctn-location-extension]]), implementations of
which SHOULD make use of the existing browser permissions framework for the Geolocation API.


## Security considerations for [=[RPS]=] ## {#sctn-security-considerations-rp}

### Cryptographic Challenges ### {#sctn-cryptographic-challenges}

As a cryptographic protocol, Web Authentication is dependent upon randomized challenges
to avoid replay attacks. Therefore, the values of both {{PublicKeyCredentialCreationOptions}}.{{PublicKeyCredentialCreationOptions/challenge}} and {{PublicKeyCredentialRequestOptions}}.{{PublicKeyCredentialRequestOptions/challenge}} MUST be randomly generated
by [=[RPS]=] in an environment they trust (e.g., on the server-side), and the
returned {{CollectedClientData/challenge}} value in the client's
response MUST match what was generated. This SHOULD be done in a fashion that does not rely
upon a client's behavior, e.g., the Relying Party SHOULD store the challenge temporarily
until the operation is complete. Tolerating a mismatch will compromise the security
of the protocol.

In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD
therefore be at least 16 bytes long.

### Security Benefits for [WRPS] ### {#sctn-rp-benefits}

The main benefits offered to [=[WRPS]=] by this specification include:

Expand Down Expand Up @@ -5881,23 +5900,24 @@ Note: All variants of [=man-in-the-middle attacks=] described above are more dif
than a [=man-in-the-middle attack=] against conventional password authentication.


## Credential ID Unsigned ## {#sctn-credentialIdSecurity}

The [=credential ID=] is not signed.
This is not a problem because all that would happen if an [=authenticator=] returns
the wrong [=credential ID=], or if an attacker intercepts and manipulates the [=credential ID=], is that the [=[WRP]=] would not look up the correct
[=credential public key=] with which to verify the returned signed [=authenticator data=]
(a.k.a., [=assertion=]), and thus the interaction would end in an error.
### Revoked Attestation Certificates ### {#sctn-revoked-attestation-certificates}

If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [=[RP]=]'s policy
requires rejecting the registration/authentication request in these situations, then it is RECOMMENDED that the [=[RP]=] also
un-registers (or marks with a trust level equivalent to "[=self attestation=]") [=public key credentials=] that were registered
after the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus RECOMMENDED
that [=[RPS]=] remember intermediate attestation CA certificates during Authenticator registration in order to un-register
related [=public key credentials=] if the registration was performed after revocation of such certificates.

## Browser Permissions Framework and Extensions ## {#sctn-browser-permissions-framework-extensions}
If an [=ECDAA=] attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked
authenticators) maintained by the related ECDAA-Issuer. The [=[RP]=] SHOULD verify whether an authenticator belongs to the
RogueList when performing ECDAA-Verify (see section 3.6 in [[!FIDOEcdaaAlgorithm]]). For example, the FIDO Metadata Service
[[FIDOMetadataService]] provides one way to access such information.

Web Authentication API implementations SHOULD leverage the browser permissions framework as much as possible when obtaining user
permissions for certain extensions. An example is the location extension (see [[#sctn-location-extension]]), implementations of
which SHOULD make use of the existing browser permissions framework for the Geolocation API.
See also the related security consideration for [=authenticators=] in [[#sctn-ca-compromise]].


## Credential Loss and Key Mobility ## {#sctn-credential-loss-key-mobility}
### Credential Loss and Key Mobility ### {#sctn-credential-loss-key-mobility}

This specification defines no protocol for backing up [=credential private keys=], or for sharing them between [=authenticators=].
In general, it is expected that a [=credential private key=] never leaves the [=authenticator=] that created it. Losing an
Expand All @@ -5919,6 +5939,11 @@ different [=public key credential|credentials=] are [=bound credential|bound=] t

The privacy principles in [[!FIDO-Privacy-Principles]] also apply to this specification.

This section is divided by audience;
general privacy considerations are direct subsections of this section,
while privacy considerations specifically for [=authenticator=], [=client=] and [=[RP]=] implementers
are grouped into respective subsections.


## De-anonymization Prevention Measures ## {#sctn-privacy-attacks}

Expand Down Expand Up @@ -6003,7 +6028,9 @@ perfoming [=user verification=] and then signaling the result by setting the [=U
instead of revealing the biometric data itself to the [=[RP]=].


## Attestation Privacy ## {#sctn-attestation-privacy}
## Privacy considerations for [=authenticators=] ## {#sctn-privacy-considerations-authenticator}

### Attestation Privacy ### {#sctn-attestation-privacy}

Attestation keys can be used to track users or link various online identities of the same user together. This can be mitigated
in several ways, including:
Expand Down Expand Up @@ -6033,7 +6060,25 @@ in several ways, including:
signature using the [=ECDAA-Issuer public key=], but the attestation signature does not serve as a global correlation handle.


## Registration Ceremony Privacy ## {#sctn-make-credential-privacy}
### Privacy of [PII] Stored in Authenticators ### {#sctn-pii-privacy}

[=Authenticators=] MAY provide additional information to [=clients=] outside what's defined by this specification, e.g.,
to enable the [=client=] to provide a rich UI with which the user can pick which [=credential=] to use for an [=authentication
ceremony=]. If an [=authenticator=] chooses to do so, it SHOULD NOT expose [PII] unless successful [=user verification=] has been
performed. If the [=authenticator=] supports [=user verification=] with more than one concurrently enrolled user, the
[=authenticator=] SHOULD NOT expose [PII] of users other than the currently [=user verified|verified=] user. Consequently, an
[=authenticator=] that is not capable of [=user verification=] SHOULD NOT store [PII].

For the purposes of this discussion, the [=user handle=] conveyed as the {{PublicKeyCredentialUserEntity/id}} member of
{{PublicKeyCredentialUserEntity}} is not considered [PII]; see [[#sctn-user-handle-privacy]].

These recommendations serve to prevent an adversary with physical access to an [=authenticator=] from extracting [PII] about the
[=authenticator=]'s enrolled user(s).


## Privacy considerations for [=clients=] ## {#sctn-privacy-considerations-client}

### Registration Ceremony Privacy ### {#sctn-make-credential-privacy}

In order to protect users from being identified without [=user consent|consent=], implementations of the
{{PublicKeyCredential/[[Create]](origin, options, sameOriginWithAncestors)}} method need to take care to not leak information that
Expand All @@ -6056,7 +6101,7 @@ distinguishable error is returned, because in this case the user has confirmed i
leaked.


## Authentication Ceremony Privacy ## {#sctn-assertion-privacy}
### Authentication Ceremony Privacy ### {#sctn-assertion-privacy}

In order to protect users from being identified without [=user consent|consent=], implementations of the
{{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} method need to take care to not
Expand All @@ -6074,38 +6119,24 @@ one of the [=public key credential|credentials=] listed in the {{PublicKeyCreden
available to the user.


## Privacy Between Operating System Accounts ## {#sctn-os-account-privacy}
### Privacy Between Operating System Accounts ### {#sctn-os-account-privacy}

If a [=platform authenticator=] is included in a [=client device=] with a multi-user operating system, the [=platform
authenticator=] and [=client device=] SHOULD work together to ensure that the existence of any [=platform credential=] is revealed
only to the operating system user that created that [=platform credential=].


## Privacy of [PII] Stored in Authenticators ## {#sctn-pii-privacy}

[=Authenticators=] MAY provide additional information to [=clients=] outside what's defined by this specification, e.g.,
to enable the [=client=] to provide a rich UI with which the user can pick which [=credential=] to use for an [=authentication
ceremony=]. If an [=authenticator=] chooses to do so, it SHOULD NOT expose [PII] unless successful [=user verification=] has been
performed. If the [=authenticator=] supports [=user verification=] with more than one concurrently enrolled user, the
[=authenticator=] SHOULD NOT expose [PII] of users other than the currently [=user verified|verified=] user. Consequently, an
[=authenticator=] that is not capable of [=user verification=] SHOULD NOT store [PII].

For the purposes of this discussion, the [=user handle=] conveyed as the {{PublicKeyCredentialUserEntity/id}} member of
{{PublicKeyCredentialUserEntity}} is not considered [PII]; see [[#sctn-user-handle-privacy]].

These recommendations serve to prevent an adversary with physical access to an [=authenticator=] from extracting [PII] about the
[=authenticator=]'s enrolled user(s).

## Privacy considerations for [=[RPS]=] ## {#sctn-privacy-considerations-rp}

## User Handle Contents ## {#sctn-user-handle-privacy}
### User Handle Contents ### {#sctn-user-handle-privacy}

Since the [=user handle=] is not considered [PII] in [[#sctn-pii-privacy]], the [=[RP]=] MUST NOT include [PII], e.g., e-mail
addresses or usernames, in the [=user handle=]. This includes hash values of [PII], unless the hash
function is [=salted=] with [=salt=] values private to the [=[RP]=], since hashing does not prevent probing for guessable input
values. It is RECOMMENDED to let the [=user handle=] be 64 random bytes, and store this value in the user's account.


## Username Enumeration ## {#sctn-username-enumeration}
### Username Enumeration ### {#sctn-username-enumeration}

While initiating a [=registration ceremony|registration=] or [=authentication ceremony=], there is a risk that the [=[WRP]=] might leak sensitive
information about its registered users. For example, if a [=[RP]=] uses e-mail addresses as usernames and an attacker attempts to
Expand Down Expand Up @@ -6166,7 +6197,7 @@ leakage due to such an attack:
to the preceding authentication step, where it may be easier to solve.


## Privacy leak via credential IDs ## {#sctn-credential-id-privacy-leak}
### Privacy leak via credential IDs ### {#sctn-credential-id-privacy-leak}

[INFORMATIVE]

Expand Down

0 comments on commit 8ed793f

Please sign in to comment.