openssh unix dev - Oct 2020 - FIDO Flags and some other changes

Hello,
I just want to share my ideas about few things related to fido keys:



   1. Right now, we specify flags like "no-touch-required" and
   "verify-required" during key generation, but I think this
information
   should not be attached to keys at generation times, especially because
   servers most accept our keys based on their configurations: for example,
   one server may have "no-touch-required" on it's
"authorized_key" file and
   another one doesn't. But we cannot change "no-touch-required"
on every
   login since it's permanently attached to its private key. Also, keys
   created with "verify-required" need to have
"verify_required" on the server
   config or they will be rejected, and if we add "verify-required" to
keys
   which do not have this flag, they'll become useless. My purpose is, these
   options should be configured on ssh configs, so for each server, we can
   specify them as it should be(or select a default with "Host *").
What do
   you think?
   2. Another thing I wanted to share is, with "verify-required", you
ask
   for the pin before starting sk module, I think it's not a good idea since
   some modules do not read pin (for example mine, which is using Windows
   Hello, and it needs to ask for the pin on it's UI) And in future, when
you
   want to add support for biometric verification, this should be changed.
   3. "-O user" option only set key_id in sk-usbhid.c, you hardcoded
name
   and display_name to "openssh", this can make key management hard,
most of
   key managers app(like YubiKey manager) only shows the name of the resident
   key, and refuse to delete keys when there are two with the same name, an
   easy fix is to set name and display name to the one requested in
"user"
   option (and fallback to "openssh" when the user is not configuring
any name
   since they can't be empty)
   4. In the next version of libfido2, a new function named
   fido_cred_authdata_raw_ptr will be added which is same as
   fido_cred_authdata_ptr but its output is not CBOR encoded. I think it's a
   better fit for storing attested data.


Thanks for reading this.
Regards,

>   1. Right now, we specify flags like "no-touch-required" and
>   "verify-required" during key generation, but I think this
information
>   should not be attached to keys at generation times, especially because
>   servers most accept our keys based on their configurations: for example,
>   one server may have "no-touch-required" on it's
"authorized_key" file and
>   another one doesn't. But we cannot change
"no-touch-required" on every
>   login since it's permanently attached to its private key. Also, keys
>   created with "verify-required" need to have
"verify_required" on the server
>   config or they will be rejected, and if we add
"verify-required" to keys
>   which do not have this flag, they'll become useless. My purpose is,
these
>   options should be configured on ssh configs, so for each server, we can
>   specify them as it should be(or select a default with "Host
*"). What do
>   you think?
Defining these attributes during key generation allows the 
corresponding policy to be enforced at the authenticator level 
(through FIDO 2.1 credential protection, which is the intention), 
and subsequent notarisation by a CA.

Keys created with verify-required do not require verify-required to 
be set on the server. In FIDO2, the entity that ultimately decides 
how a signature takes place is the authenticator. The verifying part 
is of course expected to validate and reject signatures that do not 
satisfy its security requirements, but should accomodate signatures 
that exceed said requirements:

"(...) the Authenticator may perform user verification even if 
not requested to enhance its security offering." [1]

-p.

[1]
https://fidoalliance.org/specs/fido2/fido-client-to-authenticator-protocol-v2.1-rd-20191217.html