summaryrefslogtreecommitdiff
path: root/PROTOCOL.u2f
diff options
context:
space:
mode:
Diffstat (limited to 'PROTOCOL.u2f')
-rw-r--r--PROTOCOL.u2f16
1 files changed, 8 insertions, 8 deletions
diff --git a/PROTOCOL.u2f b/PROTOCOL.u2f
index ab9e3e333..a587480be 100644
--- a/PROTOCOL.u2f
+++ b/PROTOCOL.u2f
@@ -22,13 +22,13 @@ given key is backed by hardware. Finally the signature format includes
22a monotonic signature counter that can be used (at scale) to detect 22a monotonic signature counter that can be used (at scale) to detect
23concurrent use of a private key, should it be extracted from hardware. 23concurrent use of a private key, should it be extracted from hardware.
24 24
25U2F private keys are generatted through an enrollment operation, 25U2F private keys are generated through an enrollment operation,
26which takes an application ID - a URL-like string, typically "ssh:" 26which takes an application ID - a URL-like string, typically "ssh:"
27in this case, but a HTTP origin for the case of web authentication, 27in this case, but a HTTP origin for the case of web authentication,
28and a challenge string (typically randomly generated). The enrollment 28and a challenge string (typically randomly generated). The enrollment
29operation returns a public key, a key handle that must be used to invoke 29operation returns a public key, a key handle that must be used to invoke
30the hardware-backed private key, some flags and signed attestation 30the hardware-backed private key, some flags and signed attestation
31information that may be used to verify that private key is hosted on a 31information that may be used to verify that a private key is hosted on a
32particular hardware instance. 32particular hardware instance.
33 33
34It is common for U2F hardware to derive private keys from the key handle 34It is common for U2F hardware to derive private keys from the key handle
@@ -73,7 +73,7 @@ The corresponding private key contains:
73The certificate form of a SSH U2F key appends the usual certificate 73The certificate form of a SSH U2F key appends the usual certificate
74information to the public key: 74information to the public key:
75 75
76 string "sk-ecdsa-sha2-nistp256@openssh.com" 76 string "sk-ecdsa-sha2-nistp256-cert-v01@openssh.com"
77 string nonce 77 string nonce
78 ec_point Q 78 ec_point Q
79 string application 79 string application
@@ -98,7 +98,7 @@ choose not to include this information in the public key or save it by
98default. 98default.
99 99
100Attestation information is very useful however in an organisational 100Attestation information is very useful however in an organisational
101context, where it may be used by an CA as part of certificate 101context, where it may be used by a CA as part of certificate
102issuance. In this case, exposure to the CA of hardware identity is 102issuance. In this case, exposure to the CA of hardware identity is
103desirable. To support this case, OpenSSH optionally allows retaining the 103desirable. To support this case, OpenSSH optionally allows retaining the
104attestation information at the time of key generation. It will take the 104attestation information at the time of key generation. It will take the
@@ -151,16 +151,16 @@ ecdsa_signature field returned from the hardware.
151ssh-agent protocol extensions 151ssh-agent protocol extensions
152----------------------------- 152-----------------------------
153 153
154ssh-agent requires some protocol extension to support U2F keys. At 154ssh-agent requires a protocol extension to support U2F keys. At
155present the closest analogue to Security Keys in ssh-agent are PKCS#11 155present the closest analogue to Security Keys in ssh-agent are PKCS#11
156tokens, insofar as they require a middleware library to communicate with 156tokens, insofar as they require a middleware library to communicate with
157the device that holds the keys. Unfortunately, the protocol message used 157the device that holds the keys. Unfortunately, the protocol message used
158to add PKCS#11 keys to ssh-agent does not include any way to send the 158to add PKCS#11 keys to ssh-agent does not include any way to send the
159key handle to the agent as U2F keys require. 159key handle to the agent as U2F keys require.
160 160
161To avoid this, without having to add wholy new messages to the agent 161To avoid this, without having to add wholly new messages to the agent
162protocol we will use the existing SSH2_AGENTC_ADD_ID_CONSTRAINED message 162protocol, we will use the existing SSH2_AGENTC_ADD_ID_CONSTRAINED message
163with a new a key constraint extension to encode a path to the middleware 163with a new key constraint extension to encode a path to the middleware
164library for the key. The format of this constraint extension would be: 164library for the key. The format of this constraint extension would be:
165 165
166 byte SSH_AGENT_CONSTRAIN_EXTENSION 166 byte SSH_AGENT_CONSTRAIN_EXTENSION