Question about webauthn signatures?

[Tyson Whitehead]

On 5/6/21 10:41 PM, Damien Miller wrote:
> I do have vague plans to do a more web-like FIDO authentication method
> for OpenSSH in the future, but haven't got around to it yet.

This is very good news!  :)

> (this message number was defined for GSS authentication, w/
> SSH_MSG_USERAUTH_INFO_REQUEST always going in the s->c direction and
> SSH_MSG_USERAUTH_INFO_RESPONSE always going c->s).
> 
> where each key_info member contains
> 
> string		pkblob
> string		key handle
> uint8		flags
> string		reserved

This all seems really good to me. I'm guessing, however, you meant to have "key handle" and "flags" reversed here to match the private key layout you defined.

> Perhaps authorized_keys entries like
> 
> fido[,option...] sk-ecdsa-sha2-nistp256 at openssh.com pubkeyblob keyhandleblob
> 
> flags would be reconstructed from the options listed on the key:
> no-touch-required, verify-required, etc.
> 
> Another alternative would be to define a pubkey blob format that includes
> all the information. Not sure which is nicer...

I'm not expert, but I would probably lean towards maintaining the "options, keytype, base64-encode, key, comment" format of the authorized_keys file by combining the pubkey and keyhandle blob as currently is done in the private key format.

The user clearly isn't going to want to mix and match different pubkeyblobs and keyhandleblobs, the only real purpose of letting them specify both is to make it so they can optionally not include the keyhandleblob.

So, perhaps, the authorized_keys "sk-ecdsa-sha2-nistp256 at openssh.com" keytype could be for either a base64 encoded sk-* public or private key. The private key starts with the public key, so decoding would just be a matter of continue on decoding the private bit if there is still stuff left over after the public bit is done.

I guess this doesn't make it so obvious to the user how to distinguish the two though, so maybe a new authorized_keys "skc-ecdsa-sha2-nistp256 at openssh.com" (security key combined?) keytype  would be better to use to explicitly distinguish whether it is a base64 encoded sk-* public or private key for the user?

A third option would be to just make it so you can specify the key handle in base64 as one of the options. A bit ugly due to being on the long side for an option, but maybe the most in keeping with the spirit of the authorized_keys file format?

key-handle=MDAwMDAwMDA6IDViIDFlIGJjIDNmIDMyIGIwIDg4IDFjIGI3IDBiIGI3IGFiIGNjIDA4IDY0IDkwCjAwMDAwMDEwOiBiZiA1OSBjYSBiOSBkZCAzZSAyMiA3OCBiYyAyNyAyOCBmMSA3ZSA2NiBjMiBhYQowMDAwMDAyMDogY2UgYzUgYjYgYzkgYzAgZGUgMzkgNzQgMjAgMDMgNjUgYzkgNTggZmQgZDAgZGYKMDAwMDAwMzA6IDc0IDRiIDE3IGM1IDRkIDE5IDNmIGI0IDQ1IGIxIDhkIGY0IGU0IGQ1IGU2IDg5Cg== sk-ecdsa-sha2-nistp256 at openssh.com pubkeyblob comment

Anyway, really excited to hear that you have been thinking about these things! Thanks for letting us in on your thoughts. Looking forward to whatever comes of it.

Cheers!  -Tyson