Import openssh_6.8p1.orig.tar.gz

1 files changed, 50 insertions, 3 deletions

diff --git a/PROTOCOL b/PROTOCOL
index aa59f584e..91bfe270d 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
 
@@ -282,6 +282,53 @@ by the client cancel the forwarding of a Unix domain socket.
         boolean         FALSE
         string          socket path
 
+2.5. connection: hostkey update and rotation "hostkeys-00@openssh.com"
+and "hostkeys-prove-00@openssh.com"
+
+OpenSSH supports a protocol extension allowing a server to inform
+a client of all its protocol v.2 host keys after user-authentication
+has completed.
+
+        byte            SSH_MSG_GLOBAL_REQUEST
+        string          "hostkeys-00@openssh.com"
+        string[]        hostkeys
+
+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.
+
+        byte            SSH_MSG_GLOBAL_REQUEST
+        string          "hostkeys-prove-00@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          "hostkeys-prove-00@openssh.com"
+        string          session identifier
+        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
 
 3.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK
@@ -406,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.24 2014/07/15 15:54:14 millert Exp $
+$OpenBSD: PROTOCOL,v 1.27 2015/02/20 22:17:21 djm Exp $