On 5/6/21 2:02 AM, Damien Miller wrote:
On Wed, 5 May 2021, Tyson Whitehead wrote: Without knowing your needs I can't really say whether it would be useful to you :)
Sorry if I wasn't clear here. I was just meaning I wanted to understand in case, upon doing so, I would see a use case. The background would be that I work for one of the members of the Canadian academic super computing consortium Compute Canada. We have a very large user base across Canada (free accounts for all Canadian researchers and their students) with a wide range of computing experience. When we have been compromised, it has been by local privilege escalation from a user account compromised elsewhere. Ideally we would like to help our users avoid their accounts being compromised without raising any usability hurtles to our many non-unix-savvy users.
The webauthn signature type (note: note a key type) was added to support browser-based SSH clients that can only interact with FIDO keys via the webauthn APIs. These APIs do not allow "bare" FIDO signatures, but implictly include weborigin information in the signed data.
Thank you for the clarification. I believe I understand now it is for the signature in the SSH_MSG_USERAUTH_REQUEST when the client only has access to the device via the webauthn API. That makes sense. Many of our non-unix savvy users just use passwords as settings up keys is difficult for them. From reading up on the FIDO2 standard, it would seem that it should be possible to just have server-side FIDO2 keys. This could be a huge plus as we could generate and register these keys on our clusters for them off our website. They could just use them without having to setup anything on their end. I was looking at RFC4252 (The SSH Authentication Protocol) to see if FIDO2-based server-side could be retrofitted into the SSH protocol, and it seemed to me like it could be done. Specifically, the "publickey" authentication protocol has the client send byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding string service name in US-ASCII string "publickey" boolean FALSE string public key algorithm name string public key blob and the server respond with byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request so I am thinking it could be (slightly) abused by 1. creating a another esk-ecdsa key type where the key handle was stored with the public key 2. have the client pass an empty "public key blob" when sending the SSH_MSG_USERAUTH_REQUEST message for this key type 3. have the server respond back with the key handle (or the entire public key with the key handle) in the "public key blob" of its SSH_MSG_USERAUTH_PK_OK response Support for multiple keys could be done by having repeated queries return subsequent ones. The server could also reply with fakes to avoid leaking information about whether any such keys actually exist.
The only thing that AFAIK uses it is the test Javascript that I wrote: regress/unittests/sshsig/webauthn.html in the source distribution. If you stick it on a web server then you can generate FIDO keys and webauthn signatures that you can verify using ssh-keygen -Y. It's the basis of the webauthn signature unit tests.
Very interesting. I added a bit on top of your javascript to also export the private key to see if we could do the key generation sever side in order to make things easier for our non-unix-savvy users https://staff.sharcnet.ca/tyson/webauthnkey.html The resulting keys seem to work fine in SSH, which makes me think, if SSH could support pure server-side key, and we could generate these keys with Webauthn, it would actually make things even easier for our non-unix-savvy users (buy a key, press a button on our website to register it) while really tightening up user accounts and thereby decreasing the attack vectors against us. Would love to hear your thoughts on it. Thanks! -Tyson _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
