diff options
author | naddy@openbsd.org <naddy@openbsd.org> | 2019-11-01 12:10:43 +0000 |
---|---|---|
committer | Damien Miller <djm@mindrot.org> | 2019-11-02 11:12:50 +1100 |
commit | ad38406fc95fa223b0ef2edf8ff50508f8ab1cb6 (patch) | |
tree | 0d682806a09cbebd1a06c0dc32c0c442eb8157aa /PROTOCOL.u2f | |
parent | 9cac151c2dc76b8e5b727b2fa216f572e372170f (diff) |
upstream: fix miscellaneous text problems; ok djm@
OpenBSD-Commit-ID: 0cbf411a14d8fa0b269b69cbb1b4fc0ca699fe9f
Diffstat (limited to 'PROTOCOL.u2f')
-rw-r--r-- | PROTOCOL.u2f | 16 |
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 | |||
22 | a monotonic signature counter that can be used (at scale) to detect | 22 | a monotonic signature counter that can be used (at scale) to detect |
23 | concurrent use of a private key, should it be extracted from hardware. | 23 | concurrent use of a private key, should it be extracted from hardware. |
24 | 24 | ||
25 | U2F private keys are generatted through an enrollment operation, | 25 | U2F private keys are generated through an enrollment operation, |
26 | which takes an application ID - a URL-like string, typically "ssh:" | 26 | which takes an application ID - a URL-like string, typically "ssh:" |
27 | in this case, but a HTTP origin for the case of web authentication, | 27 | in this case, but a HTTP origin for the case of web authentication, |
28 | and a challenge string (typically randomly generated). The enrollment | 28 | and a challenge string (typically randomly generated). The enrollment |
29 | operation returns a public key, a key handle that must be used to invoke | 29 | operation returns a public key, a key handle that must be used to invoke |
30 | the hardware-backed private key, some flags and signed attestation | 30 | the hardware-backed private key, some flags and signed attestation |
31 | information that may be used to verify that private key is hosted on a | 31 | information that may be used to verify that a private key is hosted on a |
32 | particular hardware instance. | 32 | particular hardware instance. |
33 | 33 | ||
34 | It is common for U2F hardware to derive private keys from the key handle | 34 | It is common for U2F hardware to derive private keys from the key handle |
@@ -73,7 +73,7 @@ The corresponding private key contains: | |||
73 | The certificate form of a SSH U2F key appends the usual certificate | 73 | The certificate form of a SSH U2F key appends the usual certificate |
74 | information to the public key: | 74 | information 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 | |||
98 | default. | 98 | default. |
99 | 99 | ||
100 | Attestation information is very useful however in an organisational | 100 | Attestation information is very useful however in an organisational |
101 | context, where it may be used by an CA as part of certificate | 101 | context, where it may be used by a CA as part of certificate |
102 | issuance. In this case, exposure to the CA of hardware identity is | 102 | issuance. In this case, exposure to the CA of hardware identity is |
103 | desirable. To support this case, OpenSSH optionally allows retaining the | 103 | desirable. To support this case, OpenSSH optionally allows retaining the |
104 | attestation information at the time of key generation. It will take the | 104 | attestation information at the time of key generation. It will take the |
@@ -151,16 +151,16 @@ ecdsa_signature field returned from the hardware. | |||
151 | ssh-agent protocol extensions | 151 | ssh-agent protocol extensions |
152 | ----------------------------- | 152 | ----------------------------- |
153 | 153 | ||
154 | ssh-agent requires some protocol extension to support U2F keys. At | 154 | ssh-agent requires a protocol extension to support U2F keys. At |
155 | present the closest analogue to Security Keys in ssh-agent are PKCS#11 | 155 | present the closest analogue to Security Keys in ssh-agent are PKCS#11 |
156 | tokens, insofar as they require a middleware library to communicate with | 156 | tokens, insofar as they require a middleware library to communicate with |
157 | the device that holds the keys. Unfortunately, the protocol message used | 157 | the device that holds the keys. Unfortunately, the protocol message used |
158 | to add PKCS#11 keys to ssh-agent does not include any way to send the | 158 | to add PKCS#11 keys to ssh-agent does not include any way to send the |
159 | key handle to the agent as U2F keys require. | 159 | key handle to the agent as U2F keys require. |
160 | 160 | ||
161 | To avoid this, without having to add wholy new messages to the agent | 161 | To avoid this, without having to add wholly new messages to the agent |
162 | protocol we will use the existing SSH2_AGENTC_ADD_ID_CONSTRAINED message | 162 | protocol, we will use the existing SSH2_AGENTC_ADD_ID_CONSTRAINED message |
163 | with a new a key constraint extension to encode a path to the middleware | 163 | with a new key constraint extension to encode a path to the middleware |
164 | library for the key. The format of this constraint extension would be: | 164 | library 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 |