summaryrefslogtreecommitdiff
path: root/PROTOCOL
diff options
context:
space:
mode:
authorDamien Miller <djm@mindrot.org>2010-08-31 22:41:14 +1000
committerDamien Miller <djm@mindrot.org>2010-08-31 22:41:14 +1000
commiteb8b60e320cdade9f4c07e2abacfb92c52e01348 (patch)
tree4e5bc25790566402e5b7ae00cefd2c57e867ef09 /PROTOCOL
parentda108ece6843f1268aa36d7c8ed0030dc53acd15 (diff)
- djm@cvs.openbsd.org 2010/08/31 11:54:45
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c] [authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c] [monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c] [ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c] [ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h] [ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5] [uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c] Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer better performance than plain DH and DSA at the same equivalent symmetric key length, as well as much shorter keys. Only the mandatory sections of RFC5656 are implemented, specifically the three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and ECDSA. Point compression (optional in RFC5656 is NOT implemented). Certificate host and user keys using the new ECDSA key types are supported. Note that this code has not been tested for interoperability and may be subject to change. feedback and ok markus@
Diffstat (limited to 'PROTOCOL')
-rw-r--r--PROTOCOL45
1 files changed, 31 insertions, 14 deletions
diff --git a/PROTOCOL b/PROTOCOL
index 5fc31eade..5d2a7118a 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -12,7 +12,9 @@ are individually implemented as extensions described below.
12The protocol used by OpenSSH's ssh-agent is described in the file 12The protocol used by OpenSSH's ssh-agent is described in the file
13PROTOCOL.agent 13PROTOCOL.agent
14 14
151. transport: Protocol 2 MAC algorithm "umac-64@openssh.com" 151. Transport protocol changes
16
171.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"
16 18
17This is a new transport-layer MAC method using the UMAC algorithm 19This is a new transport-layer MAC method using the UMAC algorithm
18(rfc4418). This method is identical to the "umac-64" method documented 20(rfc4418). This method is identical to the "umac-64" method documented
@@ -20,7 +22,7 @@ in:
20 22
21http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt 23http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt
22 24
232. transport: Protocol 2 compression algorithm "zlib@openssh.com" 251.2. transport: Protocol 2 compression algorithm "zlib@openssh.com"
24 26
25This transport-layer compression method uses the zlib compression 27This transport-layer compression method uses the zlib compression
26algorithm (identical to the "zlib" method in rfc4253), but delays the 28algorithm (identical to the "zlib" method in rfc4253), but delays the
@@ -31,14 +33,27 @@ The method is documented in:
31 33
32http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt 34http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
33 35
343. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com" and 361.3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com",
35 "ssh-dsa-cert-v00@openssh.com" 37 "ssh-dsa-cert-v00@openssh.com",
38 "ecdsa-sha2-nistp256-cert-v01@openssh.com",
39 "ecdsa-sha2-nistp384-cert-v01@openssh.com" and
40 "ecdsa-sha2-nistp521-cert-v01@openssh.com"
36 41
37OpenSSH introduces two new public key algorithms to support certificate 42OpenSSH introduces new public key algorithms to support certificate
38authentication for users and hostkeys. These methods are documented in 43authentication for users and hostkeys. These methods are documented in
39the file PROTOCOL.certkeys 44the file PROTOCOL.certkeys
40 45
414. connection: Channel write close extension "eow@openssh.com" 461.4. transport: Elliptic Curve cryptography
47
48OpenSSH supports ECC key exchange and public key authentication as
49specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
50and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic
51curve points encoded using point compression are NOT accepted or
52generated.
53
542. Connection protocol changes
55
562.1. connection: Channel write close extension "eow@openssh.com"
42 57
43The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF 58The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF
44message to allow an endpoint to signal its peer that it will send no 59message to allow an endpoint to signal its peer that it will send no
@@ -77,8 +92,8 @@ message is only sent to OpenSSH peers (identified by banner).
77Other SSH implementations may be whitelisted to receive this message 92Other SSH implementations may be whitelisted to receive this message
78upon request. 93upon request.
79 94
805. connection: disallow additional sessions extension 952.2. connection: disallow additional sessions extension
81 "no-more-sessions@openssh.com" 96 "no-more-sessions@openssh.com"
82 97
83Most SSH connections will only ever request a single session, but a 98Most SSH connections will only ever request a single session, but a
84attacker may abuse a running ssh client to surreptitiously open 99attacker may abuse a running ssh client to surreptitiously open
@@ -105,7 +120,7 @@ of this message, the no-more-sessions request is only sent to OpenSSH
105servers (identified by banner). Other SSH implementations may be 120servers (identified by banner). Other SSH implementations may be
106whitelisted to receive this message upon request. 121whitelisted to receive this message upon request.
107 122
1086. connection: Tunnel forward extension "tun@openssh.com" 1232.3. connection: Tunnel forward extension "tun@openssh.com"
109 124
110OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" 125OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"
111channel type. This channel type supports forwarding of network packets 126channel type. This channel type supports forwarding of network packets
@@ -166,7 +181,9 @@ The contents of the "data" field for layer 2 packets is:
166The "frame" field contains an IEEE 802.3 Ethernet frame, including 181The "frame" field contains an IEEE 802.3 Ethernet frame, including
167header. 182header.
168 183
1697. sftp: Reversal of arguments to SSH_FXP_SYMLINK 1843. SFTP protocol changes
185
1863.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK
170 187
171When OpenSSH's sftp-server was implemented, the order of the arguments 188When OpenSSH's sftp-server was implemented, the order of the arguments
172to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately, 189to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately,
@@ -179,7 +196,7 @@ SSH_FXP_SYMLINK as follows:
179 string targetpath 196 string targetpath
180 string linkpath 197 string linkpath
181 198
1828. sftp: Server extension announcement in SSH_FXP_VERSION 1993.2. sftp: Server extension announcement in SSH_FXP_VERSION
183 200
184OpenSSH's sftp-server lists the extensions it supports using the 201OpenSSH's sftp-server lists the extensions it supports using the
185standard extension announcement mechanism in the SSH_FXP_VERSION server 202standard extension announcement mechanism in the SSH_FXP_VERSION server
@@ -200,7 +217,7 @@ ever changed in an incompatible way. The server MAY advertise the same
200extension with multiple versions (though this is unlikely). Clients MUST 217extension with multiple versions (though this is unlikely). Clients MUST
201check the version number before attempting to use the extension. 218check the version number before attempting to use the extension.
202 219
2039. sftp: Extension request "posix-rename@openssh.com" 2203.3. sftp: Extension request "posix-rename@openssh.com"
204 221
205This operation provides a rename operation with POSIX semantics, which 222This operation provides a rename operation with POSIX semantics, which
206are different to those provided by the standard SSH_FXP_RENAME in 223are different to those provided by the standard SSH_FXP_RENAME in
@@ -217,7 +234,7 @@ rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
217This extension is advertised in the SSH_FXP_VERSION hello with version 234This extension is advertised in the SSH_FXP_VERSION hello with version
218"1". 235"1".
219 236
22010. sftp: Extension requests "statvfs@openssh.com" and 2373.4. sftp: Extension requests "statvfs@openssh.com" and
221 "fstatvfs@openssh.com" 238 "fstatvfs@openssh.com"
222 239
223These requests correspond to the statvfs and fstatvfs POSIX system 240These requests correspond to the statvfs and fstatvfs POSIX system
@@ -258,4 +275,4 @@ The values of the f_flag bitmask are as follows:
258Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are 275Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are
259advertised in the SSH_FXP_VERSION hello with version "2". 276advertised in the SSH_FXP_VERSION hello with version "2".
260 277
261$OpenBSD: PROTOCOL,v 1.15 2010/02/26 20:29:54 djm Exp $ 278$OpenBSD: PROTOCOL,v 1.16 2010/08/31 11:54:45 djm Exp $