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,
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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,
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev