FIDO_ERR_NO_CREDENTIALS when doing fido_dev_get_assert

[VedaviBalaji]

I am trying to use my YubiKey Edge (4.3.7) [OTP+FIDO] to authenticate to an internal site. However, the key works in webauthn.io website after registering and authenticating but does not work in my internal site where there is only assertion as my key is already registered.

$ fido2-token -I

proto: 0x02
major: 0x04
minor: 0x03
build: 0x07
caps: 0x01 (wink, nocbor, msg)

$ fido2-assert with FIDO_DEBUG=1

run_manifest: found 1 hid device
fido_tx: dev=0x6000024e53b0, cmd=0x06
fido_tx: buf=0x6000024e53b0, len=8
0000: 68 a1 16 f0 c4 fa 66 c4
fido_rx: dev=0x6000024e53b0, cmd=0x06, ms=-1
rx_preamble: buf=0x700007da6020, len=64
0000: ff ff ff ff 86 00 11 68 a1 16 f0 c4 fa 66 c4 00
0016: 69 00 03 02 04 03 07 01 00 00 00 00 00 00 00 00
0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
rx: payload_len=17
fido_rx: buf=0x6000024e53b8, len=17
0000: 68 a1 16 f0 c4 fa 66 c4 00 69 00 03 02 04 03 07
0016: 01
fido_tx: dev=0x6000024e53b0, cmd=0x03
fido_tx: buf=0x6000021b33a8, len=138
0000: 00 02 07 00 00 00 81 ff ff ff ff ff ff ff ff ff
0016: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0032: ff ff ff ff ff ff ff ac cf 5d 46 ee 39 36 b6 65
0048: 55 50 3d 05 48 a9 fc b6 39 01 f5 ee b5 35 47 c7
0064: dc 59 cf 2a 31 ca ac 40 4d 66 b4 b7 fb 79 1b 18
0080: cf ba 49 db 75 dc 6b 78 34 50 b0 c3 d7 0a f5 ee
0096: 17 e2 91 15 5c b5 0b b3 38 84 72 ee f8 5a 0a 99
0112: b6 e7 36 61 52 09 d0 41 10 c0 3f 6c e8 8e 95 02
0128: 5b e0 b6 e0 46 e8 fd 42 00 00
fido_rx: dev=0x6000024e53b0, cmd=0x03, ms=19996
rx_preamble: buf=0x700007da5f40, len=64
0000: 00 69 00 03 83 00 02 6a 80 00 00 00 00 00 00 00
0016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
rx: payload_len=2
fido_rx: buf=0x7fc6c4045000, len=2
0000: 6a 80
u2f_authenticate_single: not found
fido_tx: dev=0x6000024e53b0, cmd=0x03
fido_tx: buf=0x6000021b33a8, len=138
0000: 00 02 07 00 00 00 81 ff ff ff ff ff ff ff ff ff
0016: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0032: ff ff ff ff ff ff ff ac cf 5d 46 ee 39 36 b6 65
0048: 55 50 3d 05 48 a9 fc b6 39 01 f5 ee b5 35 47 c7
0064: dc 59 cf 2a 31 ca ac 40 5e 0d 7e f1 ca 26 4b 5e
0080: f5 b5 13 6e 6d 8a aa 1a 19 c3 31 a7 8d 13 44 b1
0096: cf 01 b6 30 1c 3d 13 5c 7a 70 4d 43 78 42 73 cc
0112: cc 5c f1 8f f7 f0 71 e1 5b 31 ab c1 e8 7f 53 6d
0128: 7f b1 47 ba bb dc 79 67 00 00
fido_rx: dev=0x6000024e53b0, cmd=0x03, ms=19979
rx_preamble: buf=0x700007da5f40, len=64
0000: 00 69 00 03 83 00 02 6a 80 00 00 00 00 00 00 00
0016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
rx: payload_len=2
fido_rx: buf=0x7fc6c4045000, len=2
0000: 6a 80
u2f_authenticate_single: not found

This is the sample request:

GetRequest { challenge: "xxxxxx", rp_id: "x.com", timeout: None, allow_credentials: Some([PublicKeyCredentialDescriptor { id: "yyyyy", transports: ["usb"], type_field: "public-key" }, PublicKeyCredentialDescriptor { id: "jjjjjjj", transports: ["usb"], type_field: "public-key" }]), user_verification: Some("discouraged"), attestation: Some("none"), attestation_formats: None, extensions: Some({"appid": String("https://x.com/app-id.json"), "remoteDesktopClientOverride": Object {"origin": String("https://x.com"), "sameOriginWithAncestors": Bool(true)}}) }

I tried ykman --device 555555 fido credentials list and it errored as ERROR: Credential Management is not supported on this YubiKey.. I wonder if this key is supported this way for the above Get requests. I am using libfido2 v1.13.0 with rust bindings in macOS

[LDVG]

Hi,

The most probable explanation I can think of is that the RP ID does not match what was used when the key was registered. An alternative is that you're passing the wrong Credential ID.

Depending on how the authenticator was registered, you may have to deal with the appid extension. Note that libfido2 does not have internal support for the appid extension, the client (your application) must handle it themselves ¹, see the client processing steps in the WebAuthn specification. In a nutshell, it essentially boils down to retrying the assertion with the AppID given to fido_assert_set_rp() as the id argument.

Footnotes

1. However, do note the currently unreleased workaround for the windows://hello pseudo-device. ↩

[VedaviBalaji]

How can I identify how the credential was registered, whether u2f or fido2?
Is there any way to identify if the credential is u2f or fido2?
The assert request comes with appid even when the credential was generated using fido2, which I believe the server sends with good intention, but is the only way to deal with is trying to fido_dev_get_assert twice, first with appid maybe and if it fails then with rpid?

In the documentation I see this for fido_assert_set_winhello_appid -
Note that fido_assert_set_winhello_appid() is not needed on platforms offering CTAP primitives, since the authenticator can be silently probed for the existence of U2F credentials. Basically I am not sure how to do this.

[LDVG]

but is the only way to deal with is trying to fido_dev_get_assert twice, first with appid maybe and if it fails then with rpid?

Yes, this is basically what you have to do to support the AppID extension.

Basically I am not sure how to do this.

The manual you're quoting is referring to the concept that the CTAP specification calls a "pre-flight", in which you request one or several assertions from the authenticator with user presence set to false. This makes it possible to silently probe for the existence of U2F credentials. If the credential is known to the authenticator, the assertion is requested by the client one final time with the correct settings.

For a pre-flight assertion, a FIDO2 authenticator will respond with FIDO_OK if it knows of the credential. An U2F authenticator will instead respond with FIDO_ERR_USER_PRESENCE_REQUIRED.

There's a longer conversation on probing/pre-flights in discussion #750 (comment) that may be interesting to you.