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