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. 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. [1] https://github.com/trezor/trezor-firmware/issues/877#issuecomment-2573760523 -- Best Regards / S pozdravom, Pavol "Stick" Rusnak Co-Founder, SatoshiLabs
Pavol Rusnak via openssh-unix-dev:> 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. This way FIDO authenticators wouldn't even need to > support resident credentials to function with OpenSSH.They don't need to support resident credentials. OpenSSH's FIDO support is fundamentally based on U2F aka FIDO1, which doesn't even feature resident keys. The U2F/FIDO key handle is placed in id_ecdsa_sk. That provides a very useful property: If an attacker steals my authenticator, they still cannot log into my accounts because they lack id_ecdsa_sk. Note that U2F was conceived as a second factor in a 2FA scheme. If you allow a login simply with the FIDO credential, you're back to a single factor. By moving the key handle into the SSH private key, OpenSSH splits this into two again: (1) possession of the authenticator and (2) possession of the SSH private key (= FIDO key handle). Any old U2F authenticator can be used with OpenSSH's U2F/FIDO support. You only need FIDO2 for the _additional_ features of ED25519 and resident keys...> 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 use case for supporting FIDO2 residential keys appears to be that you can use ssh on a machine which does not already have a copy of id_ecdsa_sk, say, in a corporate network. You can use ssh-add -K to download the FIDO key handle from the authenticator. Note that the authenticator will only allow this after the user has entered a PIN or a fingerprint etc. to confirm their identity to the authenticator, so again a simple theft of the authenticator does not provide an attacker with access. IIRC, the principal difference between CTAP 2.0 and 2.1 is that 2.1 allows the deletion of individual keys, whereas 2.0 only provides a reset of the authenticator that deletes all keys. That's an issue when the authenticator's storage capacity has been exhausted, but it has nothing to do with OpenSSH. -- Christian "naddy" Weisgerber naddy at mips.inka.de
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