Lines Matching +full:multi +full:- +full:touch
4 ----------
6 U2F is an open standard for two-factor authentication hardware, widely
9 cheapest way for users to achieve hardware-backed credential storage.
19 by requiring the user touch the key). They also offer an attestation
26 which takes an application ID - a URL-like string, typically "ssh:"
30 the hardware-backed private key, some flags and signed attestation
35 in conjunction with a small per-device secret that is unique to the
36 hardware, thus requiring little on-device storage for an effectively
39 primarily use ECDSA signatures in the NIST-P256 field, though the FIDO2
42 Use of U2F security keys does not automatically imply multi-factor
45 authentication. To enable multi-factor authentication in ssh, please
50 -------------------
54 sk-ecdsa-sha2-nistp256@openssh.com
55 sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
56 sk-ssh-ed25519@openssh.com
57 sk-ssh-ed25519-cert-v01@openssh.com
59 While each uses ecdsa-sha256-nistp256 as the underlying signature primitive,
62 the existing ecdsa-sha2-nistp* key types.
64 The format of a sk-ecdsa-sha2-nistp256@openssh.com public key is:
66 string "sk-ecdsa-sha2-nistp256@openssh.com"
69 string application (user-specified, but typically "ssh:")
73 string "sk-ecdsa-sha2-nistp256@openssh.com"
76 string application (user-specified, but typically "ssh:")
81 The format of a sk-ssh-ed25519@openssh.com public key is:
83 string "sk-ssh-ed25519@openssh.com"
85 string application (user-specified, but typically "ssh:")
89 string "sk-ssh-ed25519@openssh.com"
91 string application (user-specified, but typically "ssh:")
99 string "sk-ecdsa-sha2-nistp256-cert-v01@openssh.com"
118 string "sk-ssh-ed25519-cert-v01@openssh.com"
136 string type (e.g. "sk-ssh-ed25519-cert-v01@openssh.com")
145 hardware-backed. Unfortunately, the protocol required for this proof is
146 not privacy-preserving and may be used to identify U2F tokens with at
151 Attestation information is useful for out-of-band key and certificate
157 string "ssh-sk-attest-v01"
167 string "ssh-sk-attest-v00"
177 ------------------
199 For use in the SSH protocol, we wish to avoid server-side parsing of ASN.1
200 format data in the pre-authentication attack surface. Therefore, the
204 string "sk-ecdsa-sha2-nistp256@openssh.com"
217 string "sk-ssh-ed25519@openssh.com"
223 -------------------
229 "webauthn-sk-ecdsa-sha2-nistp256@openssh.com" signature algorithm.
231 The wire encoding for a webauthn-sk-ecdsa-sha2-nistp256@openssh.com
232 signature is similar to the sk-ecdsa-sha2-nistp256@openssh.com format:
234 string "webauthn-sk-ecdsa-sha2-nistp256@openssh.com"
243 the JSON-like structure signed by the browser and "extensions" are any
246 [1] https://www.w3.org/TR/webauthn-2/
248 ssh-agent protocol extensions
249 -----------------------------
251 ssh-agent requires a protocol extension to support U2F keys. At
252 present the closest analogue to Security Keys in ssh-agent are PKCS#11
255 to add PKCS#11 keys to ssh-agent does not include any way to send the
264 string sk-provider@openssh.com
267 This constraint-based approach does not present any compatibility
271 -------------------
276 regress testing. For this reason, OpenSSH shall support a dynamically-
281 numbers listed in sk-api.h. Included in the defined numbers is a
285 miscellaneous options may be passed to the middleware as a NULL-
303 overriding OpenSSH's default of using an all-zero username.
306 ssh-pkcs11-helper to provide address-space containment of the
307 middleware from ssh-agent.