Re: Extension Idea: Support for SSH and Other Arbitrary Signed Challenges

On Wed, May 16, 2018 at 11:18 PM David Strauss <david@davidstrauss.net>
wrote:

> I started a proof-of-concept SSH agent backed by a FIDO token. This mostly
> went well: I use the "registration" process to generate a keypair, extract
> the curve points, and even encode them for an SSH-format ECDSA key.
>
> Things break down for signing the challenges, though. FIDO2 supports the
> necessary algorithms and hashes, but the tokens always prefix challenges
> with a counter, a small bitfield, and other data before signing [1], making
> the signature unusable for any API that can't accommodate the signer adding
> a prefix on the challenge.
>
> SSH uses its own system of nonces that operates outside the signing API
> (in the form of session IDs) [2]. Consequently, the SSH agent protocol
> doesn't support the signer adding a prefix to the challenge before signing,
> at least for ECDSA keys [3]. It would be possible to extend the SSH server
> and client to support including prefix data in signatures, but that would
> probably take 10+ years to roll out to a critical mass of servers and
> clients. Similar problems exist for supporting X.509 and GPG signing
> requirements.
>
> Proposed Extensions
>
> We should consider adding a FIDO extension for both registration and
> authentication to support "raw signing" of bytes with no prefixing or other
> alteration.. To avoid risk to the primary signing functionality (e.g.
> replay attacks or faking the existence of a clone), it could use a
> different keypair than the main one for the RP+user. Use of a different
> keypair would be why we would also need a registration extension: a
> different public key necessitates a way to obtain that public key.
>
> The protocol for the extensions would be straightforward. The registration
> extension would return the second, raw-signing public key for the RP+user.
> The authentication extension would return the challenge as signed by the
> second, raw-signing private key without alteration. Neither would require
> any request parameters (beyond those mandated in the FIDO2 spec).
>
> This would allow major smart card-compatible APIs to support -- with
> client-side changes alone -- what I hope will become the most widely
> accessible and inexpensive smart card framework on the market.
>

Some CTAP1 devices also support being an SSH agent already. Presumably
future some CTAP2 devices will support that too.

But I don't believe that it's an issue for the Web Authentication group.

It *might* be something that FIDO would take up as an extension to CTAP2 to
allow devices to reuse their CTAP2 interface for supporting SSH, but that
would be their call.


Cheers

AGL