Another U2F documentation issue

[Ron Frederick]

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