[BACK]Return to PROTOCOL.u2f CVS log [TXT][DIR] Up to [local] / src / usr.bin / ssh

Diff for /src/usr.bin/ssh/PROTOCOL.u2f between version 1.1 and 1.2

version 1.1, 2019/10/31 21:14:17 version 1.2, 2019/11/01 12:10:43
Line 22 
Line 22 
 a monotonic signature counter that can be used (at scale) to detect  a monotonic signature counter that can be used (at scale) to detect
 concurrent use of a private key, should it be extracted from hardware.  concurrent use of a private key, should it be extracted from hardware.
   
 U2F private keys are generatted through an enrollment operation,  U2F private keys are generated through an enrollment operation,
 which takes an application ID - a URL-like string, typically "ssh:"  which takes an application ID - a URL-like string, typically "ssh:"
 in this case, but a HTTP origin for the case of web authentication,  in this case, but a HTTP origin for the case of web authentication,
 and a challenge string (typically randomly generated). The enrollment  and a challenge string (typically randomly generated). The enrollment
 operation returns a public key, a key handle that must be used to invoke  operation returns a public key, a key handle that must be used to invoke
 the hardware-backed private key, some flags and signed attestation  the hardware-backed private key, some flags and signed attestation
 information that may be used to verify that private key is hosted on a  information that may be used to verify that a private key is hosted on a
 particular hardware instance.  particular hardware instance.
   
 It is common for U2F hardware to derive private keys from the key handle  It is common for U2F hardware to derive private keys from the key handle
Line 73 
Line 73 
 The certificate form of a SSH U2F key appends the usual certificate  The certificate form of a SSH U2F key appends the usual certificate
 information to the public key:  information to the public key:
   
         string          "sk-ecdsa-sha2-nistp256@openssh.com"          string          "sk-ecdsa-sha2-nistp256-cert-v01@openssh.com"
         string          nonce          string          nonce
         ec_point        Q          ec_point        Q
         string          application          string          application
Line 98 
Line 98 
 default.  default.
   
 Attestation information is very useful however in an organisational  Attestation information is very useful however in an organisational
 context, where it may be used by an CA as part of certificate  context, where it may be used by a CA as part of certificate
 issuance. In this case, exposure to the CA of hardware identity is  issuance. In this case, exposure to the CA of hardware identity is
 desirable. To support this case, OpenSSH optionally allows retaining the  desirable. To support this case, OpenSSH optionally allows retaining the
 attestation information at the time of key generation. It will take the  attestation information at the time of key generation. It will take the
Line 151 
Line 151 
 ssh-agent protocol extensions  ssh-agent protocol extensions
 -----------------------------  -----------------------------
   
 ssh-agent requires some protocol extension to support U2F keys. At  ssh-agent requires a protocol extension to support U2F keys. At
 present the closest analogue to Security Keys in ssh-agent are PKCS#11  present the closest analogue to Security Keys in ssh-agent are PKCS#11
 tokens, insofar as they require a middleware library to communicate with  tokens, insofar as they require a middleware library to communicate with
 the device that holds the keys. Unfortunately, the protocol message used  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  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.  key handle to the agent as U2F keys require.
   
 To avoid this, without having to add wholy new messages to the agent  To avoid this, without having to add wholly new messages to the agent
 protocol we will use the existing SSH2_AGENTC_ADD_ID_CONSTRAINED message  protocol, we will use the existing SSH2_AGENTC_ADD_ID_CONSTRAINED message
 with a new a key constraint extension to encode a path to the middleware  with a new key constraint extension to encode a path to the middleware
 library for the key. The format of this constraint extension would be:  library for the key. The format of this constraint extension would be:
   
         byte            SSH_AGENT_CONSTRAIN_EXTENSION          byte            SSH_AGENT_CONSTRAIN_EXTENSION
Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2