passkey_child doesn't prompt for PIN when device returns FIDO_ERR_PIN_REQUIRED

[romeo-am]

I'm using a Token2 Bio3 with FreeIPA passkey auth on Rocky 10. The setup is --require-user-verification=off in FreeIPA and alwaysUv=true on the key, so the key enforces UV locally via fingerprint. When the fingerprint reads correctly, auth works.

When the fingerprint doesn't read, the prompt just loops back to "Insert your passkey device, then press ENTER" and there's no way to enter a PIN. The only recovery is to unplug the key and try again.

From /var/log/sssd/passkey_child.log:

[passkey_child] [get_assert_data] (0x0400): Getting assert.
[passkey_child] [request_assert] (0x0040): fido_dev_get_assert failed [54]: FIDO_ERR_PIN_REQUIRED.

The device returns FIDO_ERR_PIN_REQUIRED to indicate PIN should be used. passkey_child logs it correctly then exits with status 1 instead of prompting for the PIN.

The same key handles this correctly in Chromium WebAuthn: fingerprint failure falls through to a PIN prompt within the same flow.

To reproduce:

• Biometric FIDO2 key with alwaysUv=true (Token2 PIN+ Bio3, AAGUID eabb46cce24180bfae9e96fa6d2975cf)
• ipa user-add-passkey <user> --register
• ipa passkeyconfig-mod --require-user-verification=off
• Trigger any PAM auth, fail or skip the fingerprint
• Expected: PIN prompt
• Actual: loops on "press ENTER", FIDO_ERR_PIN_REQUIRED in passkey_child.log

Environment:

• Rocky Linux 10
• sssd-2.11.1-2.el10_1.1
• ipa client 4.12.2
• libfido2 1.14.0

[ikerexxe]

Hi @romeo-am,

Thanks for reporting this! I've been trying to reproduce the issue on a CentOS Stream 10 system using a YubiKey Bio Series with the fingerprint enabled (which should behave similarly to your Token2 Bio3), but so far I haven't been able to replicate the exact looping behavior.

Environment

• OS: CentOS Stream 10
• sssd-2.12.0-3.el10.x86_64
• ipa-client-4.13.1-3.el10.2.x86_64
• libfido2-1.14.0-7.el10.x86_64

Description

The key has user-verification enabled (alwaysUv is active):

$ fido2-token -I /dev/hidraw7
...
options: rk, up, uv, noplat, uvToken, alwaysUv, credMgmt, authnrCfg, bioEnroll, clientPin, largeBlobs, pinUvAuthToken, setMinPINLength, nomakeCredUvNotRqd, credentialMgmtPreview, userVerificationMgmtPreview
...

I created the user and disabled user verification on the FreeIPA side:

$ ipa passkeyconfig-mod --require-user-verification=False
Require user verification: False

When testing a failed or skipped fingerprint match, instead of hitting a prompt loop or logging FIDO_ERR_PIN_REQUIRED, my setup immediately drops to an authentication failure:

$ su - iker@ipa.test
Insert your passkey device, then press ENTER.
<- Finger reading request and I touch with the "wrong" finger
su: Authentication failure

Since I don't have the exact token model you're using, it would be incredibly helpful if we could narrow down whether this is a version-specific issue or a wider logic gap:

1. Update SSSD: would you mind updating your environment to a more recent version (such as sssd-2.12.x) if possible, to see if the looping behavior persists?
2. SSSD debug logs: if it still fails on the newer version, could you capture the debug logs from the PAM responder? You can set debug_level = 9 in the [pam] and your [domain] sections of /etc/sssd/sssd.conf, reproduce the failure, and attach the log snippets. If you don't want to share them publicly you can email them to ipedrosa@redhat.com.

[romeo-am]

Bit of a clarification on the original report, plus newer logs.

Ignore the "looping" that was me testing with sudo true, which was just retrying a few
times. Switched to su - for this run and it's a single clean dropout, same underlying
thing.

Setup is the same: UV off in IPA but alwaysUv=true on the key, so it goes straight to
fingerprint instead of asking for a PIN. That's deliberate and it works fine when the
fingerprint reads. When it doesn't, the device returns FIDO_ERR_PIN_REQUIRED but SSSD
doesn't fall back to a PIN prompt and I can't get through to try the password either when I am connected to a remote box for example.

Updated to the nightly like you suggested:

• sssd-2.14.0-0.260609.151702.git817b00258.el10.x86_64
• libfido2-1.14.0-7.el10.x86_64

alternate@gold:~$ su - romeo
Insert your passkey device, then press ENTER.
su: Authentication failure

Full debug_level=9 logs from the PAM responder and passkey_child attached, single su -
attempt. Still the same line:

[passkey_child] [request_assert] (0x0040): fido_dev_get_assert failed [54]: FIDO_ERR_PIN_REQUIRED.

Which I believe should trigger a PIN prompt rather than an auth failure. Ideally it would be possible to know if the key can provide it's own UV?

passkey_child(1).log
sssd_pam(1).log

[ikerexxe]

Hi @romeo-am,

Thanks for providing the clean su - logs and clearing up the looping behavior. That makes the current state of things much clearer.

You are exactly right about what should happen ideally: a graceful fallback to a PIN prompt when biometrics fail. To understand why this isn't happening today, it helps to look at how SSSD splits responsibilities between its internal processes.

Why this happens

SSSD uses a decoupled responder-helper architecture for passkey authentication, splitting the work between the PAM responder (sssd_pam) and a dedicated helper process (passkey_child).

The core issue is that the communication between these two processes is linear and unidirectional. sssd_pam passes the execution parameters to passkey_child at startup and waits for a final success or failure exit code.

When your FIDO2 key enforces its hardware-level alwaysUv=true constraint and the fingerprint fails or is skipped, the device naturally drops back to demanding a PIN (FIDO_ERR_PIN_REQUIRED). However, because passkey_child is completely isolated from the active PAM conversation context, it cannot dynamically halt execution, message sssd_pam to prompt you for a PIN, and inject that PIN back into the ongoing FIDO2 session. Because it lacks this interactive feedback loop, passkey_child hits a dead end, logs the error, and exits with a failure state, causing SSSD to drop the authentication attempt entirely.

Future improvements

We are actively working on an enhancement that introduces a pre-flight check with the FIDO2 device before requesting the assertion data. This will allow passkey_child to probe the token's capabilities and constraints upfront, report them deterministically back to sssd_pam before the main assertion loop begins, and allow the responder to correctly drive conversational prompts (like falling back to a PIN). Because this requires a significant refactor of the communication flow and state management between SSSD processes, it is taking some time to implement.

Recommended workaround

In the meantime, the best way forward is to align your centralized FreeIPA policy with your hardware token's configuration.

I highly recommend enabling user verification on the FreeIPA side to match your key:

ipa passkeyconfig-mod --require-user-verification=True

By setting this to True, sssd_pam will explicitly expect the user verification flow from the very beginning, safely collecting the PIN upfront via PAM before calling passkey_child. This resolves the structural logic gap and aligns with security best practices by enforcing a consistent two-factor verification standard.