W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2021

[webauthn] Closed Pull Request: Draft changes for allowCredentials to indicate per-credential verification

From: Shane Weeden via GitHub <sysbot+gh@w3.org>
Date: Wed, 27 Jan 2021 20:13:09 +0000
To: public-webauthn@w3.org
Message-ID: <pull_request.closed-557871632-1611778387-sysbot+gh@w3.org>
sbweeden has just closed Firstyear's pull request 1547 for https://github.com/w3c/webauthn:

== Draft changes for allowCredentials to indicate per-credential verification ==
This is a rough draft of changes to the webauthn specification to allow the service to indicate to the browser per-authenticator verification policies.

The current definition of userVerification is focussed around the concept of per-ceremony verification requirements. However, this is not compatible with identity management systems which tend to have per-authenticator requirements, or even per-identity requirements. 

An example of this is today if an IDM service existed that allowed a user to have multiple credentials, and those credentials could be either verified (MFA devices, as per https://pages.nist.gov/800-63-3/sp800-63b.html 5.1.9) or the user may have a password and an unverified single factor authenticator (SFA https://pages.nist.gov/800-63-3/sp800-63b.html 5.1.7). In the webauthn specification this is not possible to express in `PublicKeyCredentialRequestOptions.userVerification`. If this is set to "required" we exclude the SFA device. If this is set to "discouraged" we exclude the MFA device. If set to preferred, we can cause the SFA device to upgrade to "verified" in some browsers (IE CTAP2 vs CTAP1). We also then run the risk that the user may tamper with the `PublicKeyCredentialRequestOptions.userVerification` to set it to discouraged, causing our MFA device to downgrade to an SFA device, as this field is not part of the hashed collected client data. Since we issued the request as 'preferred' we must accept unverified credentials, which may be an authentication bypass or downgrade attack depending on the server implementation.

This means to satisfy this scenario would would require a "lead in" page to request from the user which of their devices/authentication methods they wish to use, so that we can issue the correct `PublicKeyCredentialRequestOptions.userVerification`, but this may be an information disclosure which may be considered a risk to some organisations.

As webauthn intends to be a device authentication for users, and those users must exist in an identity management system with requirements and policy around authentication, then webauthn should have a method to represent this in it's exchange.

This PR extends the PublicKeyCredentialDescriptor field with an optional boolean `verificationRequired` which defines per-authenticator verification policy that the server can issue to support mixed SFA/MFA devices in a single webauthn operation. The browser is then able to offer the correct verification steps for each device as required, and the server can verify this with it's per-authenticator knowledge of the requirements. If the browser does not understand this field (older browser etc) then it will continue to use the userVerification flag from PublicKeyCredentialRequestOptions.

This also changes the default userVerification from preferred to discouraged. This is because in authentication, since preferred is not part of the signed clientdatajson and may be altered by the client, and the server *must* accept unverified credentials by design, then preferred is equivalent to discouraged. It would then be implementation specific on how to act in this scenario, but it is very likely this represents a verification bypass. Preferred still has value in credential registration however, allowing the client to indicate if the device is a SFA or MFA device, and if tampered with at this stage to downgrade to discouraged, the service is able to make other appropriate policy decisions to assume the device is not verified IE then continuing to enforce a password as another factor. 

fixes: https://github.com/w3c/webauthn/issues/1510

see also: https://fy.blackhats.net.au/blog/html/2020/11/21/webauthn_userverificationpolicy_curiosities.html


<!--
    This comment and the below content is programatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/Firstyear/webauthn/pull/1547.html" title="Last updated on Jan 20, 2021, 1:33 AM UTC (49576f9)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/1547/a1f9066...Firstyear:49576f9.html" title="Last updated on Jan 20, 2021, 1:33 AM UTC (49576f9)">Diff</a>

See https://github.com/w3c/webauthn/pull/1547


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 January 2021 20:13:11 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:42 UTC