openssh bugs - Nov 2022 - [Bug 3498] New: Support for unlocking keys with more than one FIDO/WebAuthn token

https://bugzilla.mindrot.org/show_bug.cgi?id=3498

            Bug ID: 3498
           Summary: Support for unlocking keys with more than one
                    FIDO/WebAuthn token
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Smartcard
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bugzilla.mindrot at me.benboeckel.net

I'd like to be able to have a single key be unlocked by multiple
FIDO/WebAuthn tokens instead of having one-to-one. The problem is that
I juggle dozens of keys (I prefer one key per "service"; $DAYJOB also
has a setup where keys get access to specific resources using
rrsync[1], so a key-per-resource is required) as it is and having to
double (or triple) it for robust backups feels excessive.

Specifically, what would be nice-to-have:

- support for multiple FIDO/WebAuthn tokens to be able to unlock a
private key
- ability to add a new token to be able to unlock an existing private
key
- the public key should not know/care about which token unlocked the
private key (i.e., should not change after adding a token)

I don't think this supports the mechanism where part of the private key
is stored on the token itself; I think that's fine as now to support
the second point is really questionable if part of the key is
token-locked.

[1] https://download.samba.org/pub/rsync/rrsync.1

(I tried searching for existing issues, but I just get errors about
malformed redirects.)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3498

Ben Boeckel <bugzilla.mindrot at me.benboeckel.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla.mindrot at me.benboec
                   |                            |kel.net

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3498

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
It sounds like you're after something like Passkeys
(https://fidoalliance.org/passkeys/) - I have no idea whether these
will work with OpenSSH or whether modifications will be required.

Putting Passkeys aside, there is no trivial way to do what what you
want. Private keys are fundamentally device-linked in the FIDO model,
so you could no longer rely on their notion of keys directly.

It might be possible to rig something up using the FIDO2 hmac-secret
extension
(https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#sctn-hmac-secret-extension),
which can let you exchange a key handle for a durable symmetric key.

Maybe it would be possible to rig up some multi-key encryption scheme
that uses these keys to decrypt the actual private key material.
However, it isn't clear whether this would yield a more convenient
workflow than managing separate FIDO keys. Also, you'd be giving up
most of the benefit of hardware tokens as the actual key material would
be decrypted on the host and not the token.

Another non-FIDO approach would be to buy FIDO keys that also support
PIV or some other standard that allows key access via PKCS#11, and load
the same key onto multiple tokens (rather than having the token
generate the keys). This gets you proper hardware backing for the keys
(so long as you didn't leak it when generating and loading it), but you
would be dealing it the messiness of PKCS#11...

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3498

--- Comment #2 from Ben Boeckel <bugzilla.mindrot at me.benboeckel.net>
---
Thank you for the information. This makes sense; I'll put my hopes into
(evolution of?) Passkeys then. Hopefully we also get support that
doesn't rely on trillion-dollar companies too?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3498

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |LATER
             Status|NEW                         |RESOLVED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3498

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
OpenSSH 9.3 has been released. Close resolved bugs

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.