openssh unix dev - Nov 2019 - U2F support in OpenSSH HEAD

I've had a patch on the bugzilla for a while related to U2F with
support for a few additional settings such as providing a path to a
specific key to use instead of the first one found and setting if user
presence is required when using the key. Is there any objection to
folding those parts in if appropriate?

Joseph, to offer comment on NIST P-256. There was originally quite a
limited subset of support in U2F, originally ES256 or RS256. There's
since been more added (Ed25519 appears to be one of them at a cursory
glance). If you take a look at param.h in the libfido2 repository
you'll see the list of supported algorithm constants (COSE_*). From
personal experience though I've had a few different brands of
pure-u2f-only tokens and never seen support for anything other than
P-256 in the wild. Yubicos U2F only keys for example are currently
listed on their site as only having P-256 support. I imagine
multi-purpose keys might have more expansive support though. RS256
also appears to be marked as deprecated.

On Sat, Nov 2, 2019 at 7:54 PM Joseph S. Testa II
<jtesta at positronsecurity.com> wrote:
>
> On 11/1/19 4:36 AM, Damien Miller wrote:
> >  new key type "sk-ecdsa-sha2-nistp256 at openssh.com"
>
> Was ECDSA with NIST P-256 strictly necessary, or would Ed25519 be
> possible as well?
>
>     Thanks,
>     - Joe
>
> --
> Joseph S. Testa II
> Founder & Principal Security Consultant
> Positron Security
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 2 Nov 2019, Jordan J wrote:
> I've had a patch on the bugzilla for a while related to U2F with
> support for a few additional settings such as providing a path to a
> specific key to use instead of the first one found
This would need to be implemented in the middleware library, either
the one in libfido/tools/sk-libfido2.c or another.
> and setting if user
> presence is required when using the key. Is there any objection to
> folding those parts in if appropriate?
That's possible already: at keygen time, the default is to require
user presence for signatures but you can overide this by passing the
"-x 0" flag. This is currently undocumented, and I'll hopefully
soon
get around to documenting it and making it accept mnemonic string
instead of raw U2F flags.

At authentication time, I've got a patch almost ready to require
user presence that I hope to commit next week.

-d

> That's possible already: at keygen time, the default is to require
> user presence for signatures but you can overide this by passing the
> "-x 0" flag. This is currently undocumented, and I'll
hopefully soon
> get around to documenting it and making it accept mnemonic string
> instead of raw U2F flags.
I can make a quick pull request to update it to be a mnemonic if
you're interested. I'm looking around and testing the U2F support at
the moment anyway.