kanidm_unixd: Support PAM authentication via FIDO2/WebAuthn/"Passkeys"

[JJGadgets]

Is your feature request related to a problem? Please describe.

Currently, my understanding is that kanidm_unixd only supports passwords for PAM authentication, and not FIDO2/WebAuthn/"Passkeys".

Describe the solution you'd like

FIDO2 as PAM authentication is shown to be possible as shown by pam_u2f.so (https://github.com/Yubico/pam-u2f), and the FIDO2 enrollment simply stores the FIDO2 challenge data to ~/.config/Yubico/u2f_keys or user-defined location of authfile.

I think it would be nice if kanidm_unixd could also support FIDO2 PAM authentication in its own PAM module, and if a user has both supported passkeys (e.g. YubiKeys and not iOS-only) and password enabled, allow a PAM variable to either prompt or choose which is preferred.

Describe alternatives you've considered

Alternatively, kanidm_unixd could "sync" or at least provide the FIDO2 challenge data stored within Kanidm's database to the enrolled Linux machine running pam_u2f.so so the authfile can be pointed to the kanidm_unixd "synced" file.

Additional context

Currently, all my personal Linux workstations (not my personal servers) use YubiKeys in passwordless FIDO2 mode for PAM authentication including PIN verification. Since Kanidm is embracing passwordless FIDO2 as a valid and preferred authentication method, I think this feature would be nice to round out the "passwordless-FIDO2-first" authentication provider experience.

[Firstyear]

I agree that this would be a good enhancement - I've been recently thinking about it too. So far we haven't had many other users with linux desktop machines which is probably why this hadn't been done sooner.

The main things would be:

• The pam module has to detect correctly if the user is at a local or remote session type to offer the correct auth methods - you can't do webauthn over ssh!
• We need to have a way to mark passkeys/credentials as unix auth capable - this way their public keys are added to the unix user token record for caching on the machine (for when you are out and about). As you correctly identify, iOS credentials can't be used for this without something like caBLE support.
• We need to probably alter the pam to unixd communication format to allow the pam module itself to interact with the usb device, since the unixd daemon is isolated away from the seat/session. That means we'd need some extra parts to correctly do this since the current pam code is assuming a certain workflow.

[leoleoasd]

And this is another usecase of #1703: We can do webauthn on remote machines via one-time-link.

[Firstyear]

And this is another usecase of #1703: We can do webauthn on remote machines via one-time-link.

Not really. This is for CTAP2 on a local machine where you might need offline authentication. Imagine a laptop with no internet and you want to auth with a security key.

Anyway, some of the values here may be helpful to determine local vs remote session setup, which is critical for us to resolve this issue.

https://github.com/systemd/systemd/blob/main/src/login/pam_systemd.c#L853

[kenjitamura]

Describe alternatives you've considered

Alternatively, kanidm_unixd could "sync" or at least provide the FIDO2 challenge data stored within Kanidm's database to the enrolled Linux machine running pam_u2f.so so the authfile can be pointed to the kanidm_unixd "synced" file.

I see that sssd implemented passkey support earlier this year. If the second option is considered could an implementation like theirs be used where the mapping data is exposed as an ldap attribute?

https://sssd.io/release-notes/sssd-2.9.0.html https://sssd.io/release-notes/sssd-2.9.2.html

[Firstyear]

IIRC it's not actually doing passkeys/CTAP2 locally, it pops a qr code to scan to go to an oauth2 portal. It's passkey storage also is extremely primitive compared to ours.

I'd rather not imitate anything about how SSSD/IPA do this, because they are significantly behind us in their passkey support.

[Firstyear]

@kenjitamura Also another issue here is we don't have a way in pam via something like sudo to distinguish local user vs remote an ssh, so we don't actually know properly if we can proceed with ctap2 or not. We need to actually have that solved for a good user experience.

[kenjitamura]

Thank you for the response!

I think since they've pulled in libfido2 as a dependency they've offloaded the CTAP2 handling to it or at least in the blog post write up I found there isn't mention of the need for an oauth2 portal during the setup. But maybe they just left it off in their steps:
https://fedoraproject.org/wiki/Changes/Passkey_authentication_centrally_managed_users#How_To_Test

It looks like for the sudo problem, with FreeIPA specifically, they had this to say:

FreeIPA extension to issue Kerberos tickets based on the passkey authentication allows to solve usability issues in accessing network resources in a passwordless way. This extension also provides Kerberos authentication indicator support, making passkey authentication visible to Kerberos services. This can be used, for example, for passwordless SUDO access with pam_sss_gss module when a Kerberos ticket was obtained with a specific (passkey) authentication mechanism.

Which I guess just sounds like if the authentication succeeds with a passkey it's automatically backed by kerberos and pulls in the module they have to facilitate passwordless sudo?

Unfortunately a lot of this is over my head and it's probably something you've already seen.

https://ikerexxe.github.io/idm/2022/12/19/passkey-central-auth.html https://fedoraproject.org/wiki/Changes/Passkey_authentication_centrally_managed_users#Benefit_to_Fedora

[yaleman]

Thank you for the response!

I think since they've pulled in libfido2 as a dependency they've offloaded the CTAP2 handling to it or at least in the blog post write up I found there isn't mention of the need for an oauth2 portal during the setup. But maybe they just left it off in their steps: https://fedoraproject.org/wiki/Changes/Passkey_authentication_centrally_managed_users#How_To_Test

This describes using a locally connected Passkey (as in a physical token), which won't work for SSH-connected users - which is central to our problem - PAM can't tell the difference between a local user and an SSH-connected so you'd end up locking users out of remote authentication.