On Mon, 6 Jan 2025, Pavol Rusnak via openssh-unix-dev wrote: > Hello list! > > Recently, there was a request to implement CTAP 2.1 resident credential > management to Trezor, a hardware wallet which already supports FIDO2 > authentication (full CTAP 2.0). > > My colleague Andrew[1] raised some points on GitHub and I'd like to check > with you what are we missing or whether Andrew is right. > > Thank you for your help and understanding! > > Quoting from [1]: > > It really makes no sense to me why credential management is needed by > OpenSSH in the first place. In fact it doesn't even make sense to me why > resident credentials are needed by OpenSSH. Firstly, the private key file > `id_ed25519_sk` contains primarily the FIDO credential, which is nothing > secret and should logically be placed in `id_ed25519_sk.pub` which resides > on the remote server. It's done this way to allow FIDO keys to work along other key types in the SSH protocol without requiring a whole new authentication subprotocol just for FIDO keys, which would be needed to communicate the key handle from the server back to the client - no such ability exists in the existing SSH publickey authentication subprotocol. This was a deliberate tradeoff we made when integrating FIDO keys into SSH: making the integration more SSH-like (dramatically lowering the costs for other SSH server vendors to add authentication-only FIDO support) vs making it more web-like (lowering the costs of of implementing the client side of generating assertions). > This way FIDO authenticators wouldn't even need to > support resident credentials to function with OpenSSH. Secondly, assuming > that there is some kind of rational reason not to place the FIDO credential > into `id_ed25519_sk.pub`, credential management commands should still not > be needed. I see no justifiable reason why to load resident keys from a > FIDO authenticator to the SSH client computer, which is what `ssh-add -K` > does. The normal way to work with resident credentials is to specify the RP > ID `ssh:` in the authentication request to the authenticator. This all > works well with CTAP 2.0. First, the client doesn't a priori know which RPID to use, it might be something other than "ssh:". That's one of the reasons why we store it in the pub/privkey file. How does a user of a RK-capable token get this information from a token? For OpenSSH, we implemented it as `ssh-add -K` I have no idea whether invoking keys by RPID alone works with other RK-supporting FIDO 2 tokens, we've always provided the key handle + RPID and no other FIDO 2 token vendor that I'm aware of has had trouble with this. Anyway, it's totally up to Trezor whether they want to be compatible with this relatively-niche feature, but I don't plan on spending any development cycles on it for the sake of a single vendor. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
