idnits 2.17.1 draft-ietf-secsh-transport-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1348. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 603 has weird spacing: '... string cer...' == Line 616 has weird spacing: '... string sig...' == Line 636 has weird spacing: '... string dss...' == Line 656 has weird spacing: '... string rsa...' == Line 722 has weird spacing: '...me-list kex...' == (19 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 (December 9, 2004) is 7077 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 721 == Unused Reference: 'RFC3280' is defined on line 1266, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-20 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-25 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-23 == Outdated reference: A later version (-12) exists of draft-ietf-secsh-assignednumbers-10 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Downref: Normative reference to an Experimental RFC: RFC 2693 ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-197' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH' -- Obsolete informational reference (is this intentional?): RFC 1134 (Obsoleted by RFC 1171) Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Lonvick, Ed. 2 Internet-Draft Cisco Systems, Inc. 3 Expires: June 9, 2005 December 9, 2004 5 SSH Transport Layer Protocol 6 draft-ietf-secsh-transport-22.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "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 This Internet-Draft will expire on June 9, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 SSH is a protocol for secure remote login and other secure network 42 services over an insecure network. 44 This document describes the SSH transport layer protocol which 45 typically runs on top of TCP/IP. The protocol can be used as a basis 46 for a number of secure network services. It provides strong 47 encryption, server authentication, and integrity protection. It may 48 also provide compression. 50 Key exchange method, public key algorithm, symmetric encryption 51 algorithm, message authentication algorithm, and hash algorithm are 52 all negotiated. 54 This document also describes the Diffie-Hellman key exchange method 55 and the minimal set of algorithms that are needed to implement the 56 SSH transport layer protocol. 58 Table of Contents 60 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Conventions Used in This Document . . . . . . . . . . . . . 4 63 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . 5 65 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . 5 66 5. Compatibility With Old SSH Versions . . . . . . . . . . . . 6 67 5.1 Old Client, New Server . . . . . . . . . . . . . . . . . . 6 68 5.2 New Client, Old Server . . . . . . . . . . . . . . . . . . 7 69 5.3 Packet Size and Overhead . . . . . . . . . . . . . . . . . 7 70 6. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 8 71 6.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . 9 72 6.2 Compression . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . 12 75 6.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . 13 76 6.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . 13 77 7. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . 16 79 7.2 Output from Key Exchange . . . . . . . . . . . . . . . . . 19 80 7.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . 21 81 8. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 21 82 8.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . 23 83 8.2 diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 23 84 9. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 23 85 10. Service Request . . . . . . . . . . . . . . . . . . . . . . 24 86 11. Additional Messages . . . . . . . . . . . . . . . . . . . . 24 87 11.1 Disconnection Message . . . . . . . . . . . . . . . . . 25 88 11.2 Ignored Data Message . . . . . . . . . . . . . . . . . . 26 89 11.3 Debug Message . . . . . . . . . . . . . . . . . . . . . 26 90 11.4 Reserved Messages . . . . . . . . . . . . . . . . . . . 26 91 12. Summary of Message Numbers . . . . . . . . . . . . . . . . . 26 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 93 14. Security Considerations . . . . . . . . . . . . . . . . . . 27 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 15.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . 27 96 15.2 Informative . . . . . . . . . . . . . . . . . . . . . . . 29 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . 29 98 Intellectual Property and Copyright Statements . . . . . . . 30 100 1. Contributors 102 The major original contributors of this set of documents have been: 103 Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 104 Communications Security Corp), and Markku-Juhani O. Saarinen 105 (University of Jyvaskyla). Darren Moffit was the original editor of 106 this set of documents and also made very substantial contributions. 108 Additional contributors to this document include [need list]. 109 Listing their names here does not mean that they endorse this 110 document, but that they have contributed to it. 112 Comments on this internet draft should be sent to the IETF SECSH 113 working group, details at: 114 http://ietf.org/html.charters/secsh-charter.html Note: This paragraph 115 will be removed before this document progresses to become an RFC. 117 2. Introduction 119 The SSH transport layer is a secure low level transport protocol. It 120 provides strong encryption, cryptographic host authentication, and 121 integrity protection. 123 Authentication in this protocol level is host-based; this protocol 124 does not perform user authentication. A higher level protocol for 125 user authentication can be designed on top of this protocol. 127 The protocol has been designed to be simple, flexible, to allow 128 parameter negotiation, and to minimize the number of round-trips. 129 Key exchange method, public key algorithm, symmetric encryption 130 algorithm, message authentication algorithm, and hash algorithm are 131 all negotiated. It is expected that in most environments, only 2 132 round-trips will be needed for full key exchange, server 133 authentication, service request, and acceptance notification of 134 service request. The worst case is 3 round-trips. 136 3. Conventions Used in This Document 138 All documents related to the SSH protocols shall use the keywords 139 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 140 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 141 requirements. These keywords are to be interpreted as described in 142 [RFC2119]. 144 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 145 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 146 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 147 this document when used to describe namespace allocation are to be 148 interpreted as described in [RFC2434]. 150 4. Connection Setup 152 SSH works over any 8-bit clean, binary-transparent transport. The 153 underlying transport SHOULD protect against transmission errors as 154 such errors cause the SSH connection to terminate. 156 The client initiates the connection. 158 4.1 Use over TCP/IP 160 When used over TCP/IP, the server normally listens for connections on 161 port 22. This port number has been registered with the IANA, and has 162 been officially assigned for SSH. 164 4.2 Protocol Version Exchange 166 When the connection has been established, both sides MUST send an 167 identification string. This identification string MUST be 169 SSH-protoversion-softwareversion SP comments CR LF 171 Since the protocol being defined in this set of documents is version 172 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is 173 OPTIONAL. If the 'comments' string is included, a 'space' character 174 (denoted above as SP, ASCII 32) MUST separate the 'softwareversion' 175 and 'comments' strings. The identification MUST be terminated by a 176 single Carriage Return and a single Line Feed character (ASCII 13 and 177 10, respectively). Implementors who wish to maintain compatibility 178 with older, undocumented versions of this protocol, may want to 179 process the identification string without expecting the presence of 180 the carriage return character for reasons described in Section 5 of 181 this document. The null character MUST NOT be sent. The maximum 182 length of the string is 255 characters, including the Carriage Return 183 and Line Feed. 185 The part of the identification string preceding Carriage Return and 186 Line Feed is used in the Diffie-Hellman key exchange (see Section 8). 188 The server MAY send other lines of data before sending the version 189 string. Each line SHOULD be terminated by a Carriage Return and Line 190 Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 191 in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients 192 MUST be able to process such lines. They MAY be silently ignored, or 193 MAY be displayed to the client user. If they are displayed, control 194 character filtering discussed in [SSH-ARCH] SHOULD be used. The 195 primary use of this feature is to allow TCP-wrappers to display an 196 error message before disconnecting. 198 Both the 'protoversion' and 'softwareversion' strings MUST consist of 199 printable US-ASCII characters with the exception of whitespace 200 characters and the minus sign (-). The 'softwareversion' string is 201 primarily used to trigger compatibility extensions and to indicate 202 the capabilities of an implementation. The 'comments' string SHOULD 203 contain additional information that might be useful in solving user 204 problems. As such, an example of a valid identification string is 206 SSH-2.0-billsSSH_3.6.3q3 208 This identification string does not contain the optional 'comments' 209 string and is thusly terminated by a CR and LF immediately after the 210 'softwareversion' string. 212 Key exchange will begin immediately after sending this identifier. 213 All packets following the identification string SHALL use the binary 214 packet protocol which is described in Section 6. 216 5. Compatibility With Old SSH Versions 218 As stated earlier, the 'protoversion' specified for this protocol is 219 "2.0". Earlier versions of this protocol have not been formally 220 documented but it is widely known that they use 'protoversion' of 221 "1.x" (e.g., "1.5" or "1.3"). At the time of this writing, many 222 implementations of SSH are utilizing protocol version 2.0 but it is 223 known that there are still devices using the previous versions. 224 During the transition period, it is important to be able to work in a 225 way that is compatible with the installed SSH clients and servers 226 that use the older version of the protocol. Information in this 227 section is only relevant for implementations supporting compatibility 228 with SSH versions 1.x. For those interested, the only known 229 documentation of the 1.x protocol is contained in README files that 230 are shipped along with the source code. [ssh-1.2.30] 232 5.1 Old Client, New Server 234 Server implementations MAY support a configurable "compatibility" 235 flag that enables compatibility with old versions. When this flag is 236 on, the server SHOULD identify its protocol version as "1.99". 237 Clients using protocol 2.0 MUST be able to identify this as identical 238 to "2.0". In this mode the server SHOULD NOT send the carriage 239 return character (ASCII 13) after the version identification string. 241 In the compatibility mode the server SHOULD NOT send any further data 242 after its initialization string until it has received an 243 identification string from the client. The server can then determine 244 whether the client is using an old protocol, and can revert to the 245 old protocol if required. In the compatibility mode, the server MUST 246 NOT send additional data before the version string. 248 When compatibility with old clients is not needed, the server MAY 249 send its initial key exchange data immediately after the 250 identification string. 252 5.2 New Client, Old Server 254 Since the new client MAY immediately send additional data after its 255 identification string (before receiving server's identification), the 256 old protocol may already have been corrupted when the client learns 257 that the server is old. When this happens, the client SHOULD close 258 the connection to the server, and reconnect using the old protocol. 260 5.3 Packet Size and Overhead 262 Some readers will worry about the increase in packet size due to new 263 headers, padding, and Message Authentication Code (MAC). The minimum 264 packet size is in the order of 28 bytes (depending on negotiated 265 algorithms). The increase is negligible for large packets, but very 266 significant for one-byte packets (telnet-type sessions). There are, 267 however, several factors that make this a non-issue in almost all 268 cases: 269 o The minimum size of a TCP/IP header is 32 bytes. Thus, the 270 increase is actually from 33 to 51 bytes (roughly). 271 o The minimum size of the data field of an Ethernet packet is 46 272 bytes [RFC0894]. Thus, the increase is no more than 5 bytes. 273 When Ethernet headers are considered, the increase is less than 10 274 percent. 275 o The total fraction of telnet-type data in the Internet is 276 negligible, even with increased packet sizes. 278 The only environment where the packet size increase is likely to have 279 a significant effect is PPP [RFC1134] over slow modem lines (PPP 280 compresses the TCP/IP headers, emphasizing the increase in packet 281 size). However, with modern modems, the time needed to transfer is 282 in the order of 2 milliseconds, which is a lot faster than people can 283 type. 285 There are also issues related to the maximum packet size. To 286 minimize delays in screen updates, one does not want excessively 287 large packets for interactive sessions. The maximum packet size is 288 negotiated separately for each channel. 290 6. Binary Packet Protocol 292 Each packet is in the following format: 294 uint32 packet_length 295 byte padding_length 296 byte[n1] payload; n1 = packet_length - padding_length - 1 297 byte[n2] random padding; n2 = padding_length 298 byte[m] MAC (Message Authentication Code); m = mac_length 300 packet_length 301 The length of the packet in bytes, not including the Message 302 Authentication Code (MAC) or the packet_length field itself. 304 padding_length 305 Length of padding (bytes). 307 payload 308 The useful contents of the packet. If compression has been 309 negotiated, this field is compressed. Initially, compression 310 MUST be "none". 312 random padding 313 Arbitrary-length padding, such that the total length of 314 (packet_length || padding_length || payload || padding) is a 315 multiple of the cipher block size or 8, whichever is larger. 316 There MUST be at least four bytes of padding. The padding 317 SHOULD consist of random bytes. The maximum amount of padding 318 is 255 bytes. 320 mac 321 Message Authentication Code. If message authentication has 322 been negotiated, this field contains the MAC bytes. Initially, 323 the MAC algorithm MUST be "none". 325 Note that length of the concatenation of packet length, padding 326 length, payload, and padding MUST be a multiple of the cipher block 327 size or 8, whichever is larger. This constraint MUST be enforced 328 even when using stream ciphers. Note that the packet length field is 329 also encrypted, and processing it requires special care when sending 330 or receiving packets. 332 The minimum size of a packet is 16 (or the cipher block size, 333 whichever is larger) bytes (plus MAC). Implementations SHOULD 334 decrypt the length after receiving the first 8 (or cipher block size, 335 whichever is larger) bytes of a packet. 337 6.1 Maximum Packet Length 339 All implementations MUST be able to process packets with uncompressed 340 payload length of 32768 bytes or less and total packet size of 35000 341 bytes or less (including length, padding length, payload, padding, 342 and MAC). The maximum of 35000 bytes is an arbitrary chosen value 343 larger than uncompressed size. Implementations SHOULD support longer 344 packets, where they might be needed. For example: if an 345 implementation wants to send a very large number of certificates, the 346 larger packets MAY be sent if the version string indicates that the 347 other party is able to process them. However, implementations SHOULD 348 check that the packet length is reasonable for the implementation to 349 avoid denial-of-service and/or buffer overflow attacks. 351 6.2 Compression 353 If compression has been negotiated, the payload field (and only it) 354 will be compressed using the negotiated algorithm. The length field 355 and MAC will be computed from the compressed payload. Encryption 356 will be done after compression. 358 Compression MAY be stateful, depending on the method. Compression 359 MUST be independent for each direction, and implementations MUST 360 allow independently choosing the algorithm for each direction. In 361 practice however, it is RECOMMENDED that the compression method be 362 the same in both directions. 364 The following compression methods are currently defined: 366 none REQUIRED no compression 367 zlib OPTIONAL ZLIB (LZ77) compression 369 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 370 The compression context is initialized after each key exchange, and 371 is passed from one packet to the next with only a partial flush being 372 performed at the end of each packet. A partial flush means that the 373 current compressed block is ended and all data will be output. If 374 the current block is not a stored block, one or more empty blocks are 375 added after the current block to ensure that there are at least 8 376 bits counting from the start of the end-of-block code of the current 377 block to the end of the packet payload. 379 Additional methods may be defined as specified in [SSH-ARCH] and 380 [SSH-NUMBERS]. 382 6.3 Encryption 384 An encryption algorithm and a key will be negotiated during the key 385 exchange. When encryption is in effect, the packet length, padding 386 length, payload and padding fields of each packet MUST be encrypted 387 with the given algorithm. 389 The encrypted data in all packets sent in one direction SHOULD be 390 considered a single data stream. For example: initialization vectors 391 SHOULD be passed from the end of one packet to the beginning of the 392 next packet. All ciphers SHOULD use keys with an effective key 393 length of 128 bits or more. 395 The ciphers in each direction MUST run independent of each other. 396 Implementations MUST allow the algorithm for each direction to be 397 independently selected, if multiple algorithms are allowed by local 398 policy. In practice however, it is RECOMMENDED that the same 399 algorithm be used in both directions. 401 The following ciphers are currently defined: 403 3des-cbc REQUIRED three-key 3DES in CBC mode 404 blowfish-cbc OPTIONAL Blowfish in CBC mode 405 twofish256-cbc OPTIONAL Twofish in CBC mode, 406 with 256-bit key 407 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 408 is being retained for 409 historical reasons) 410 twofish192-cbc OPTIONAL Twofish with 192-bit key 411 twofish128-cbc OPTIONAL Twofish with 128-bit key 412 aes256-cbc OPTIONAL AES in CBC mode, 413 with 256-bit key 414 aes192-cbc OPTIONAL AES with 192-bit key 415 aes128-cbc RECOMMENDED AES with 128-bit key 416 serpent256-cbc OPTIONAL Serpent in CBC mode, with 417 256-bit key 418 serpent192-cbc OPTIONAL Serpent with 192-bit key 419 serpent128-cbc OPTIONAL Serpent with 128-bit key 420 arcfour OPTIONAL the ARCFOUR stream cipher 421 idea-cbc OPTIONAL IDEA in CBC mode 422 cast128-cbc OPTIONAL CAST-128 in CBC mode 423 none OPTIONAL no encryption; NOT RECOMMENDED 425 The "3des-cbc" cipher is three-key triple-DES 426 (encrypt-decrypt-encrypt), where the first 8 bytes of the key are 427 used for the first encryption, the next 8 bytes for the decryption, 428 and the following 8 bytes for the final encryption. This requires 24 429 bytes of key data (of which 168 bits are actually used). To 430 implement CBC mode, outer chaining MUST be used (i.e., there is only 431 one initialization vector). This is a block cipher with 8 byte 432 blocks. This algorithm is defined in [FIPS-46-3]. Note that since 433 this algorithm only has an effective key length of 112 bits 434 ([SCHNEIER]), it does not meet the specifications that SSH encryption 435 algorithms should use keys of 128 bits or more. However, this 436 algorithm is still REQUIRED for historical reasons; essentially, all 437 known implementations at the time of this writing support this 438 algorithm, and it is commonly used because it is the fundamental 439 interoperable algorithm. At some future time it is expected that 440 another algorithm, one with better strength, will become so prevalent 441 and ubiquitous that the use of "3des-cbc" will be deprecated by 442 another STANDARDS ACTION. 444 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 445 [SCHNEIER]. This is a block cipher with 8 byte blocks. 447 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 448 with 256 bit keys as described [TWOFISH]. This is a block cipher 449 with 16 byte blocks. 451 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 453 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 455 The "aes256-cbc" cipher is AES (Advanced Encryption Standard) 456 [FIPS-197], in CBC mode. This version uses 256-bit key. 458 The "aes192-cbc" cipher. Same as above but with 192-bit key. 460 The "aes128-cbc" cipher. Same as above but with 128-bit key. 462 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as 463 described in the Serpent AES submission. 465 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 467 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 469 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 470 Arcfour cipher is believed to be compatible with the RC4 cipher 471 [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. 472 Arcfour (and RC4) has problems with weak keys, and should be used 473 with caution. 475 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 477 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 478 [RFC2144]. 480 The "none" algorithm specifies that no encryption is to be done. 482 Note that this method provides no confidentiality protection, and it 483 is not recommended. Some functionality (e.g., password 484 authentication) may be disabled for security reasons if this cipher 485 is chosen. 487 Additional methods may be defined as specified in [SSH-ARCH] and in 488 [SSH-NUMBERS]. 490 6.4 Data Integrity 492 Data integrity is protected by including with each packet a message 493 authentication code (MAC) that is computed from a shared secret, 494 packet sequence number, and the contents of the packet. 496 The message authentication algorithm and key are negotiated during 497 key exchange. Initially, no MAC will be in effect, and its length 498 MUST be zero. After key exchange, the selected MAC will be computed 499 before encryption from the concatenation of packet data: 501 mac = MAC(key, sequence_number || unencrypted_packet) 503 where unencrypted_packet is the entire packet without MAC (the length 504 fields, payload and padding), and sequence_number is an implicit 505 packet sequence number represented as uint32. The sequence number is 506 initialized to zero for the first packet, and is incremented after 507 every packet (regardless of whether encryption or MAC is in use). It 508 is never reset, even if keys/algorithms are renegotiated later. It 509 wraps around to zero after every 2^32 packets. The packet sequence 510 number itself is not included in the packet sent over the wire. 512 The MAC algorithms for each direction MUST run independently, and 513 implementations MUST allow choosing the algorithm independently for 514 both directions. 516 The MAC bytes resulting from the MAC algorithm MUST be transmitted 517 without encryption as the last part of the packet. The number of MAC 518 bytes depends on the algorithm chosen. 520 The following MAC algorithms are currently defined: 522 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 523 length = 20) 524 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 525 length = 12, key length = 20) 526 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 527 length = 16) 528 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 529 length = 12, key length = 16) 531 none OPTIONAL no MAC; NOT RECOMMENDED 533 Figure 1 535 The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs 536 use only the first n bits of the resulting value. 538 The hash algorithms are described in [SCHNEIER]. 540 Additional methods may be defined as specified in [SSH-ARCH] and in 541 [SSH-NUMBERS]. 543 6.5 Key Exchange Methods 545 The key exchange method specifies how one-time session keys are 546 generated for encryption and for authentication, and how the server 547 authentication is done. 549 Two REQUIRED key exchange methods have been defined: 551 diffie-hellman-group1-sha1 REQUIRED 552 diffie-hellman-group14-sha1 REQUIRED 554 These methods are described later in this document. 556 Additional methods may be defined as specified in [SSH-NUMBERS]. 557 Note that, for historical reasons, the name 558 "diffie-hellman-group1-sha1" is used for a key exchange method using 559 an Oakley group as defined in [RFC2412]. Subsequently, the Working 560 Group attempted to follow the numbering scheme of group numbers from 561 [RFC3526] with diffie-hellman-group14-sha1 for the name of the second 562 defined name. This is considered an aberration and should not be 563 repeated. Any future specifications of Diffie-Hellman key exchange 564 using Oakley groups defined in [RFC2412] or its successors should be 565 performed with care and a bit of research. 567 6.6 Public Key Algorithms 569 This protocol has been designed to be able to operate with almost any 570 public key format, encoding, and algorithm (signature and/or 571 encryption). 573 There are several aspects that define a public key type: 574 o Key format: how is the key encoded and how are certificates 575 represented. The key blobs in this protocol MAY contain 576 certificates in addition to keys. 577 o Signature and/or encryption algorithms. Some key types may not 578 support both signing and encryption. Key usage may also be 579 restricted by policy statements - e.g., in certificates. In this 580 case, different key types SHOULD be defined for the different 581 policy alternatives. 582 o Encoding of signatures and/or encrypted data. This includes but 583 is not limited to padding, byte order, and data formats. 585 The following public key and/or certificate formats are currently 586 defined: 588 ssh-dss REQUIRED sign Raw DSS Key 589 ssh-rsa RECOMMENDED sign Raw RSA Key 590 spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) 591 spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) 592 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 593 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 595 Additional key types may be defined as specified in [SSH-ARCH] and in 596 [SSH-NUMBERS]. 598 The key type MUST always be explicitly known (from algorithm 599 negotiation or some other source). It is not normally included in 600 the key blob. 602 Certificates and public keys are encoded as follows: 603 string certificate or public key format identifier 604 byte[n] key/certificate data 606 The certificate part may have be a zero length string, but a public 607 key is required. This is the public key that will be used for 608 authentication. The certificate sequence contained in the 609 certificate blob can be used to provide authorization. 611 Public key / certificate formats that do not explicitly specify a 612 signature format identifier MUST use the public key / certificate 613 format identifier as the signature identifier. 615 Signatures are encoded as follows: 616 string signature format identifier (as specified by the 617 public key / cert format) 618 byte[n] signature blob in format specific encoding. 620 The "ssh-dss" key format has the following specific encoding: 622 string "ssh-dss" 623 mpint p 624 mpint q 625 mpint g 626 mpint y 628 Here the p, q, g, and y parameters form the signature key blob. 630 Signing and verifying using this key format is done according to the 631 Digital Signature Standard [FIPS-186-2] using the SHA-1 hash. 633 The resulting signature is encoded as follows: 635 string "ssh-dss" 636 string dss_signature_blob 638 dss_signature_blob is encoded as a string containing r followed by s 639 (which are 160 bits long integers, without lengths or padding, 640 unsigned and in network byte order). 642 The "ssh-rsa" key format has the following specific encoding: 644 string "ssh-rsa" 645 mpint e 646 mpint n 648 Here the e and n parameters form the signature key blob. 650 Signing and verifying using this key format is done according to 651 [SCHNEIER] and [RFC3447] using the SHA-1 hash. 653 The resulting signature is encoded as follows: 655 string "ssh-rsa" 656 string rsa_signature_blob 658 rsa_signature_blob is encoded as a string containing s (which is an 659 integer, without lengths or padding, unsigned and in network byte 660 order). 662 The "spki-sign-rsa" method indicates that the certificate blob 663 contains a sequence of SPKI certificates. The format of SPKI 664 certificates is described in [RFC2693]. This method indicates that 665 the key (or one of the keys in the certificate) is an RSA-key. 667 The "spki-sign-dss". As above, but indicates that the key (or one of 668 the keys in the certificate) is a DSS-key. 670 The "pgp-sign-rsa" method indicates the certificates, the public key, 671 and the signature are in OpenPGP compatible binary format 672 ([RFC2440]). This method indicates that the key is an RSA-key. 674 The "pgp-sign-dss". As above, but indicates that the key is a 675 DSS-key. 677 7. Key Exchange 679 Key exchange (kex) begins by each side sending name-lists of 680 supported algorithms. Each side has a preferred algorithm in each 681 category, and it is assumed that most implementations at any given 682 time will use the same preferred algorithm. Each side MAY guess 683 which algorithm the other side is using, and MAY send an initial key 684 exchange packet according to the algorithm if appropriate for the 685 preferred method. 687 The guess is considered wrong, if: 688 o the kex algorithm and/or the host key algorithm is guessed wrong 689 (server and client have different preferred algorithm), or 690 o if any of the other algorithms cannot be agreed upon (the 691 procedure is defined below in Section 7.1). 693 Otherwise, the guess is considered to be right and the optimistically 694 sent packet MUST be handled as the first key exchange packet. 696 However, if the guess was wrong, and a packet was optimistically sent 697 by one or both parties, such packets MUST be ignored (even if the 698 error in the guess would not affect the contents of the initial 699 packet(s)), and the appropriate side MUST send the correct initial 700 packet. 702 A key exchange method uses "explicit server authentication" if the 703 key exchange messages include a signature or other proof of the 704 server's authenticity. A key exchange method uses "implicit server 705 authentication" if, in order to prove its authenticity, the server 706 also has to prove that it knows the shared secret K, by sending a 707 message and a corresponding MAC which the client can verify. 709 The key exchange method defined by this document uses explicit server 710 authentication. However, key exchange methods with implicit server 711 authentication MAY be used with this protocol. After a key exchange 712 with implicit server authentication, the client MUST wait for 713 response to its service request message before sending any further 714 data. 716 7.1 Algorithm Negotiation 718 Key exchange begins by each side sending the following packet: 720 byte SSH_MSG_KEXINIT 721 byte[16] cookie (random bytes) 722 name-list kex_algorithms 723 name-list server_host_key_algorithms 724 name-list encryption_algorithms_client_to_server 725 name-list encryption_algorithms_server_to_client 726 name-list mac_algorithms_client_to_server 727 name-list mac_algorithms_server_to_client 728 name-list compression_algorithms_client_to_server 729 name-list compression_algorithms_server_to_client 730 name-list languages_client_to_server 731 name-list languages_server_to_client 732 boolean first_kex_packet_follows 733 uint32 0 (reserved for future extension) 735 Each of the algorithm name-lists MUST be a comma-separated list of 736 algorithm names - see Algorithm Naming in [SSH-ARCH] and additional 737 information in [SSH-NUMBERS]. Each supported (allowed) algorithm 738 MUST be listed in order of preference, from most to least. 740 The first algorithm in each name-list MUST be the preferred (guessed) 741 algorithm. Each name-list MUST contain at least one algorithm name. 743 cookie 744 The cookie MUST be a random value generated by the sender. Its 745 purpose is to make it impossible for either side to fully 746 determine the keys and the session identifier. 748 kex_algorithms 749 Key exchange algorithms were defined above. The first 750 algorithm MUST be the preferred (and guessed) algorithm. If 751 both sides make the same guess, that algorithm MUST be used. 752 Otherwise, the following algorithm MUST be used to choose a key 753 exchange method: Iterate over client's kex algorithms, one at a 754 time. Choose the first algorithm that satisfies the following 755 conditions: 756 + the server also supports the algorithm, 757 + if the algorithm requires an encryption-capable host key, 758 there is an encryption-capable algorithm on the server's 759 server_host_key_algorithms that is also supported by the 760 client, and 761 + if the algorithm requires a signature-capable host key, 762 there is a signature-capable algorithm on the server's 763 server_host_key_algorithms that is also supported by the 764 client. 765 If no algorithm satisfying all these conditions can be found, 766 the connection fails, and both sides MUST disconnect. 768 server_host_key_algorithms 769 A name-list of the algorithms supported for the server host 770 key. The server lists the algorithms for which it has host 771 keys; the client lists the algorithms that it is willing to 772 accept. (There MAY be multiple host keys for a host, possibly 773 with different algorithms.) 775 Some host keys may not support both signatures and encryption 776 (this can be determined from the algorithm), and thus not all 777 host keys are valid for all key exchange methods. 779 Algorithm selection depends on whether the chosen key exchange 780 algorithm requires a signature or encryption capable host key. 781 It MUST be possible to determine this from the public key 782 algorithm name. The first algorithm on the client's name-list 783 that satisfies the requirements and is also supported by the 784 server MUST be chosen. If there is no such algorithm, both 785 sides MUST disconnect. 787 encryption_algorithms 788 A name-list of acceptable symmetric encryption algorithms in 789 order of preference. The chosen encryption algorithm to each 790 direction MUST be the first algorithm on the client's name-list 791 that is also on the server's name-list. If there is no such 792 algorithm, both sides MUST disconnect. 794 Note that "none" must be explicitly listed if it is to be 795 acceptable. The defined algorithm names are listed in Section 796 6.3. 798 mac_algorithms 799 A name-list of acceptable MAC algorithms in order of 800 preference. The chosen MAC algorithm MUST be the first 801 algorithm on the client's name-list that is also on the 802 server's name-list. If there is no such algorithm, both sides 803 MUST disconnect. 805 Note that "none" must be explicitly listed if it is to be 806 acceptable. The MAC algorithm names are listed in Section 807 Figure 1. 809 compression_algorithms 810 A name-list of acceptable compression algorithms in order of 811 preference. The chosen compression algorithm MUST be the first 812 algorithm on the client's name-list that is also on the 813 server's name-list. If there is no such algorithm, both sides 814 MUST disconnect. 816 Note that "none" must be explicitly listed if it is to be 817 acceptable. The compression algorithm names are listed in 818 Section 6.2. 820 languages 821 This is a name-list of language tags in order of preference 822 [RFC3066]. Both parties MAY ignore this name-list. If there 823 are no language preferences, this name-list SHOULD be empty as 824 defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT 825 be present unless they are known to be needed by the sending 826 party. 828 first_kex_packet_follows 829 Indicates whether a guessed key exchange packet follows. If a 830 guessed packet will be sent, this MUST be TRUE. If no guessed 831 packet will be sent, this MUST be FALSE. 833 After receiving the SSH_MSG_KEXINIT packet from the other side, 834 each party will know whether their guess was right. If the 835 other party's guess was wrong, and this field was TRUE, the 836 next packet MUST be silently ignored, and both sides MUST then 837 act as determined by the negotiated key exchange method. If 838 the guess was right, key exchange MUST continue using the 839 guessed packet. 841 After the KEXINIT packet exchange, the key exchange algorithm is run. 842 It may involve several packet exchanges, as specified by the key 843 exchange method. 845 Once a party has sent a KEXINIT message for key exchange or 846 re-exchange, until is has sent a NEWKEYS message (Section 7.3), it 847 MUST NOT send any messages other than: 848 o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST 849 and SERVICE_ACCEPT MUST NOT be sent); 850 o Algorithm negotiation messages (20 to 29) (but further KEXINITs 851 MUST NOT be sent); 852 o Specific key exchange method messages (30 to 49). 854 The provisions of Section 11 apply to unrecognized messages. 856 Note however that during a key re-exchange, after sending a KEXINIT 857 message, each party MUST be prepared to process an arbitrary number 858 of messages that may be in-flight before receiving a KEXINIT from the 859 other party. 861 7.2 Output from Key Exchange 863 The key exchange produces two values: a shared secret K, and an 864 exchange hash H. Encryption and authentication keys are derived from 865 these. The exchange hash H from the first key exchange is 866 additionally used as the session identifier, which is a unique 867 identifier for this connection. It is used by authentication methods 868 as a part of the data that is signed as a proof of possession of a 869 private key. Once computed, the session identifier is not changed, 870 even if keys are later re-exchanged. 872 Each key exchange method specifies a hash function that is used in 873 the key exchange. The same hash algorithm MUST be used in key 874 derivation. Here, we'll call it HASH. 876 Encryption keys MUST be computed as HASH of a known value and K as 877 follows: 878 o Initial IV client to server: HASH(K || H || "A" || session_id) 879 (Here K is encoded as mpint and "A" as byte and session_id as raw 880 data. "A" means the single character A, ASCII 65). 881 o Initial IV server to client: HASH(K || H || "B" || session_id) 882 o Encryption key client to server: HASH(K || H || "C" || session_id) 883 o Encryption key server to client: HASH(K || H || "D" || session_id) 884 o Integrity key client to server: HASH(K || H || "E" || session_id) 885 o Integrity key server to client: HASH(K || H || "F" || session_id) 887 Key data MUST be taken from the beginning of the hash output. 128 888 bits (16 bytes) MUST be used for algorithms with variable-length 889 keys. The only variable key length algorithm defined in this 890 document is arcfour). For other algorithms, as many bytes as are 891 needed are taken from the beginning of the hash value. If the key 892 length needed is longer than the output of the HASH, the key is 893 extended by computing HASH of the concatenation of K and H and the 894 entire key so far, and appending the resulting bytes (as many as HASH 895 generates) to the key. This process is repeated until enough key 896 material is available; the key is taken from the beginning of this 897 value. In other words: 899 K1 = HASH(K || H || X || session_id) (X is e.g., "A") 900 K2 = HASH(K || H || K1) 901 K3 = HASH(K || H || K1 || K2) 902 ... 903 key = K1 || K2 || K3 || ... 905 This process will lose entropy if the amount of entropy in K is 906 larger than the internal state size of HASH. 908 7.3 Taking Keys Into Use 910 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 911 This message is sent with the old keys and algorithms. All messages 912 sent after this message MUST use the new keys and algorithms. 914 When this message is received, the new keys and algorithms MUST be 915 taken into use for receiving. 917 The purpose of this message is to ensure that a party is able to 918 respond with a SSH_MSG_DISCONNECT message that the other party can 919 understand if something goes wrong with the key exchange. 921 byte SSH_MSG_NEWKEYS 923 8. Diffie-Hellman Key Exchange 925 The Diffie-Hellman (DH) key exchange provides a shared secret that 926 can not be determined by either party alone. The key exchange is 927 combined with a signature with the host key to provide host 928 authentication. This key exchange method provides explicit server 929 authentication as is defined in Section 7. 931 In the following description (C is the client, S is the server; p is 932 a large safe prime, g is a generator for a subgroup of GF(p), and q 933 is the order of the subgroup; V_S is S's version string; V_C is C's 934 version string; K_S is S's public host key; I_C is C's KEXINIT 935 message and I_S S's KEXINIT message which have been exchanged before 936 this part begins): 938 1. C generates a random number x (1 < x < q) and computes e = g^x 939 mod p. C sends "e" to S. 941 2. S generates a random number y (0 < y < q) and computes f = g^y 942 mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C 943 || V_S || I_C || I_S || K_S || e || f || K) (these elements are 944 encoded according to their types; see below), and signature s on 945 H with its private host key. S sends "K_S || f || s" to C. The 946 signing operation may involve a second hashing operation. 948 3. C verifies that K_S really is the host key for S (e.g., using 949 certificates or a local database). C is also allowed to accept 950 the key without verification; however, doing so will render the 951 protocol insecure against active attacks (but may be desirable 952 for practical reasons in the short term in many environments). C 953 then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || 954 K_S || e || f || K), and verifies the signature s on H. 956 Either side MUST NOT send or accept e or f values that are not in the 957 range [1, p-1]. If this condition is violated, the key exchange 958 fails. 960 This is implemented with the following messages. The hash algorithm 961 for computing the exchange hash is defined by the method name, and is 962 called HASH. The public key algorithm for signing is negotiated with 963 the KEXINIT messages. 965 First, the client sends the following: 967 byte SSH_MSG_KEXDH_INIT 968 mpint e 970 The server responds with the following: 972 byte SSH_MSG_KEXDH_REPLY 973 string server public host key and certificates (K_S) 974 mpint f 975 string signature of H 977 The hash H is computed as the HASH hash of the concatenation of the 978 following: 980 string V_C, the client's version string (CR and NL excluded) 981 string V_S, the server's version string (CR and NL excluded) 982 string I_C, the payload of the client's SSH_MSG_KEXINIT 983 string I_S, the payload of the server's SSH_MSG_KEXINIT 984 string K_S, the host key 985 mpint e, exchange value sent by the client 986 mpint f, exchange value sent by the server 987 mpint K, the shared secret 989 This value is called the exchange hash, and it is used to 990 authenticate the key exchange. The exchange hash SHOULD be kept 991 secret. 993 The signature algorithm MUST be applied over H, not the original 994 data. Most signature algorithms include hashing and additional 995 padding - for example, "ssh-dss" specifies SHA-1 hashing. In that 996 case, the data is first hashed with HASH to compute H, and H is then 997 hashed with SHA-1 as part of the signing operation. 999 8.1 diffie-hellman-group1-sha1 1001 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 1002 exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit 1003 MODP Group). This method MUST be supported for interoperability as 1004 all of the known implementations currently support it. Note that, 1005 for historical reasons, this method is named using the phrase 1006 "group1" even though it specifies the use of Oakley Group 2. 1008 8.2 diffie-hellman-group14-sha1 1010 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key 1011 exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit 1012 MODP Group), and it MUST also be supported. 1014 9. Key Re-Exchange 1016 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when 1017 not already doing a key exchange (as described in Section 7.1). When 1018 this message is received, a party MUST respond with its own 1019 SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT 1020 already was a reply. Either party MAY initiate the re-exchange, but 1021 roles MUST NOT be changed (i.e., the server remains the server, and 1022 the client remains the client). 1024 Key re-exchange is performed using whatever encryption was in effect 1025 when the exchange was started. Encryption, compression, and MAC 1026 methods are not changed before a new SSH_MSG_NEWKEYS is sent after 1027 the key exchange (as in the initial key exchange). Re-exchange is 1028 processed identically to the initial key exchange, except for the 1029 session identifier that will remain unchanged. It is permissible to 1030 change some or all of the algorithms during the re-exchange. Host 1031 keys can also change. All keys and initialization vectors are 1032 recomputed after the exchange. Compression and encryption contexts 1033 are reset. 1035 It is recommended that the keys are changed after each gigabyte of 1036 transmitted data or after each hour of connection time, whichever 1037 comes sooner. However, since the re-exchange is a public key 1038 operation, it requires a fair amount of processing power and should 1039 not be performed too often. 1041 More application data may be sent after the SSH_MSG_NEWKEYS packet 1042 has been sent; key exchange does not affect the protocols that lie 1043 above the SSH transport layer. 1045 10. Service Request 1047 After the key exchange, the client requests a service. The service 1048 is identified by a name. The format of names and procedures for 1049 defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS]. 1051 Currently, the following names have been reserved: 1053 ssh-userauth 1054 ssh-connection 1056 Similar local naming policy is applied to the service names, as is 1057 applied to the algorithm names. A local service should use the 1058 PRIVATE USE syntax of "servicename@domain". 1060 byte SSH_MSG_SERVICE_REQUEST 1061 string service name 1063 If the server rejects the service request, it SHOULD send an 1064 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 1066 When the service starts, it may have access to the session identifier 1067 generated during the key exchange. 1069 If the server supports the service (and permits the client to use 1070 it), it MUST respond with the following: 1072 byte SSH_MSG_SERVICE_ACCEPT 1073 string service name 1075 Message numbers used by services should be in the area reserved for 1076 them (see [SSH-ARCH]) and [SSH-NUMBERS]. The transport level will 1077 continue to process its own messages. 1079 Note that after a key exchange with implicit server authentication, 1080 the client MUST wait for response to its service request message 1081 before sending any further data. 1083 11. Additional Messages 1085 Either party may send any of the following messages at any time. 1087 11.1 Disconnection Message 1088 byte SSH_MSG_DISCONNECT 1089 uint32 reason code 1090 string description [RFC3629] 1091 string language tag [RFC3066] 1093 This message causes immediate termination of the connection. All 1094 implementations MUST be able to process this message; they SHOULD be 1095 able to send this message. 1097 The sender MUST NOT send or receive any data after this message, and 1098 the recipient MUST NOT accept any data after receiving this message. 1099 The Disconnection Message 'description' string gives a more specific 1100 explanation in a human-readable form. The Disconnection Message 1101 'reason code' gives the reason in a more machine-readable format 1102 (suitable for localization), and can have the values as displayed in 1103 the table below. Note that the decimal representation is displayed 1104 in this table for readability but that the values are actually uint32 1105 values. 1107 description reason code 1108 ----------- ----------- 1109 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 1110 SSH_DISCONNECT_PROTOCOL_ERROR 2 1111 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 1112 SSH_DISCONNECT_RESERVED 4 1113 SSH_DISCONNECT_MAC_ERROR 5 1114 SSH_DISCONNECT_COMPRESSION_ERROR 6 1115 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1116 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1117 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1118 SSH_DISCONNECT_CONNECTION_LOST 10 1119 SSH_DISCONNECT_BY_APPLICATION 11 1120 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1121 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1122 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1123 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1125 If the 'description' string is displayed, control character filtering 1126 discussed in [SSH-ARCH] should be used to avoid attacks by sending 1127 terminal control characters. 1129 Requests for assignments of new Disconnection Message 'reason code' 1130 values (and associated 'description' text) in the range of 0x00000010 1131 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 1132 described in [RFC2434]. The Disconnection Message 'reason code' 1133 values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for 1134 PRIVATE USE. As is noted, the actual instructions to the IANA are in 1136 [SSH-NUMBERS]. 1138 11.2 Ignored Data Message 1139 byte SSH_MSG_IGNORE 1140 string data 1142 All implementations MUST understand (and ignore) this message at any 1143 time (after receiving the protocol version). No implementation is 1144 required to send them. This message can be used as an additional 1145 protection measure against advanced traffic analysis techniques. 1147 11.3 Debug Message 1148 byte SSH_MSG_DEBUG 1149 boolean always_display 1150 string message [RFC3629] 1151 string language tag [RFC3066] 1153 All implementations MUST understand this message, but they are 1154 allowed to ignore it. This message is used to transmit information 1155 that may help debugging. If always_display is TRUE, the message 1156 SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 1157 debugging information has been explicitly requested by the user. 1159 The message doesn't need to contain a newline. It is, however, 1160 allowed to consist of multiple lines separated by CRLF (Carriage 1161 Return - Line Feed) pairs. 1163 If the message string is displayed, terminal control character 1164 filtering discussed in [SSH-ARCH] should be used to avoid attacks by 1165 sending terminal control characters. 1167 11.4 Reserved Messages 1169 An implementation MUST respond to all unrecognized messages with an 1170 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1171 received. Such messages MUST be otherwise ignored. Later protocol 1172 versions may define other meanings for these message types. 1173 byte SSH_MSG_UNIMPLEMENTED 1174 uint32 packet sequence number of rejected message 1176 12. Summary of Message Numbers 1178 The following message numbers have been defined in this protocol: 1180 SSH_MSG_DISCONNECT 1 1181 SSH_MSG_IGNORE 2 1182 SSH_MSG_UNIMPLEMENTED 3 1183 SSH_MSG_DEBUG 4 1184 SSH_MSG_SERVICE_REQUEST 5 1185 SSH_MSG_SERVICE_ACCEPT 6 1186 SSH_MSG_KEXINIT 20 1187 SSH_MSG_NEWKEYS 21 1188 SSH_MSG_KEXDH_INIT 30 1189 SSH_MSG_KEXDH_REPLY 31 1191 Note that Numbers 30-49 are used for kex packets. Different kex 1192 methods may reuse message numbers in this range. 1194 13. IANA Considerations 1196 This document is part of a set. The IANA considerations for the SSH 1197 protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and 1198 this document, are detailed in [SSH-NUMBERS]. 1200 14. Security Considerations 1202 This protocol provides a secure encrypted channel over an insecure 1203 network. It performs server host authentication, key exchange, 1204 encryption, and integrity protection. It also derives a unique 1205 session id that may be used by higher-level protocols. 1207 Full security considerations for this protocol are provided in 1208 [SSH-ARCH]. 1210 15. References 1212 15.1 Normative 1214 [SSH-ARCH] 1215 Lonvick, C., "SSH Protocol Architecture", I-D 1216 draft-ietf-secsh-architecture-20.txt, December 2004. 1218 [SSH-USERAUTH] 1219 Lonvick, C., "SSH Authentication Protocol", I-D 1220 draft-ietf-secsh-userauth-25.txt, December 2004. 1222 [SSH-CONNECT] 1223 Lonvick, C., "SSH Connection Protocol", I-D 1224 draft-ietf-secsh-connect-23.txt, December 2004. 1226 [SSH-NUMBERS] 1227 Lonvick, C., "SSH Protocol Assigned Numbers", I-D 1228 draft-ietf-secsh-assignednumbers-10.txt, December 2004. 1230 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1231 Specification version 3.3", RFC 1950, May 1996. 1233 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1234 version 1.3", RFC 1951, May 1996. 1236 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1237 Keyed-Hashing for Message Authentication", RFC 2104, 1238 February 1997. 1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1241 Requirement Levels", BCP 14, RFC 2119, March 1997. 1243 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1244 May 1997. 1246 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1247 (IKE)", RFC 2409, November 1998. 1249 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 1250 2412, November 1998. 1252 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1253 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1254 October 1998. 1256 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1257 "OpenPGP Message Format", RFC 2440, November 1998. 1259 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1260 B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1261 September 1999. 1263 [RFC3066] Alvestrand, H., "Tags for the Identification of 1264 Languages", BCP 47, RFC 3066, January 2001. 1266 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1267 X.509 Public Key Infrastructure Certificate and 1268 Certificate Revocation List (CRL) Profile", RFC 3280, 1269 April 2002. 1271 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1272 Standards (PKCS) #1: RSA Cryptography Specifications 1273 Version 2.1", RFC 3447, February 2003. 1275 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1276 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1277 RFC 3526, May 2003. 1279 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1280 10646", STD 63, RFC 3629, November 2003. 1282 [FIPS-186-2] 1283 Federal Information Processing Standards Publication, 1284 "FIPS PUB 186-2, Digital Signature Standard (DSS)", 1285 January 2000. 1287 [FIPS-197] 1288 NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", 1289 November 2001. 1291 [FIPS-46-3] 1292 U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption 1293 Standard (DES)", October 1999. 1295 [SCHNEIER] 1296 Schneier, B., "Applied Cryptography Second Edition: 1297 protocols algorithms and source in code in C", 1996. 1299 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1300 128-Bit Block Cipher, 1st Edition", March 1999. 1302 15.2 Informative 1304 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 1305 over Ethernet networks", STD 41, RFC 894, April 1984. 1307 [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for 1308 multi-protocol transmission of datagrams over 1309 Point-to-Point links", RFC 1134, November 1989. 1311 [ssh-1.2.30] 1312 Ylonen, T., "ssh-1.2.30/RFC", File within compressed 1313 tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/ 1314 ssh-1.2.30.tar.gz, November 1995. 1316 Author's Address 1318 Chris Lonvick (editor) 1319 Cisco Systems, Inc. 1320 12515 Research Blvd. 1321 Austin 78759 1322 USA 1324 EMail: clonvick@cisco.com 1326 Intellectual Property Statement 1328 The IETF takes no position regarding the validity or scope of any 1329 Intellectual Property Rights or other rights that might be claimed to 1330 pertain to the implementation or use of the technology described in 1331 this document or the extent to which any license under such rights 1332 might or might not be available; nor does it represent that it has 1333 made any independent effort to identify any such rights. Information 1334 on the procedures with respect to rights in RFC documents can be 1335 found in BCP 78 and BCP 79. 1337 Copies of IPR disclosures made to the IETF Secretariat and any 1338 assurances of licenses to be made available, or the result of an 1339 attempt made to obtain a general license or permission for the use of 1340 such proprietary rights by implementers or users of this 1341 specification can be obtained from the IETF on-line IPR repository at 1342 http://www.ietf.org/ipr. 1344 The IETF invites any interested party to bring to its attention any 1345 copyrights, patents or patent applications, or other proprietary 1346 rights that may cover technology that may be required to implement 1347 this standard. Please address the information to the IETF at 1348 ietf-ipr@ietf.org. 1350 The IETF has been notified of intellectual property rights claimed in 1351 regard to some or all of the specification contained in this 1352 document. For more information consult the online list of claimed 1353 rights. 1355 Disclaimer of Validity 1357 This document and the information contained herein are provided on an 1358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1360 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1361 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1362 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1365 Copyright Statement 1367 Copyright (C) The Internet Society (2004). This document is subject 1368 to the rights, licenses and restrictions contained in BCP 78, and 1369 except as set forth therein, the authors retain all their rights. 1371 Acknowledgment 1373 Funding for the RFC Editor function is currently provided by the 1374 Internet Society.