Another U2F documentation issue

Ron Frederick
2019-12-07T18:54:10Z

Hello,

I forgot to mention one other issue in my previous e-mail about the ssh-agent
documentation for U2F keys. Right now,
https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.u2f
<https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.u2f>
has the following text:
> ssh-agent requires a protocol extension to support U2F keys. At
> present the closest analogue to Security Keys in ssh-agent are PKCS#11
> tokens, insofar as they require a middleware library to communicate with
> the device that holds the keys. Unfortunately, the protocol message used
> to add PKCS#11 keys to ssh-agent does not include any way to send the
> key handle to the agent as U2F keys require.
However, the extension described there has nothing to do with sending the key
handle. In fact, all of the necessary fields (public key, application, flags,
and key_handle) are all already encoded in the private key blob (and appended to
the certificate blob when certificates are being imported). The extension only
communicates the path to the middleware library to use, not the additional key
information such as the key handle.

If you had ssh-agent pick up the location of the middleware library when the
ssh-agent was started (from the environment and/or a command-line option), you
wouldn?t actually need clients talking to the agent to use ADD_ID_CONSTRAINED
when sending requests. Alternately, if you want clients to be able to set this
library on a per-request basis, you could support the proposed constraint for
this purpose but fall back to the provider set when ssh-agent started up and/or
to the ?internal? provider that OpenSSH has built-in, avoiding the need for
either the agent client or the agent itself to have to specify anything to get
SK keys to work in the common case. An unmodified client sending a normal
ADD_IDENTITY request would work just fine in this case, as long as it sent the
new SK format private key blob.

As an aside, I also noticed that sending the new constraint when importing
non-SK keys seems to cause the add operation to fail. That?s easy enough to
prevent in the client code, but the code would be simpler if it was always safe
to add the extension (when a middleware path was available) regardless of the
type of key being added.
--
Ron Frederick
ronf at timeheart.net