idnits 2.17.1 draft-ietf-secsh-transport-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 436 has weird spacing: '... string cert...' == Line 463 has weird spacing: '... string dss...' == Line 505 has weird spacing: '... string kex...' == Line 506 has weird spacing: '... string ser...' == Line 507 has weird spacing: '... string enc...' == (21 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 June 1999) is 9075 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SPKI' is mentioned on line 475, but not defined -- Looks like a reference, but probably isn't: '16' on line 504 == Unused Reference: 'RFC-1034' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'SSH-USERAUTH' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 1044, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' -- Possible downref: Non-RFC (?) normative reference: ref. 'Orm96' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-04 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-06 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-06 Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ylonen 2 INTERNET-DRAFT T. Kivinen 3 draft-ietf-secsh-transport-06.txt M. Saarinen 4 Expires in six months T. Rinne 5 S. Lehtinen 6 SSH 7 22 June 1999 9 SSH Transport Layer Protocol 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 SSH is a protocol for secure remote login and other secure network ser- 36 vices over an insecure network. This document describes the SSH trans- 37 port layer protocol which typically runs on top of TCP/IP. The protocol 38 can be used as a basis for a number of secure network services. It pro- 39 vides strong encryption, server authentication, and integrity protec- 40 tion. It may also provide compression. Key exchange method, public key 41 algorithm, symmetric encryption algorithm, message authentication algo- 42 rithm, and hash algorithm are all negotiated. This document also 43 describes the Diffie-Hellman key exchange method and the minimal set of 44 algorithms that are needed to implement the SSH transport layer proto- 45 col. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 51 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2. Protocol Version Exchange . . . . . . . . . . . . . . . . . 3 54 3.3. Compatibility with Old SSH Versions . . . . . . . . . . . . 4 55 3.3.1. Old Client, New Server . . . . . . . . . . . . . . . . . 4 56 3.3.2. New Client, Old Server . . . . . . . . . . . . . . . . . 4 57 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Maximum Packet Length . . . . . . . . . . . . . . . . . . . 5 59 4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.5. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 8 63 4.6. Public Key Algorithms . . . . . . . . . . . . . . . . . . . 8 64 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 10 66 5.2. Output from Key Exchange . . . . . . . . . . . . . . . . . . 12 67 5.3. Taking Keys into Use . . . . . . . . . . . . . . . . . . . . 13 68 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . . 14 69 6.1. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 15 70 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . . 16 71 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . . 17 73 9.1. Disconnection Message . . . . . . . . . . . . . . . . . . . 17 74 9.2. Ignored Data Message . . . . . . . . . . . . . . . . . . . . 18 75 9.3. Debug Message . . . . . . . . . . . . . . . . . . . . . . . 18 76 9.4. Reserved Messages . . . . . . . . . . . . . . . . . . . . . 18 77 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 18 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 19 79 12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 19 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 The SSH transport layer is a secure low level transport protocol. It 86 provides strong encryption, cryptographic host authentication, and 87 integrity protection. 89 Authentication in this protocol level is host-based; this protocol does 90 not perform user authentication. A higher level protocol for user 91 authentication can be designed on top of this protocol. 93 The protocol has been designed to be simple, flexible, to allow 94 parameter negotiation, and to minimize the number of round-trips. Key 95 exchange method, public key algorithm, symmetric encryption algorithm, 96 message authentication algorithm, and hash algorithm are all negotiated. 97 It is expected that in most environments, only 2 round-trips will be 98 needed for full key exchange, server authentication, service request, 99 and acceptance notification of service request. The worst case is 3 100 round-trips. 102 2. Conventions Used in This Document 104 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and 105 "MAY" that appear in this document are to be interpreted as described in 106 [RFC-2119]. 108 The used data types and terminology are specified in the architecture 109 document [SSH-ARCH]. 111 The architecture document also discusses the algorithm naming 112 conventions that MUST be used with the SSH protocols. 113 3. Connection Setup 115 SSH works over any 8-bit clean, binary-transparent transport. The 116 underlying transport SHOULD protect against transmission errors as such 117 errors cause the SSH connection to terminate. 119 The client initiates the connection. 121 3.1. Use over TCP/IP 123 When used over TCP/IP, the server normally listens for connections on 124 port 22. This port number has been registered with the IANA, and has 125 been officially assigned for SSH. 127 3.2. Protocol Version Exchange 129 When the connection has been established, both sides MUST send an 130 identification string of the form "SSH-protoversion-softwareversion 131 comments", followed by carriage return and newline characters (ascii 13 132 and 10, respectively). Both sides MUST be able to process 133 identification strings without carriage return character. No null 134 character is sent. The maximum length of the string is 255 characters, 135 including the carriage return and newline. 137 The part of the identification string preceding carriage return and 138 newline is used in the Diffie-Hellman key exchange (Section ``Diffie- 139 Hellman Key Exchange''). 141 The server MAY send other lines of data before sending the version 142 string. Each line SHOULD be terminated by a carriage return and 143 newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 144 in ISO-10646 UTF-8 [RFC-2044] (language is not specified). Clients MUST 145 be able to process such lines; they MAY be silently ignored, or MAY be 146 displayed to the client user; if they are displayed, control character 147 filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of 148 this feature is to allow TCP-wrappers to display an error message before 149 disconnecting. 151 Version strings MUST consist of printable US-ASCII characters, not 152 including whitespaces or a minus sign (-). The version string is 153 primarily used to trigger compatibility extensions and to indicate the 154 capabilities of an implementation. The comment string should contain 155 additional information that might be useful in solving user problems. 157 The protocol version described in this document is 2.0. 159 Key exchange will begin immediately after sending this identifier. All 160 packets following the identification string SHALL use the binary packet 161 protocol, to be described below. 162 3.3. Compatibility with Old SSH Versions 164 During a transition period, it is important to be able to work 165 compatibly with installed SSH clients and servers using an older version 166 of the protocol. Information in this section is only relevant for 167 implementations supporting compatibility with SSH versions 1.x. 169 3.3.1. Old Client, New Server 171 Server implementations MAY support a configurable "compatibility" flag 172 that enables compatibility with old versions. When this flag is on, the 173 server SHOULD identify its protocol version as "1.99". Clients using 174 protocol 2.0 MUST be able to identify this as identical to "2.0". In 175 this mode the server SHOULD NOT send carriage return character (ascii 176 13) after the version identification string. 178 In the compatibility mode the server SHOULD NOT send any further data 179 after its initialization string until it has received an identification 180 string from the client. The server can then determine whether the 181 client is using an old protocol, and can revert to the old protocol if 182 desired. The server MUST NOT send additional data before the version 183 string, in the compatibility mode. 185 When compatibility with old clients is not needed, the server MAY send 186 its initial key exchange data immediately after the identification 187 string. 189 3.3.2. New Client, Old Server 191 Since the new client MAY immediately send additional data after its 192 identification string (before receiving server's identification), the 193 old protocol may already have been corrupted when the client learns that 194 the server is old. When this happens, the client SHOULD close the 195 connection to the server, and reconnect using the old protocol. 197 4. Binary Packet Protocol 199 Each packet is of the following format. 201 uint32 packet_length 202 byte padding_length 203 byte[n1] payload; n1 = packet_length - padding_length - 1 204 byte[n2] random padding; n2 = padding_length 205 byte[m] mac (message authentication code); m = mac_length 207 packet_length 208 The length of the packet (bytes), not including MAC or the 209 packet_length field itself. 211 padding_length 212 Length of padding (bytes). 214 payload 215 The useful contents of the packet. If compression has been 216 negotiated, this field is compressed. Initially, compression MUST 217 be "none". 219 Padding 220 Arbitrary-length padding, such that the total length of 221 (packet_length || padding_length || payload || padding) is a 222 multiple of the cipher block size or 8, whichever is larger. 223 There MUST be at least four bytes of padding. The padding SHOULD 224 consist of random bytes. The maximum amount of padding is 255 225 bytes. 227 MAC 228 Message authentication code. If message authentication has been 229 negotiated, this field contains the MAC bytes. Initially, the MAC 230 algorithm MUST be "none". 232 Note that length of the concatenation of packet length, padding length, 233 payload, and padding MUST be a multiple of the cipher block size or 8, 234 whichever is larger. This constraint MUST be enforced even when using 235 stream ciphers. Note that the packet length field is also encrypted, 236 and processing it requires special care when sending or receiving 237 packets. 239 The minimum size of a packet is 16 (or the cipher block size, whichever 240 is larger) bytes (plus MAC); implementations SHOULD decrypt the length 241 after receiving the first 8 (or cipher block size, whichever is larger) 242 bytes of a packet. 244 4.1. Maximum Packet Length 246 All implementations MUST be able to process packets with uncompressed 247 payload length of 32768 bytes or less and total packet size of 35000 248 bytes or less (including length, padding length, payload, padding, and 249 MAC). Implementations SHOULD support longer packets, where they might 250 be needed e.g. if an implementation wants to send a very large number of 251 certificates. Such packets MAY be sent if the version string indicates 252 that the other party is able to process them. However, implementations 253 SHOULD check that the packet length is reasonable for the implementation 254 to avoid denial-of-service and/or buffer overflow attacks. 256 4.2. Compression 258 If compression has been negotiated, the payload field (and only it) will 259 be compressed using the negotiated algorithm. The length field and MAC 260 will be computed from the compressed payload. 262 Compression MAY be stateful, depending on the method. Compression MUST 263 be independent for each direction, and implementations MUST allow 264 independently choosing the algorithm for each direction. 266 The following compression methods are currently defined: 268 none REQUIRED no compression 269 zlib OPTIONAL GNU ZLIB (LZ77) compression 271 The "zlib" compression is described in [RFC-1950] and in [RFC-1951]. The 272 compression context is initialized after each key exchange, and is 273 passed from one packet to the next with only a partial flush being 274 performed at the end of each packet. A partial flush means that all data 275 will be output, but the next packet will continue using compression 276 tables from the end of the previous packet. 278 Additional methods may be defined as specified in [SSH-ARCH]. 280 4.3. Encryption 282 An encryption algorithm and a key will be negotiated during the key 283 exchange. When encryption is in effect, the packet length, padding 284 length, payload and padding fields of each packet MUST be encrypted with 285 the given algorithm. 287 The encrypted data in all packets sent in one direction SHOULD be 288 considered a single data stream. For example, initialization vectors 289 SHOULD be passed from the end of one packet to the beginning of the next 290 packet. All ciphers SHOULD use keys with an effective key length of 128 291 bits or more. 293 The ciphers in each direction MUST run independently of each other, and 294 implementations MUST allow independently choosing the algorithm for each 295 direction (if multiple algorithms are allowed by local policy). 297 The following ciphers are currently defined: 299 3des-cbc REQUIRED three-key 3DES in CBC mode 300 blowfish-cbc RECOMMENDED Blowfish in CBC mode 301 twofish-cbc RECOMMENDED Twofish in CBC mode 302 arcfour OPTIONAL the ARCFOUR stream cipher 303 idea-cbc OPTIONAL IDEA in CBC mode 304 cast128-cbc OPTIONAL CAST-128 in CBC mode 305 none OPTIONAL no encryption; NOT RECOMMENDED 307 The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-encrypt), 308 where the first 8 bytes of the key are used for the first encryption, 309 the next 8 bytes for the decryption, and the following 8 bytes for the 310 final encryption. This requires 24 bytes of key data (of which 168 bits 311 are actually used). To implement CBC mode, outer chaining MUST be used 312 (i.e., there is only one initialization vector). This is a block cipher 313 with 8 byte blocks. This algorithm is defined in [Schneier]. 315 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 316 [Schneier]. This is a block cipher with 8 byte blocks. 318 The "twofish-cbc" cipher is Twofish in CBC mode, with 256 bit keys as 319 described in Twofish AES submission. This is a block cipher with 16 byte 320 blocks. 322 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 323 Arcfour cipher is believed to be compatible with the RC4 cipher 324 [Schneier]. RC4 is a registered trademark of RSA Data Security Inc. 326 The "idea-cbc" cipher is the IDEA cipher in CBC mode [Schneier]. IDEA is 327 patented by Ascom AG. 329 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC-2144]. 331 The "none" algorithm specifies that no encryption is to be done. Note 332 that this method provides no confidentiality protection, and it is not 333 recommended. Some functionality (e.g. password authentication) may be 334 disabled for security reasons if this cipher is chosen. 336 Additional methods may be defined as specified in [SSH-ARCH]. 338 4.4. Data Integrity 340 Data integrity is protected by including with each packet a message 341 authentication code (MAC) that is computed from a shared secret, packet 342 sequence number, and the contents of the packet. 343 The message authentication algorithm and key are negotiated during key 344 exchange. Initially, no MAC will be in effect, and its length MUST be 345 zero. After key exchange, the selected MAC will be computed before 346 encryption from the concatenation of packet data: 348 mac = MAC(key, sequence_number || unencrypted_packet) 350 where unencrypted_packet is the entire packet without MAC (the length 351 fields, payload and padding), and sequence_number is an implicit packet 352 sequence number represented as uint32. The sequence number is initial- 353 ized to zero for the first packet, and is incremented after every packet 354 (regardless of whether encryption or MAC is in use). It is never reset, 355 even if keys/algorithms are renegotiated later. It wraps around to zero 356 after every 2^32 packets. The packet sequence number itself is not 357 included in the packet sent over the wire. 359 The MAC algorithms for each direction MUST run independently, and 360 implementations MUST allow choosing the algorithm independently for both 361 directions. 363 The MAC bytes resulting from the MAC algorithm MUST be transmitted 364 without encryption as the last part of the packet. The number of MAC 365 bytes depends on the algorithm chosen. 367 The following MAC algorithms are currently defined: 369 hmac-sha1 REQUIRED HMAC-SHA1 (length = 20) 370 hmac-sha-96 RECOMMENDED first 96 bits of HMAC-SHA1 (length = 12) 371 hmac-md5 OPTIONAL HMAC-MD5 (length = 16) 372 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (length = 12) 373 none OPTIONAL no MAC; NOT RECOMMENDED 375 The "hmac-*" algorithms are described in [RFC-2104]. The "*-n" MACs use 376 only the first n bits of the resulting value. 378 The hash algorithms are described in [Schneier]. 380 The "none" method is NOT RECOMMENDED. An active attacker may be able to 381 modify transmitted data if this is used. 383 Additional methods may be defined as specified in [SSH-ARCH]. 385 4.5. Key Exchange Methods 387 The key exchange method specifies how one-time session keys are 388 generated for encryption and for authentication, and how the server 389 authentication is done. 391 Only one REQUIRED key exchange method has been defined: 393 diffie-hellman-group1-sha1 REQUIRED 395 This method is described later in this document. 397 Additional methods may be defined as specified in [SSH-ARCH]. 399 4.6. Public Key Algorithms 401 This protocol has been designed to be able to operate with almost any 402 public key format, encoding, and algorithm (signature and/or 403 encryption). 405 There are several aspects that define a public key type: 407 o Key format: how is the key encoded and how are certificates 408 represented. The key blobs in this protocol MAY contain certificates 409 in addition to keys. 411 o Signature and/or encryption algorithms. Some key types may not 412 support both signing and encryption. Key usage may also be 413 restricted by policy statements in e.g. certificates. In this case, 414 different key types SHOULD be defined for the different policy 415 alternatives. 417 o Encoding of signatures and/or encrypted data. This includes but is 418 not limited to padding, byte order, and data formats. 420 The following public key and/or certificate formats are currently 421 defined: 423 ssh-dss REQUIRED sign Simple DSS 424 x509v3 RECOMMENDED sign X.509 certificates 425 spki OPTIONAL sign SPKI certificates 426 pgp OPTIONAL sign OpenPGP certificates 428 Additional key types may be defined as specified in [SSH-ARCH]. 430 The key type MUST always be explicitly known (from algorithm negotiation 431 or some other source). It is not normally included in the key blob. 433 Certificates and public keys are encoded as: 435 uint32 combined length of the format identifier and associated data 436 string certificate or public key format identifier 437 byte[n] key/certificate data 439 The certificate part may have be a zero length string, but a public key 440 is required. This is the public key that will be used for 441 authentication; the certificate sequence contained in the certificate 442 blob can be used to provide authorization. 444 The "ssh-dss" key format has the following specific encoding: 446 uint32 length 447 string "ssh-dss" 448 mpint p 449 mpint q 450 mpint g 451 mpint y 453 Here the "p", "q", "g", and "y" parameters form the signature key blob. 455 Signing and verifying using this key format are done according to the 456 Digital Signature Standard [FIPS-186] using the SHA-1 hash. A 457 description can also be found in [Schneier]. 459 The resulting signature is encoded as: 461 uint32 length 462 string "ssh-dss" 463 string dss_signature_blob 465 dss_signature_blob is encoded as string containing "r" followed by "s" 466 (which are 160 bits long integers, without lengths or padding, unsigned 467 and in network byte order). 469 The "x509v3" method indicates that the certificates, the public key, and 470 the resulting signature are in X.509v3 compatible DER-encoded format. 471 The formats used in X.509v3 is described in [PKIX-Part1]. 473 The "spki" method indicates that the certificate blob contains a 474 sequence of SPKI certificates. The format of SPKI certificates is 475 described in [SPKI]. 477 The "pgp" method indicates the the certificates, the public key, and the 478 signature are in OpenPGP compatible binary format. [RFC-2440] 480 5. Key Exchange 482 Key exchange begins by each side sending lists of supported algorithms. 483 Each side has a preferred algorithm in each category, and it is assumed 484 that most implementations at any given time will use the same preferred 485 algorithm. Each side MAY guess which algorithm the other side is using, 486 and MAY send an initial key exchange packet according to the algorithm 487 if appropriate for the preferred method. If all algorithms were guessed 488 right, the optimistically sent packet MUST be handled as the first key 489 exchange packet. However, if the guess was wrong, and a packet was 490 optimistically sent by one or both parties, such packets MUST be ignored 491 (even if the error in the guess would not affect the contents of the 492 initial packet(s)), and the appropriate side MUST send the correct 493 initial packet. 495 Server authentication in the key exchange MAY be implicit. After a key 496 exchange with implicit server authentication, the client MUST wait for 497 response to its service request message before sending any further data. 499 5.1. Algorithm Negotiation 501 Key exchange begins by each side sending the following packet: 503 byte SSH_MSG_KEXINIT 504 byte[16] cookie (random bytes) 505 string kex_algorithms 506 string server_host_key_algorithms 507 string encryption_algorithms_client_to_server 508 string encryption_algorithms_server_to_client 509 string mac_algorithms_client_to_server 510 string mac_algorithms_server_to_client 511 string compression_algorithms_client_to_server 512 string compression_algorithms_server_to_client 513 string languages_client_to_server 514 string languages_server_to_client 515 boolean first_kex_packet_follows 516 uint32 0 (reserved for future extension) 518 Each of the algorithm strings MUST be a comma-separated list of 519 algorithm names (see ``Algorithm Naming'' in [SSH-ARCH]). Each supported 520 (allowed) algorithm MUST be listed, in order of preference. 522 The first algorithm in each list MUST be the preferred (guessed) 523 algorithm. Each string MUST contain at least one algorithm name. 525 cookie 526 The cookie MUST be a random value generated by the sender. Its 527 purpose is to make it impossible for either side to fully 528 determine the keys and the session identifier. 530 kex_algorithms 531 Key exchange algorithms were defined above. The first algorithm 532 MUST be the preferred (and guessed) algorithm. If both sides make 533 the same guess, that algorithm MUST used. Otherwise, the 534 following algorithm MUST be used to choose a key exchange method: 535 iterate over client's kex algorithms, one at a time. Choose the 536 first algorithm that satisfies the following conditions: 538 o the server also supports the algorithm, 540 o if the algorithm requires an encryption-capable host key, there is 541 an encryption-capable algorithm on the server's 542 server_host_key_algorithms that is also supported by the client, 543 and 545 o if the algorithm requires a signature-capable host key, there is a 546 signature-capable algorithm on the server's 547 server_host_key_algorithms that is also supported by the client. 549 If no algorithm satisfying all these conditions can be found, the 550 connection fails, and both sides MUST disconnect. 552 server_host_key_algorithms 553 List of the algorithms supported for the server host key. The 554 server lists the algorithms for which it has host keys; the client 555 lists the algorithms that it is willing to accept. (There MAY be 556 multiple host keys for a host, possibly with different 557 algorithms.) 559 Some host keys may not support both signatures and encryption 560 (this can be determined from the algorithm), and thus not all host 561 keys are valid for all key exchange methods. 563 Algorithm selection depends on whether the chosen key exchange 564 algorithm requires a signature- or encryption capable host key. 565 It MUST be possible to determine this from the public key 566 algorithm name. The first algorithm on the client's list that 567 satisfies the requirements and is also supported by the server 568 MUST be chosen. If there is no such algorithm, both sides MUST 569 disconnect. 571 encryption_algorithms 572 Lists the acceptable symmetric encryption algorithms in order of 573 preference. The chosen encryption algorithm to each direction 574 MUST be the first algorithm on the client's list that is also on 575 the server's list. If there is no such algorithm, both sides MUST 576 disconnect. 578 Note that "none" must be explicitly listed if it is to be 579 acceptable. The defined algorithm names are listed in Section 580 ``Encryption''. 582 mac_algorithms 583 Lists the acceptable MAC algorithms in order of preference. The 584 chosen MAC algorithm MUST be the first algorithm on the client's 585 list that is also on the server's list. If there is no such 586 algorithm, both sides MUST disconnect. 588 Note that "none" must be explicitly listed if it is to be 589 acceptable. The MAC algorithm names are listed in Section ``Data 590 Integrity''. 592 compression_algorithms 593 Lists the acceptable compression algorithms in order of 594 preference. The chosen compression algorithm MUST be the first 595 algorithm on the client's list that is also on the server's list. 596 If there is no such algorithm, both sides MUST disconnect. 598 Note that "none" must be explicitly listed if it is to be 599 acceptable. The compression algorithm names are listed in Section 600 ``Compression''. 602 languages 603 This is a comma-separated list of language tags in order of 604 preference [RFC-1766]. Both parties MAY ignore this list. If there 605 are no language preferences, this list SHOULD be empty. 607 first_kex_packet_follows 608 Indicates whether a guessed key exchange packet follows. If a 609 guessed packet will be sent, this MUST be true. If no guessed 610 packet will be sent, this MUST be false. 612 After receiving the SSH_MSG_KEXINIT packet from the other side, 613 each party will know whether their guess was right. If the other 614 party's guess was wrong, and this field was true, the next packet 615 MUST be silently ignored, and both sides MUST then act as 616 determined by the negotiated key exchange method. If the guess 617 was right, key exchange MUST continue using the guessed packet. 619 After the KEXINIT packet exchange, the key exchange algorithm is run. 620 It may involve several packet exchanges, as specified by the key 621 exchange method. 623 5.2. Output from Key Exchange 625 The key exchange produces two values: a shared secret K, and an exchange 626 hash H. Encryption and authentication keys are derived from these. The 627 exchange hash H from the first key exchange is additionally used as the 628 session identifier, which is a unique identifier for this connection. 630 It is used by authentication methods as a part of the data that is 631 signed as a proof of possession of a private key. Once computed, the 632 session identifier is not changed, even if keys are later re-exchanged. 634 Each key exchange method specifies a hash function that is used in the 635 key exchange. The same hash algorithm MUST be used in key derivation. 636 Here, we'll call it HASH. 638 Encryption keys MUST be computed as HASH of a known value and K as 639 follows: 641 o Initial IV client to server: HASH(K || H || "A" || session_id) (Here 642 K is encoded as mpint and "A" as byte and session_id as raw data."A" 643 means the single character A, ascii 65). 645 o Initial IV server to client: HASH(K || H || "B" || session_id) 647 o Encryption key client to server: HASH(K || H || "C" || session_id) 649 o Encryption key server to client: HASH(K || H || "D" || session_id) 651 o Integrity key client to server: HASH(K || H || "E" || session_id) 653 o Integrity key server to client: HASH(K || H || "F" || session_id) 655 Key data MUST be taken from the beginning of the hash output. 128 bits 656 (16 bytes) SHOULD be used for algorithms with variable-length keys. For 657 other algorithms, as many bytes as are needed are taken from the 658 beginning of the hash value. If the key length in longer than the output 659 of the HASH, the key is extended by computing HASH of the concatenation 660 of K and H and the entire key so far, and appending the resulting bytes 661 (as many as HASH generates) to the key. This process is repeated until 662 enough key material is available; the key is taken from the beginning of 663 this value. In other words, 665 K1 = HASH(K || H || X || session_id) (X is e.g. "A") 666 K2 = HASH(K || H || K1) 667 K3 = HASH(K || H || K1 || K2) 668 ... 669 key = K1 || K2 || K3 || ... 671 5.3. Taking Keys into Use 673 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This 674 message is sent with the old keys and algorithms. All messages sent 675 after this message MUST use the new keys and algorithms. 677 When this message is received, the new keys and algorithms MUST be taken 678 into use for receiving. 680 This message is the only valid message after key exchange, in addition 681 to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. The 682 purpose of this message is to ensure that a party is able to respond 683 with a disconnect message that the other party can understand if 684 something goes wrong with the key exchange. Implementations MUST NOT 685 accept any other messages after key exchange before receiving 686 SSH_MSG_NEWKEYS. 688 byte SSH_MSG_NEWKEYS 690 6. Diffie-Hellman Key Exchange 692 The Diffie-Hellman key exchange provides a shared secret that can not be 693 determined by either party alone. The key exchange is combined with a 694 signature with the host key to provide host authentication. 696 In the following description (C is the client, S is the server; p is a 697 large safe prime, g is a generator for a subgroup of GF(p), and q is the 698 order of the subgroup; V_S is S's version string; V_C is C's version 699 string; K_S is S's public host key; I_C is C's KEXINIT message and I_S 700 S's KEXINIT message which have been exchanged before this part begins): 702 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. 703 C sends "e" to S. 705 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. 706 S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || 707 I_C || I_S || K_S || e || f || K) (these elements are encoded 708 according to their types; see below), and signature s on H with its 709 private host key. S sends "K_S || f || s" to C. The signing 710 operation may involve a second hashing operation. 712 3. C verifies that K_S really is the host key for S (e.g. using 713 certificates or a local database). C is also allowed to accept the 714 key without verification; however, doing so will render the protocol 715 insecure against active attacks (but may be desirable for practical 716 reasons in the short term in many environments). C then computes K = 717 f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), 718 and verifies the signature s on H. 720 Either side MUST NOT send or accept e or f values that are not in the 721 range [1, p-1]. If this condition is violated, the key exchange 722 fails. 724 This is implemented with the following messages. The hash algorithm for 725 computing the exchange hash is defined by the method name, and is called 726 HASH. The public key algorithm for signing is negotiated with the 727 KEXINIT messages. 729 First, the client sends: 731 byte SSH_MSG_KEXDH_INIT 732 mpint e 734 The server responds with: 736 byte SSH_MSG_KEXDH_REPLY 737 string server public host key and certificates (K_S) 738 mpint f 739 string signature of H 741 The hash H is computed as the HASH hash of the concatenation of the 742 following: 744 string V_C, the client's version string (CR and NL excluded) 745 string V_S, the server's version string (CR and NL excluded) 746 string I_C, the payload of the client's SSH_MSG_KEXINIT 747 string I_S, the payload of the server's SSH_MSG_KEXINIT 748 string K_S, the host key 749 mpint e, exchange value sent by the client 750 mpint f, exchange value sent by the server 751 mpint K, the shared secret 753 This value is called the exchange hash, and it is used to authenticate 754 the key exchange. 756 The signature algorithm MUST be applied over H, not the original data. 757 Most signature algorithms include hashing and additional padding. For 758 example, a "ssh-dss" specifies SHA-1 hashing; in that case, the data is 759 first hashed with HASH to compute H, and H is then hashed with SHA-1 as 760 part of the signing operation. 762 6.1. diffie-hellman-group1-sha1 764 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 765 exchange with SHA-1 as HASH, and the following group: 767 The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + 768 129093 ). Its hexadecimal value is 770 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 771 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 772 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 773 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 774 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 775 FFFFFFFF FFFFFFFF. 777 In decimal, this value is 779 179769313486231590770839156793787453197860296048756011706444 780 423684197180216158519368947833795864925541502180565485980503 781 646440548199239100050792877003355816639229553136239076508735 782 759914822574862575007425302077447712589550957937778424442426 783 617334727629299387668709205606050270810842907692932019128194 784 467627007. 786 The generator used with this prime is g = 2. The group order q is (p - 787 1) / 2. 789 This group was taken from the ISAKMP/Oakley specification, and was 790 originally generated by Richard Schroeppel at the University of Arizona. 791 Properties of this prime are described in [Orm96]. 793 7. Key Re-Exchange 795 Key re-exchange is started by sending a SSH_MSG_KEXINIT packet when not 796 already doing a key exchange (as described in Section ``Algorithm 797 Negotiation''). When this message is received, a party MUST respond 798 with its own SSH_MSG_KEXINIT message except when the received 799 SSH_MSG_KEXINIT already was a reply. Either party MAY initiate the re- 800 exchange, but roles MUST NOT be changed (i.e., the server remains the 801 server, and the client remains the client). 803 Key re-exchange is performed using whatever encryption was in effect 804 when the exchange was started. Encryption, compression, and MAC methods 805 are not changed before a new SSH_MSG_NEWKEYS is sent after the key 806 exchange (as in the initial key exchange). Re-exchange is processed 807 identically to the initial key exchange, except for the session 808 identifier that will remain unchanged. It is permissible to change some 809 or all of the algorithms during the re-exchange. Host keys can also 810 change. All keys and initialization vectors are recomputed after the 811 exchange. Compression and encryption contexts are reset. 813 It is recommended that the keys are changed after each gigabyte of 814 transmitted data or after each hour of connection time, whichever comes 815 sooner. However, since the re-exchange is a public key operation, it 816 requires a fair amount of processing power and should not be performed 817 too often. 819 More application data may be sent after the SSH_MSG_NEWKEYS packet has 820 been sent; key exchange does not affect the protocols that lie above the 821 SSH transport layer. 823 8. Service Request 825 After the key exchange, the client requests a service. The service is 826 identified by a name. The format of names and procedures for defining 827 new names are defined in [SSH-ARCH]. 829 Currently, the following names have been reserved: 831 ssh-userauth 832 ssh-connection 834 Similar local naming policy is applied to the service names that is 835 applied to the algorithm names; a local service should use the 836 servicename@domain syntax. 837 byte SSH_MSG_SERVICE_REQUEST 838 string service name 840 If the server rejects the service request, it SHOULD send an appropriate 841 SSH_MSG_DISCONNECT message and MUST disconnect. 843 When the service starts, it may have access to the session identifier 844 generated during the key exchange. 846 If the server supports the service (and permits the client to use it), 847 it MUST respond with 849 byte SSH_MSG_SERVICE_ACCEPT 850 string service name 852 Message numbers used by services should be in the area reserved for them 853 (see Section ``Summary of Message Numbers''). The transport level will 854 continue to process its own messages. 856 Note that after a key exchange with implicit server authentication, the 857 client MUST wait for response to its service request message before 858 sending any further data. 860 9. Additional Messages 862 Either party may send any of the following messages at any time. 864 9.1. Disconnection Message 866 byte SSH_MSG_DISCONNECT 867 uint32 reason code 868 string description [RFC-2044] 869 string language tag [RFC-1766] 871 This message causes immediate termination of the connection. All 872 implementations MUST be able to process this message; they SHOULD be 873 able to send this message. 875 The sender MUST NOT send or receive any data after this message, and the 876 recipient MUST NOT accept any data after receiving this message. The 877 description field gives a more specific explanation in a human-readable 878 form. The error code gives the reason in a more machine-readable format 879 (suitable for localization), and can have the following values: 881 #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 882 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 883 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 884 #define SSH_DISCONNECT_HOST_AUTHENTICATION_FAILED 4 885 #define SSH_DISCONNECT_MAC_ERROR 5 886 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 887 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 888 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 889 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 890 #define SSH_DISCONNECT_CONNECTION_LOST 10 891 #define SSH_DISCONNECT_BY_APPLICATION 11 893 If the description string is displayed, control character filtering 894 discussed in [SSH-ARCH] should be used to avoid attacks by sending 895 terminal control characters. 897 9.2. Ignored Data Message 899 byte SSH_MSG_IGNORE 900 string data 902 All implementations MUST understand (and ignore) this message at any 903 time (after receiving the protocol version). No implementation is 904 required to send them. This message can be used as an additional 905 protection measure against advanced traffic analysis techniques. 907 9.3. Debug Message 909 byte SSH_MSG_DEBUG 910 boolean always_display 911 string message [RFC-2044] 912 string language tag [RFC-1766] 914 All implementations MUST understand this message, but they are allowed 915 to ignore it. This message is used to pass information to the other 916 side that may help debugging. If always_display is true, the message 917 SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 918 debugging information has been explicitly requested by the user. 920 The message doesn't need to contain a newline. It is, however, allowed 921 to consist of multiple lines separated by CRLF (carriage return - line 922 feed) pairs. 924 If the message string is displayed, terminal control character filtering 925 discussed in [SSH-ARCH] should be used to avoid attacks by sending 926 terminal control characters. 928 9.4. Reserved Messages 930 An implementation MUST respond to all unrecognized messages with an 931 SSH_MSG_UNIMPLEMENTED message in the order in which they were received. 932 Such messages MUST be otherwise ignored. Later protocol versions may 933 define other meanings for these message types. 935 byte SSH_MSG_UNIMPLEMENTED 936 uint32 packet sequence number of rejected message 938 10. Summary of Message Numbers 940 The following message numbers have been defined in this protocol. 942 #define SSH_MSG_DISCONNECT 1 943 #define SSH_MSG_IGNORE 2 944 #define SSH_MSG_UNIMPLEMENTED 3 945 #define SSH_MSG_DEBUG 4 946 #define SSH_MSG_SERVICE_REQUEST 5 947 #define SSH_MSG_SERVICE_ACCEPT 6 949 #define SSH_MSG_KEXINIT 20 950 #define SSH_MSG_NEWKEYS 21 952 /* Numbers 30-49 used for kex packets. 953 Different kex methods may reuse message numbers in 954 this range. */ 955 #define SSH_MSG_KEXDH_INIT 30 956 #define SSH_MSG_KEXDH_REPLY 31 958 11. Security Considerations 960 This protocol provides a secure encrypted channel over an unsecure 961 network. It performs server host authentication, key exchange, 962 encryption, and integrity protection. It also derives a unique session 963 id that may be used by higher-level protocols. 965 It is expected that this protocol will sometimes be used without 966 insisting on reliable association between the server host key and the 967 server host name. Such use is inherently insecure, but may be necessary 968 in non-security critical environments, and still provides protection 969 against passive attacks. However, implementors of protocols running on 970 top of this protocol should keep this possibility in mind. 972 This protocol is designed to be used over a reliable transport. If 973 transmission errors or message manipulation occur, the connection is 974 closed. The connection SHOULD be re-established if this occurs. Denial 975 of service attacks of this type ("wire cutter") are almost impossible to 976 avoid. 978 The protocol was not designed to eliminate covert channels. For 979 example, the padding, SSH_MSG_IGNORE messages, and several other places 980 in the protocol can be used to pass covert information, and the 981 recipient has no reliable way to verify whether such information is 982 being sent. 984 12. Trademark Issues 986 SSH is a registered trademark and Secure Shell is a trademark of SSH 987 Communications Security Ltd. SSH Communications Security Ltd permits 988 the use of these trademarks as the name of this standard and protocol, 989 and permits their use to describe that a product conforms to this 990 standard, provided that the following acknowledgement is included 991 where the trademarks are used: ``SSH is a registered trademark and 992 Secure Shell is a trademark of SSH Communications Security Ltd 993 (www.ssh.fi)''. These trademarks may not be used as part of a product 994 name or in otherwise confusing manner without prior written permission 995 of SSH Communications Security Ltd. 997 13. References 999 [FIPS-186] Federal Information Processing Standards Publication (FIPS 1000 PUB) 186, Digital Signature Standard, 18 May 1994. 1002 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 1, 1003 TR97-92, Department of Computer Science Technical Report, University of 1004 Arizona. 1006 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key 1007 Infrastructure, Certificate and CRL Profile", Internet Draft, draft- 1008 ietf-pkix-ipki-part1-11.txt 1010 [RFC-1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 1011 November 1987. 1013 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 1014 March 1995. 1015 [RFC-1950] Deutch, P. and Gailly, J-L., "ZLIB Compressed Data Format 1016 Specification version 3.3", May 1996. 1018 [RFC-1951] Deutch, P., "DEFLATE Compressed Data Format Specification 1019 version 1.3", May 1996. 1021 [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and 1022 ISO 10646", October 1996. 1024 [RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed- 1025 Hashing for Message Authentication", February 1997 1027 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 1028 Requirement Levels", March 1997. 1030 [RFC-2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997. 1032 [RFC-2440] Callas, J., et al, "OpenPGP Message Format", November 1998. 1034 [Schneier] Schneier, B., "Applied Cryptography Second Edition: 1035 protocols, algorithms, and source code in C", 2nd edition, John Wiley & 1036 Sons, New York, NY, 1996. 1038 [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet 1039 Draft, draft-ietf-secsh-architecture-04.txt 1041 [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", 1042 Internet Draft, draft-ietf-secsh-userauth-06.txt 1044 [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet 1045 Draft, draft-ietf-secsh-connect-06.txt 1047 14. Authors' Addresses 1049 Tatu Ylonen 1050 SSH Communications Security Ltd. 1051 Tekniikantie 12 1052 FIN-02150 ESPOO 1053 Finland 1054 E-mail: ylo@ssh.fi 1055 Tero Kivinen 1056 SSH Communications Security Ltd. 1057 Tekniikantie 12 1058 FIN-02150 ESPOO 1059 Finland 1060 E-mail: kivinen@ssh.fi 1062 Markku-Juhani O. Saarinen 1063 SSH Communications Security Ltd. 1064 Tekniikantie 12 1065 FIN-02150 ESPOO 1066 Finland 1067 E-mail: mjos@ssh.fi 1069 Timo J. Rinne 1070 SSH Communications Security Ltd. 1071 Tekniikantie 12 1072 FIN-02150 ESPOO 1073 Finland 1074 E-mail: tri@ssh.fi 1076 Sami Lehtinen 1077 SSH Communications Security Ltd. 1078 Tekniikantie 12 1079 FIN-02150 ESPOO 1080 Finland 1081 E-mail: sjl@ssh.fi