Summary:
FIDO U2F's specification says that when the wrong security key responds to a
signature, or when an already-registered key exists, that the UA should return
error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things
for WebAuthn and now we don't. This changes the soft token to return that at
the appropriate times, and updates the expectations of U2F.cpp that it should
use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE.
Also, note that WebAuthn's specification says that if any authenticator returns
"InvalidStateError" that it should be propagated, as it indicates that the
authenticator obtained user consent and failed to complete its job [1].
This change to the Soft Token affects the WebAuthn tests, but in a good way.
Reading the WebAuthn spec, we should not be returning NotAllowedError when there
is consent from the user via the token (which the softtoken always deliveres).
As such, this adjusts the affected WebAuthn tests, and adds a couple useful
checks to test_webauthn_get_assertion.html for future purposes.
[1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new
credential", Step 20, Note 2: "If any authenticator returns an error status
equivalent to "InvalidStateError"..."
Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4
Reviewers: ttaubert
Bug #: 1460767
Differential Revision: https://phabricator.services.mozilla.com/D1269
--HG--
extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
Summary:
This patch restricts any calls to navigator.credentials.* methods to selected
tabs. Any active WebAuthn request will be aborted when the parent chrome
window loses focus, or the <browser> is backgrounded.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1409202
Differential Revision: https://phabricator.services.mozilla.com/D688
--HG--
extra : amend_source : 112378a1ab2e883d7603e8a28ff3f8e944d57b5f
Summary:
Always replace attestation statements with a "none" attestation.
Bug 1430150 will introduce a prompt that asks the user for permission whenever
the RP requests "direct" attestation. Only if the user opts in we will forward
the attestation statement with the token's certificate and signature.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1416056
Differential Revision: https://phabricator.services.mozilla.com/D567
The Web Authentication CollectedClientData is missing the type field, which
is just a simple string. (The editor's draft also removes hashAlgorithm, but
let's not get ahead of ourselves...)
Add in that simple string. This was found at interop testing.
MozReview-Commit-ID: DlawLyHTYhB
--HG--
extra : rebase_source : 6cdd8e14161dc4aea5bfd1baf60c7384219ba951
The WebAuthn spec lets RPs ask to specifically get direct attestation certificates
during credential creation using the "Attestation Conveyance Preference" [1].
This change adds that field into the WebIDL and ignores it for now. This is
pre-work to Bug #1430150 which will make this useful (which in turn requires
Bug #1416056's support for anonymizing those attestation certificates).
[1] https://www.w3.org/TR/webauthn/#attestation-convey
MozReview-Commit-ID: 763vaAMv48z
--HG--
extra : rebase_source : 7fb7c64a0ee3167032485378af6074a7366295a4
Summary:
Add support for PublicKeyCredentialRequestOptions.userVerification. For now
this basically means that we'll abort the operation with NotAllowed, as we
don't support user verification yet.
Pass PublicKeyCredentialDescriptor.transports through to the token manager
implementations. The softoken will ignore those and pretend to support all
transports defined by the spec. The USB HID token will check for the "usb"
transport and either ignore credentials accordingly, or abort the operation.
Note: The `UserVerificationRequirement` in WebIDL is defined at https://w3c.github.io/webauthn/#assertion-options
Reviewers: jcj, smaug
Reviewed By: jcj, smaug
Bug #: 1406467
Differential Revision: https://phabricator.services.mozilla.com/D338
--HG--
extra : amend_source : 314cadb3bc40bbbee2a414bc5f13caed55f9d720
webauthn says[1] that public keys are encoded as COSE keys. I find the COSE
RFC quite circuitous in many respects and so any reviews should check whether
they agree with my understanding of what should be in a COSE key.
The webauthn spec says that the key:
“MUST contain the "alg" parameter and MUST NOT contain
any other optional parameters.”
I don't believe that any of the parameters included are optional but, again, I
don't think the RFC is completely clear.
[1] https://www.w3.org/TR/webauthn/#sec-attested-credential-data
MozReview-Commit-ID: 2023mW3yVWU
--HG--
extra : rebase_source : 21d84d67f19d1885b73473a4d77d15f6c4cd80c2
Summary:
We currently implement no platform authenticators, so this would always
resolve to false. For those cases, the spec recommends a resolve timeout
on the order of 10 minutes to avoid fingerprinting.
A simple solution is thus to never resolve the promise, otherwise we'd
have to track every single call to this method along with a promise
and timer to resolve it after exactly X minutes.
A Relying Party has to deal with a non-response in a timely fashion, so
we can keep this as-is (and not resolve) even when we support platform
authenticators but they're not available, or a user rejects a website's
request to use them.
Reviewers: jcj, smaug
Reviewed By: jcj, smaug
Bug #: 1406468
Differential Revision: https://phabricator.services.mozilla.com/D217
The WD-06 (and later) WebAuthn specs choose to move to integer algorithm
identifiers for the signatures [1], with a handful of algorithms identified [2].
U2F devices only support ES256 (e.g., COSE ID "-7"), so that's all that is
implemented here.
Note that the spec also now requires that we accept empty lists of parameters,
and in that case, the RP says they aren't picky, so this changes what happens
when the parameter list is empty (but still aborts when the list is non-empty
but doesn't have anything we can use) [3].
There's a follow-on to move parameter-validation logic into the U2FTokenManager
in Bug 1409220.
[1] https://w3c.github.io/webauthn/#dictdef-publickeycredentialparameters
[2] https://w3c.github.io/webauthn/#alg-identifier
[3] https://w3c.github.io/webauthn/#createCredential bullet #12
MozReview-Commit-ID: KgL7mQ9u1uq
--HG--
extra : rebase_source : 2a1767805779a9f8049102723011193f113f0713
This covers these renames:
* In CollectedClientData, hashAlg => hashAlgorithm
* In CollectedClientData, tokenBinding => tokenBindingId
* In MakePublicKeyCredentialOptions, parameters => pubKeyCredParams
* In MakePublicKeyCredentialOptions, excludeList => excludeCredentials
* In PublicKeyCredentialRequestOptions, allowList => allowCredentials
* Transport (WebAuthnTransport in Gecko) => AuthenticatorTransport
MozReview-Commit-ID: 3FdRnkosy83
--HG--
extra : rebase_source : 22f124c781b03837ad0cd4be4edf34527e3b9d38
This covers these renames:
* In PublicKeyCredentialParameters, algorithm => alg
* MakeCredentialOptions => MakePublicKeyCredentialOptions
* PublicKeyCredentialEntity => PublicKeyCredentialRpEntity
* Attachment => AuthenticatorAttachment
It sets a default excludeList and allowList for the make / get options.
It adds the method isPlatformAuthenticatorAvailable which is incomplete and
not callable, to be completed in Bug 1406468.
Adds type PublicKeyCredentialRpEntity.
Adds "userId" to AuthenticatorAssertionResponse.
Adds "id" as a buffer source to PublicKeyCredentialUserEntity and as a
DOMString to PublicKeyCredentialRpEntity, refactoring out the "id" field
from the parent PublicKeyCredentialEntity.
It also adds a simple enforcement per spec 4.4.3 "User Account Parameters for
Credential Generation" that the new user ID buffer, if set, be no more than
64 bytes long. I mostly added it here so I could adjust the tests all at once
in this commit.
MozReview-Commit-ID: IHUdGVoWocq
--HG--
extra : rebase_source : bc1793f74700b2785d2bf2099c0dba068f717a59
WebAuthn has added a flag UV to indicate the user was biometrically verified. We
have to make sure not to set that flag for U2F. Turns out we already do that,
but let's add the constant and such.
Ref: https://w3c.github.io/webauthn/#authenticator-data
MozReview-Commit-ID: 6Qtjdkverls
--HG--
extra : rebase_source : 660348596b917d8f461b19298e01dbe19410b63f
There's an intermittent which might be spurious because ASN.1 signatures might
sometimes be less than 70 bytes, but the actual floor is probably 68 (32 + 32
+ 4).
It's a sanity check, so I've adjusted it down and also am now emitting the
offending key bytes if this triggers again.
MozReview-Commit-ID: 1wwU9Q3BUPF
--HG--
extra : rebase_source : 2877deb770f8bf4bcf31dae40f75016892dc9d53
The Web Authentication types, by spec, return ArrayBuffer objects, while we
were returning a concrete Uint8Array. This is a fairly straightforward change
to add functionality to CryptoBuffer and the WebIDL types, however it's a
substantial change to the tests.
Frankly, the tests just could use another pass of clean-up now, since this is
a lot of relative ugliness added in. I refactored tab_webauthn_success.html
pretty heavily -- since it was also fairly ugly to start -- but I decided to go
with a lighter touch on the other tests.
MozReview-Commit-ID: 9vb1wdLo3SI
--HG--
rename : dom/webauthn/tests/browser/frame_webauthn_success.html => dom/webauthn/tests/browser/tab_webauthn_success.html
extra : rebase_source : bd2bc326c6bb5e00929b14c7aae66eba335c0605
Now that there are actual hardware devices, this test can't be run: it
depended on there being a deliberately-erroring implementation of WebAuthn
which would instantly reject promises. Fortunately, this test was really more
a test that telemetry scalars work properly than really the functionality
of WebAuthn.
Sadly, I don't see any way to re-enable this test without adding a new test-
only pref to the tree, which doesn't seem worth it for the telemetry.
So this patch removes the offending test completely which was backed out in
https://hg.mozilla.org/integration/mozilla-inbound/rev/c115eec567a6 .
MozReview-Commit-ID: LiLuQHbPU1z
In Bug 1380421 we reverted some behavior that required Web Authentication's
RP ID to be domain string to permit it to be an origin, too, for interop
testing. That is no longer needed, so this patch resumes enforcement that
RP ID be a domain string.
It also adds a needed test that the RP ID hash is calculated correctly.
MozReview-Commit-ID: 8dDjzo5kQKP
--HG--
extra : rebase_source : 65cd7b9f3a6ecfc58805daf102f33966c9b19b98
WD-05 changed the "hashAlg" parameter of the CollectedClientData definition
from using an internally-defined "S256" string to identify the sha256 digest
to the definition in WebCrypto [1]. This only appears once, hard-coded in
WebAuthn (since U2F only supports SHA-256), so we need to change that one
instance.
[1] https://www.w3.org/TR/WebCryptoAPI/#sha-registration
MozReview-Commit-ID: 8de2CIGBBGA
--HG--
extra : rebase_source : e54c0d1f3f9551be48c3a72444edf62c45c647c4
This patch intends to obtain a 1) rough sense of the percentage of telemetry
population using Web Authentication over time, and 2) whether or not the
Authentication request was successful or errored out as a scalar. It also tracks
3) how long it takes for requests to complete as a histogram.
It counts Register (enrollment) and Sign (login) separately as we would
anticipate there being far, far more Sign uses than Register.
MozReview-Commit-ID: 8DFyKAG8XJw
--HG--
extra : rebase_source : 0c168b32b995ffffda804538d2b92009d4dc38c5
The WebAuthn WD-05 version of the specification defines the Origin field [1]
of the CollectedClientData as being set to the RP ID [2][3].
Note there is some ambiguity in the specification, as [1] says
CollectedClientData.Origin is the document's origin, while the
algorithms [2] and [3] set it to RP ID.
I'm going to stick with the algorithm's definition for this patch; it's
simple to revert when we move to WD-06 (Bug 1384776).
[1] https://www.w3.org/TR/webauthn/#dom-collectedclientdata-origin
[2] https://www.w3.org/TR/webauthn/#createCredential
[3] https://www.w3.org/TR/webauthn/#getAssertion
MozReview-Commit-ID: LW918sIg5wH
--HG--
extra : rebase_source : 799f5fa8878614c45d0def07d01d6c1c0c6e9824
This patch intends to obtain a 1) rough sense of the percentage of telemetry
population using Web Authentication over time, and 2) whether or not the
Authentication request was successful or errored out as a scalar. It also tracks
3) how long it takes for requests to complete as a histogram.
It counts Register (enrollment) and Sign (login) separately as we would
anticipate there being far, far more Sign uses than Register.
MozReview-Commit-ID: 8DFyKAG8XJw
--HG--
extra : rebase_source : c93eeac7a978a1d1c4b08ff1e18e2548b1045ced
The Web Authentication PublicKeyCredential object has two fields currently
unpopulated which, to be spec-compliant, must be set. These fields duplicate
available data.
[PublicKeyCredential.id] must be set to the base64url encoding with omitted
padding of whatever data is in "rawId".
[PublicKeyCredential.type] must be the literal "public-key".
MozReview-Commit-ID: L6wPYpZdD8A
--HG--
extra : rebase_source : 3ca83598b70f99f4d60f303d113e875046268669
Web Authentication uses JWK algorithm names (ES256) instead of WebCrypto names
(such as P-256). There are other JWK algorithm names, but our current U2F-backed
implementation only can support ES256 anyway, as that's all that FIDO U2F
devices understand. This patch limits us to the name ES256 for the "alg"
parameter.
MozReview-Commit-ID: 3V5DMzVzPad
--HG--
extra : rebase_source : 4fcf797ca0edc49f143333cc24aa51071cf719f5
This adjusts tests to also check origin-based RP IDs, for interop
purposes. When we officially move up to WD-06, we'll want to remove these.
MozReview-Commit-ID: FJRg7vxZIcN
--HG--
extra : rebase_source : 6b89ef1ec5f8f6312bc00740b171540dd2a111cf
nsHTMLDocument included IsRegistrableDomainSuffixOfOrEqualTo() to facilitate
some use cases in Web Authentication, and this patch adds support to our
implementation. The general idea is to permit relaxing some of the same-origin
policy for single-sign-on type approaches, while restricting other uses. [1]
[1] https://w3c.github.io/webauthn/#rp-id
MozReview-Commit-ID: BP74OYvcwBJ
--HG--
extra : rebase_source : 94b62f9063de129dc30c4457578b50088a3c92e0
The spec for WebAuthn defines "RP ID" as a "valid domain string" [1], whereas we
were using an origin string (with the scheme and whatnot). This patch corrects
the default rpId strings (when not overriden) to be domain strings.
[1] https://w3c.github.io/webauthn/#rp-id
MozReview-Commit-ID: 2p1cEQDa2FV
--HG--
extra : rebase_source : 8be13b8e88abb409e15c1bf9142f18d786699504
Tim Taubert
J.C. Jones
Kris Maglione
Tooru Fujisawa
Ciure Andrei
Adam Langley
Carsten "Tomcat" Book
David Keeler
Kyle Machulis