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@xxxxxxxxxxx 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@xxxxxxxxxxx" 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@xxxxxxxxxxx" (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@xxxxxxxxxxx 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
