On Sat, 7 Dec 2019, Ron Frederick wrote: > 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 > 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. That text explains why it was not possible to use the PKCS#11 token- related messages that already exist in the ssh-agent protocol. > 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. It was a goal to support multiple providers concurrently, e.g. a user who has some keys on a USB security key and others on a BLE one. > 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. I don't think providing that sort of backwards compatibility buys anything because both the agent and the client need to support the security key formats anyway. > 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. IMO it doesn't generally make sense for the agent to be liberal in what it accepts :) -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
