+++ This bug was initially created as a clone of Bug #1814722 +++

The FIDO AppID extension allows a relying party to request an assertion from a credential that was created using the legacy U2F javascript API. We seem to support this correctly in U2FHIDTokenManager but not in CTAPHIDTokenManager, i.e. not when security.webauthn.ctap2 is true.

Users can work around this by re-registering their security keys.

This bug has been fixed in Firefox 114, but persists again in 115 and up. Can you please review the fix? The app id extension is no longer supported.

There was a regression in AppID support in Nightly 115, Bug 1834771, but it was resolved. Our solution was to downgrade requests that include the AppID extension to CTAP1/U2F.

Does your token support CTAP1? What happens when you set security.webauthn.ctap2 to false?

No, the security token is only a CTAP2/FIDO2 token, without U2F. This is a challenge in an environment with both U2F and FIOD2 tokens which are in concurrently.

Is there a better way to solve this bug? It appears other browsers such as Chrome, Safari, Edge, and Operate support the extension and don't fall back to CTAP1 with the appid extension.

FWIW, it looks like Chrome will "fall back to U2F or collect a dummy touch [if CTAP1/U2F is not supported]" (source).

One problem with App ID + CTAP2.1 is that the authenticatorClientPIN command scopes the MC and GA permissions of a pinUvAuthToken to an RP ID. The way you implement the App ID extension is to search for credentials bound to the RP ID and then, if that fails, swap out the RP ID for the App ID and try again. With CTAP 2.1, the second phase of the search would require a fresh pinUvAuthToken, hence a second call to authenticatorClientPIN, and a second user verification prompt.

Upshot: I'm not sure we can do much better. I'd welcome suggestions in authrs #269.

For the use case in an environment with CTAP1/U2F only and CTAP2/CTAP2.1/FIDO2 only tokens, the current implementation in Firefox 115 breaks the WebAuthn authentication with the app id extension, since U2F is disabled on the FIDO2 tokens.

Questions:

1. Is it possible for Firefox to adopt the same mechanism as in Chrome to perform a dummy touch?
2. Is it possible to roll back to what the solution was in Firefox 114 since that worked and implement the appid extension as Chrome?

With a CTAP2.1 token and the app id extension, the token does not respond to the WebAuthn navigator.credentials.get() API.

I'd love to help here, but I'm not clear on what the difference is between Blink-based browsers and Firefox here. Where do I start to understand the underlying issue?

FWIW this breaks all of our new CTAP2 authenticators on Firefox 115+ -- users have to fall back to long-press for textual OTP, which is less secure.

Thanks Taral for stepping in.

To reproduce the issue you'll need a U2F only token and a FIDO2 only token.

1. The U2F token will need to be registered with U2F.
2. The FIDO2 token will need to be registered with WebAuthn.

Then you'll need to set up an auth server which uses the AppId extenstion.

Taken from: https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Migrating_from_U2F.html

If you have users who have already registered U2F credentials with the U2F API, there is an extra step you need to take to make those existing credentials work in WebAuthn so your users do not have to re-register their authenticators.

The reason for this is that the U2F AppID and the WebAuthn Relying Party (RP) ID are slightly different. This does not matter for new registrations because the authenticator identifies the Relying Party by a hash of that ID, but if you try to use a U2F credential in the WebAuthn API, those hashes will not match. The solution to this is to use the appid extension and pass the U2F AppId as a parameter. That way the client can try the U2F AppId if the authenticator does not recognize the WebAuthn RP ID, so you can upgrade your server to using WebAuthn without breaking your users’ existing credentials.

In chrome, using the AppId extension works without any issues for U2F only and FIDO2 only security keys.
In FireFox as of version 115, all FIDO2 tokens fall to U2F mode which isn't supported (disabled on the firmware), which breaks the WebAuthn Auth. In FireFox 114, this wasn't a problem since the AppId support hasn't been implemented.

Can it repro with a single token that exposes both U2F and CTAP2 interfaces?

@Taral, no, this bug does not affect tokens that support U2F/CTAP1. Please open a new bug and describe the problem you're having as well as the make and model of your authenticator.

Just checking to see if the two tokens are required for repro, not related to my issue. :)

Okay, good news - I have confirmed that this is the source of our problem. Removing the appid extension results in successful CTAP2 auth. :)

(In reply to John Schanck [:jschanck] from comment #3)

With CTAP 2.1, the second phase of the search would require a fresh pinUvAuthToken, hence a second call to authenticatorClientPIN, and a second user verification prompt.

So I'm not clear on this. What I'm experiencing is no user verification prompt. Why would the fix result in two when I'm not getting any at the moment?

(In reply to Taral from comment #10)

Okay, good news - I have confirmed that this is the source of our problem. Removing the appid extension results in successful CTAP2 auth. :)

Try reproducing this in other browsers such as Chrome, Safari, Edge. Even with the AppId extension, CTAP2 auth is successful, while in FF, the AppId extension must be removed. The ask is to make Firefox operate like Chrome. When U2F will be phased out for major companies, this will be a HARD blocker in Firefox.

I have a patch for this upstream https://github.com/mozilla/authenticator-rs/pull/297. My concern about repeated UV prompts might have been misplaced, as U2F credentials that require the App ID extension should be silently discoverable.

(In reply to John Schanck [:jschanck] from comment #13)

I have a patch for this upstream https://github.com/mozilla/authenticator-rs/pull/297. My concern about repeated UV prompts might have been misplaced, as U2F credentials that require the App ID extension should be silently discoverable.

Thank you John, great work. Can this fix be released in a FF115 update?

Thanks John! That's great news. +1 to the 115 ESR backport request.

Depends on D186806

https://hg.mozilla.org/mozilla-central/rev/fa8ee8bed634

Can this be backported to 115 ESR to get things working again there?

[Tracking Requested - why for this release]:

The patch landed in nightly and beta is affected.
:jschanck, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox118 to wontfix.

For more information, please visit BugBot documentation.