pam-u2f should avoid requesting PINs multiple times for the same device

[fergus-dall]

I've discovered that when using resident keys the pam module skips trying to match keys with authenticator devices and just tries every key against every device, asking for a PIN each time, until one matches. I assume this is because listing resident keys requires a PIN anyway, but it's not a great experience, especially when using a GUI login interface where it is hard to tell if a message is repeated.

(I'm not sure why matching non-resident keys doesn't require a PIN and touch though)

At a minimum, we could cache the PIN for each device and avoid needing to query it again. Going a bit further, we could use the credential management API to determine if any resident keys match without needing the user to touch the authenticator for each key checked, for authenticators that support this.

Assuming I understand this right, I think the best order to search is:

• All non-resident keys against all authenticators (can be checked for presence without user interaction)
• Check each FIDO2 device that supports credential management, one device at a time against all resident keys
• Finally, check all resident keys against all remaining FIDO2 devices

[fergus-dall]

Okay, having actual read the spec now:

• If up is false, we never require user verification to generate an assertion, even if alwaysUv is true
• However discoverable credentials can have a credential protection policy which also limits when they can be used
  • If a credential is userVerificationOptional it can be detected without user verification
  • If it's userVerificationOptionalWithCredentialIDList is can be detected without user verification if we know the credentialId
  • If it's userVerificationRequired we need user verification always.
• If a credential is non-discoverable, we can only discover it by listing it in allowList
  • It is unclear to me if these can also be subject to credential protection. 6.1.3. Discoverable credentials contrasts discoverable credentials with a credential protection policy with non-discoverable credentials, but nothing explicitly states that a policy of userVerificationRequired should be rejected for non-discoverable credentials, and it could be persisted in the returned credentialId along with the wrapped private seed.
• Non-discoverable credentials must be listed in allowList, but discoverable credentials that we don't know the credentialId for can only be discovered if allowList is absent.

Therefore, to cover all the cases, I think we have to do:

• For each authenticator
  • Check if we can get an assertion with no allowList
  • Check if we can get an assertion with allowList containing all known credentialIds
  • If we found a credential, break
• For each authenticator
  • Perform user verification
  • Repeat the previous checks
  • If we found a credential, break
• If we stopped because we found a credential
  • If we need user verification in the real assertion and haven't yet, do it now
  • Assert the discovered credential for real

Only the last step actually consumes a user verification, so this should only require doing user verification at most once per authenticator, and doing user presence at most once overall.

Also, if possible, pamu2fcfg should output credentialId for discoverable credentials. While it isn't required to use them, we do actually know which user we're authenticating, so we can list all valid credentials and it lets us possibly skip user verifications if the credential is protected with userVerificationOptionalWithCredentialIDList.