[Bug 3517] New: ssh-keygen sk fido keys with attestation do not indicate user verification state.

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3517

            Bug ID: 3517
           Summary: ssh-keygen sk fido keys with attestation do not
                    indicate user verification state.
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: william.brown at suse.com

In the current format of the attestation that ssh-keygen creates for
fido2 credentials it is unclear if userverification / credprotect were
enabled on the private/publickey that were created. This is an
important and useful signal for ssh-servers to understand the nature of
the key that was used for authentication. 

The attest format should be altered to include the requested
userVerification and credprotect state that were requested at
credential creation time. For a stronger assertion of this, these data
could be part of the collected client data, and the collected client
data becomes part of the attest blob (see also
https://bugzilla.mindrot.org/show_bug.cgi?id=3516 where it is described
why ccd is required in the attest blob ssh-keygen produces) 

Note it is not possible for the RP (server) to rely on the state of the
userverification bit in attested credential data as ctap2.1 forces
uv=true on all credentials during creation, even if uv=discouraged were
sent to the device during the make credential operation. It is required
for the server to see "what flags" were also sent to the device for
creation.

In a similar vein, it may also be prudent to add the residentKey
boolean to the ccd so that a server can verify if an rk was created or
not.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.