summaryrefslogtreecommitdiff
path: root/PROTOCOL
diff options
context:
space:
mode:
authordjm@openbsd.org <djm@openbsd.org>2015-02-16 22:13:32 +0000
committerDamien Miller <djm@mindrot.org>2015-02-17 09:32:32 +1100
commit523463a3a2a9bfc6cfc5afa01bae9147f76a37cc (patch)
tree772be92cee9553c19d51b4570113c3d4de0c2d8b /PROTOCOL
parent6c5c949782d86a6e7d58006599c7685bfcd01685 (diff)
upstream commit
Revise hostkeys@openssh.com hostkey learning extension. The client will not ask the server to prove ownership of the private halves of any hitherto-unseen hostkeys it offers to the client. Allow UpdateHostKeys option to take an 'ask' argument to let the user manually review keys offered. ok markus@
Diffstat (limited to 'PROTOCOL')
-rw-r--r--PROTOCOL53
1 files changed, 39 insertions, 14 deletions
diff --git a/PROTOCOL b/PROTOCOL
index 8150c577..f9560839 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -40,8 +40,8 @@ http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
"ecdsa-sha2-nistp521-cert-v01@openssh.com"
OpenSSH introduces new public key algorithms to support certificate
-authentication for users and hostkeys. These methods are documented in
-the file PROTOCOL.certkeys
+authentication for users and host keys. These methods are documented
+in the file PROTOCOL.certkeys
1.4. transport: Elliptic Curve cryptography
@@ -283,26 +283,51 @@ by the client cancel the forwarding of a Unix domain socket.
string socket path
2.5. connection: hostkey update and rotation "hostkeys@openssh.com"
+and "hostkeys-prove@openssh.com"
OpenSSH supports a protocol extension allowing a server to inform
-a client of all its protocol v.2 hostkeys after user-authentication
+a client of all its protocol v.2 host keys after user-authentication
has completed.
byte SSH_MSG_GLOBAL_REQUEST
string "hostkeys@openssh.com"
string[] hostkeys
-Upon receiving this message, a client may update its known_hosts
-file, adding keys that it has not seen before and deleting keys
-for the server host that are no longer offered.
+Upon receiving this message, a client should check which of the
+supplied host keys are present in known_hosts. For keys that are
+not present, it should send a "hostkeys-prove@openssh.com" message
+to request the server prove ownership of the private half of the
+key.
-This extension allows a client to learn key types that it had
-not previously encountered, thereby allowing it to potentially
-upgrade from weaker key algorithms to better ones. It also
-supports graceful key rotation: a server may offer multiple keys
-of the same type for a period (to give clients an opportunity to
-learn them using this extension) before removing the deprecated
-key from those offered.
+ byte SSH_MSG_GLOBAL_REQUEST
+ string "hostkeys-prove@openssh.com"
+ char 1 /* want-reply */
+ string[] hostkeys
+
+When a server receives this message, it should generate a signature
+using each requested key over the following:
+
+ string session identifier
+ string "hostkeys-prove@openssh.com"
+ string hostkey
+
+These signatures should be included in the reply, in the order matching
+the hostkeys in the request:
+
+ byte SSH_MSG_REQUEST_SUCCESS
+ string[] signatures
+
+When the client receives this reply (and not a failure), it should
+validate the signatures and may update its known_hosts file, adding keys
+that it has not seen before and deleting keys for the server host that
+are no longer offered.
+
+These extensions let a client learn key types that it had not previously
+encountered, thereby allowing it to potentially upgrade from weaker
+key algorithms to better ones. It also supports graceful key rotation:
+a server may offer multiple keys of the same type for a period (to
+give clients an opportunity to learn them using this extension) before
+removing the deprecated key from those offered.
3. SFTP protocol changes
@@ -428,4 +453,4 @@ respond with a SSH_FXP_STATUS message.
This extension is advertised in the SSH_FXP_VERSION hello with version
"1".
-$OpenBSD: PROTOCOL,v 1.25 2015/01/26 03:04:45 djm Exp $
+$OpenBSD: PROTOCOL,v 1.26 2015/02/16 22:13:32 djm Exp $