Accept scoped PIN tokens for credential management #80
Assignees
Comments
6 tasks
robin-nitrokey
added a commit
that referenced
this issue
May 23, 2024
As described in #80, we currently require PIN tokens without an RP ID restriction for all credential management operations. For most operations, this is correct. For EnumerateCredentialsBegin, we should also accept a token that matches the requested RP ID hash. For DeleteCredential and UpdateUserInformation, we should also accept a token that matches the requested credential ID. As it is not trivial to compare the RP ID hash or the credential ID against the RP ID set for the PIN token, I did not handle these cases in the initial implementation. This led to an incompatibility with libfido2 because it tries to use a restricted PIN token to enumerate credentials. With this patch, we additionally compute the RP ID hash when restricting a PIN token to an RP ID and use that to validate the PIN token for EnumerateCredentialsBegin operations. For DeleteCredential and UpdateUserInformation, we still require tokens without an RP ID restriction because determining the RP ID from the credential ID is much harder and this is not known to cause incompatibility issues. See also: #80
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For the credential management subcommands
EnumerateCredentialsBeginandDeleteCredential, we should also accept PIN tokens that are restricted to the corresponding RP.Original report: Nitrokey/nitrokey-3-firmware#496
Affected subcommands:
The text was updated successfully, but these errors were encountered: