idnits 2.17.1 draft-ietf-secsh-transport-20.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 1355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1340. ** 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 595 has weird spacing: '... string cer...' == Line 608 has weird spacing: '... string sig...' == Line 628 has weird spacing: '... string dss...' == Line 648 has weird spacing: '... string rsa...' == Line 714 has weird spacing: '... string kex...' == (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 (November 18, 2004) is 7098 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 713 == Unused Reference: 'RFC1034' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 1283, but no explicit reference was found in the text -- No information found for draft-ietf-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-ARCH' -- No information found for draft-ietf-userauth - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-USERAUTH' -- No information found for draft-ietf-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' -- No information found for draft-ietf-assignednumbers - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-NUMBERS' -- Obsolete informational reference (is this intentional?): RFC 1134 (Obsoleted by RFC 1171) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 23 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: May 19, 2005 November 18, 2004 5 SSH Transport Layer Protocol 6 draft-ietf-secsh-transport-20.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 May 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . 16 79 7.2 Output from Key Exchange . . . . . . . . . . . . . . . . . 19 80 7.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . 20 81 8. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 21 82 8.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . 22 83 8.2 diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 22 84 9. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 23 85 10. Service Request . . . . . . . . . . . . . . . . . . . . . . 23 86 11. Additional Messages . . . . . . . . . . . . . . . . . . . . 24 87 11.1 Disconnection Message . . . . . . . . . . . . . . . . . 24 88 11.2 Ignored Data Message . . . . . . . . . . . . . . . . . . 25 89 11.3 Debug Message . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . 27 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . 29 98 Intellectual Property and Copyright Statements . . . . . . . 30 100 1. Contributors 102 The major original contributors of this document were: Tatu Ylonen, 103 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 document 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. This 361 practice is, however, NOT RECOMMENDED. 363 The following compression methods are currently defined: 365 none REQUIRED no compression 366 zlib OPTIONAL ZLIB (LZ77) compression 368 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 369 The compression context is initialized after each key exchange, and 370 is passed from one packet to the next with only a partial flush being 371 performed at the end of each packet. A partial flush means that the 372 current compressed block is ended and all data will be output. If 373 the current block is not a stored block, one or more empty blocks are 374 added after the current block to ensure that there are at least 8 375 bits counting from the start of the end-of-block code of the current 376 block to the end of the packet payload. 378 Additional methods may be defined as specified in [SSH-ARCH]. 380 6.3 Encryption 382 An encryption algorithm and a key will be negotiated during the key 383 exchange. When encryption is in effect, the packet length, padding 384 length, payload and padding fields of each packet MUST be encrypted 385 with the given algorithm. 387 The encrypted data in all packets sent in one direction SHOULD be 388 considered a single data stream. For example, initialization vectors 389 SHOULD be passed from the end of one packet to the beginning of the 390 next packet. All ciphers SHOULD use keys with an effective key 391 length of 128 bits or more. 393 The ciphers in each direction MUST run independent of each other, and 394 implementations MUST allow the algorithm for each direction to be 395 independently selected for each direction, if multiple algorithms are 396 allowed by local policy. This practice is, however, NOT RECOMMENDED. 398 The following ciphers are currently defined: 400 3des-cbc REQUIRED three-key 3DES in CBC mode 401 blowfish-cbc OPTIONAL Blowfish in CBC mode 402 twofish256-cbc OPTIONAL Twofish in CBC mode, 403 with 256-bit key 404 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 405 is being retained for 406 historical reasons) 407 twofish192-cbc OPTIONAL Twofish with 192-bit key 408 twofish128-cbc OPTIONAL Twofish with 128-bit key 409 aes256-cbc OPTIONAL AES in CBC mode, 410 with 256-bit key 411 aes192-cbc OPTIONAL AES with 192-bit key 412 aes128-cbc RECOMMENDED AES with 128-bit key 413 serpent256-cbc OPTIONAL Serpent in CBC mode, with 414 256-bit key 415 serpent192-cbc OPTIONAL Serpent with 192-bit key 416 serpent128-cbc OPTIONAL Serpent with 128-bit key 417 arcfour OPTIONAL the ARCFOUR stream cipher 418 idea-cbc OPTIONAL IDEA in CBC mode 419 cast128-cbc OPTIONAL CAST-128 in CBC mode 420 none OPTIONAL no encryption; NOT RECOMMENDED 422 The "3des-cbc" cipher is three-key triple-DES 423 (encrypt-decrypt-encrypt), where the first 8 bytes of the key are 424 used for the first encryption, the next 8 bytes for the decryption, 425 and the following 8 bytes for the final encryption. This requires 24 426 bytes of key data (of which 168 bits are actually used). To 427 implement CBC mode, outer chaining MUST be used (i.e., there is only 428 one initialization vector). This is a block cipher with 8 byte 429 blocks. This algorithm is defined in [FIPS-46-3]. Note that this 430 algorithm does not meet the specifications that SSH encryption 431 algorithms should use keys of 128 bits or more. However, this 432 algorithm is still REQUIRED for historical reasons; essentially, all 433 known implementations at the time of this writing support this 434 algorithm, and it is commonly used because it is the fundamental 435 interoperable algorithm. At some future time it is expected that 436 another algorithm, one with better strength, will become so prevalent 437 and ubiquitous that the use of "3des-cbc" will be depricated by 438 another STANDARDS ACTION. 440 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 441 [SCHNEIER]. This is a block cipher with 8 byte blocks. 443 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 444 with 256 bit keys as described [TWOFISH]. This is a block cipher 445 with 16 byte blocks. 447 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 449 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 451 The "aes256-cbc" cipher is AES (Advanced Encryption Standard) 452 [FIPS-197], in CBC mode. This version uses 256-bit key. 454 The "aes192-cbc" cipher. Same as above but with 192-bit key. 456 The "aes128-cbc" cipher. Same as above but with 128-bit key. 458 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as 459 described in the Serpent AES submission. 461 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 463 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 465 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 466 Arcfour cipher is believed to be compatible with the RC4 cipher 467 [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. 468 Arcfour (and RC4) has problems with weak keys, and should be used 469 with caution. 471 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 473 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 474 [RFC2144]. 476 The "none" algorithm specifies that no encryption is to be done. 477 Note that this method provides no confidentiality protection, and it 478 is not recommended. Some functionality (e.g. password 479 authentication) may be disabled for security reasons if this cipher 480 is chosen. 482 Additional methods may be defined as specified in [SSH-ARCH] and in 483 [SSH-NUMBERS]. 485 6.4 Data Integrity 487 Data integrity is protected by including with each packet a message 488 authentication code (MAC) that is computed from a shared secret, 489 packet sequence number, and the contents of the packet. 491 The message authentication algorithm and key are negotiated during 492 key exchange. Initially, no MAC will be in effect, and its length 493 MUST be zero. After key exchange, the selected MAC will be computed 494 before encryption from the concatenation of packet data: 496 mac = MAC(key, sequence_number || unencrypted_packet) 498 where unencrypted_packet is the entire packet without MAC (the length 499 fields, payload and padding), and sequence_number is an implicit 500 packet sequence number represented as uint32. The sequence number is 501 initialized to zero for the first packet, and is incremented after 502 every packet (regardless of whether encryption or MAC is in use). It 503 is never reset, even if keys/algorithms are renegotiated later. It 504 wraps around to zero after every 2^32 packets. The packet sequence 505 number itself is not included in the packet sent over the wire. 507 The MAC algorithms for each direction MUST run independently, and 508 implementations MUST allow choosing the algorithm independently for 509 both directions. 511 The MAC bytes resulting from the MAC algorithm MUST be transmitted 512 without encryption as the last part of the packet. The number of MAC 513 bytes depends on the algorithm chosen. 515 The following MAC algorithms are currently defined: 517 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 518 length = 20) 519 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 520 length = 12, key length = 20) 521 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 522 length = 16) 523 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 524 length = 12, key length = 16) 525 none OPTIONAL no MAC; NOT RECOMMENDED 527 Figure 1 529 The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs 530 use only the first n bits of the resulting value. 532 The hash algorithms are described in [SCHNEIER]. 534 Additional methods may be defined as specified in [SSH-ARCH] and in 535 [SSH-NUMBERS]. 537 6.5 Key Exchange Methods 539 The key exchange method specifies how one-time session keys are 540 generated for encryption and for authentication, and how the server 541 authentication is done. 543 Two REQUIRED key exchange methods have been defined: 545 diffie-hellman-group1-sha1 REQUIRED 546 diffie-hellman-group14-sha1 REQUIRED 548 These methods are described later in this document. 550 Additional methods may be defined as specified in [SSH-NUMBERS]. 551 Note that, for historical reasons, the name 552 "diffie-hellman-group1-sha1" is used for a key exchange method using 553 Oakley Group 2. This is considered an aberration and should not be 554 repeated. Any future specifications of Diffie Hellman key exchange 555 using Oakley groups defined in [RFC2412] or its successors should be 556 named using the group numbers assigned by IANA, and names of the form 557 "diffie-hellman-groupN-sha1" should be reserved for this purpose. 559 6.6 Public Key Algorithms 561 This protocol has been designed to be able to operate with almost any 562 public key format, encoding, and algorithm (signature and/or 563 encryption). 565 There are several aspects that define a public key type: 566 o Key format: how is the key encoded and how are certificates 567 represented. The key blobs in this protocol MAY contain 568 certificates in addition to keys. 569 o Signature and/or encryption algorithms. Some key types may not 570 support both signing and encryption. Key usage may also be 571 restricted by policy statements in e.g. certificates. In this 572 case, different key types SHOULD be defined for the different 573 policy alternatives. 574 o Encoding of signatures and/or encrypted data. This includes but 575 is not limited to padding, byte order, and data formats. 577 The following public key and/or certificate formats are currently 578 defined: 580 ssh-dss REQUIRED sign Raw DSS Key 581 ssh-rsa RECOMMENDED sign Raw RSA Key 582 spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) 583 spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) 584 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 585 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 587 Additional key types may be defined as specified in [SSH-ARCH] and in 588 [SSH-NUMBERS]. 590 The key type MUST always be explicitly known (from algorithm 591 negotiation or some other source). It is not normally included in 592 the key blob. 594 Certificates and public keys are encoded as follows: 595 string certificate or public key format identifier 596 byte[n] key/certificate data 598 The certificate part may have be a zero length string, but a public 599 key is required. This is the public key that will be used for 600 authentication. The certificate sequence contained in the 601 certificate blob can be used to provide authorization. 603 Public key / certificate formats that do not explicitly specify a 604 signature format identifier MUST use the public key / certificate 605 format identifier as the signature identifier. 607 Signatures are encoded as follows: 608 string signature format identifier (as specified by the 609 public key / cert format) 610 byte[n] signature blob in format specific encoding. 612 The "ssh-dss" key format has the following specific encoding: 614 string "ssh-dss" 615 mpint p 616 mpint q 617 mpint g 618 mpint y 620 Here the p, q, g, and y parameters form the signature key blob. 622 Signing and verifying using this key format is done according to the 623 Digital Signature Standard [FIPS-186-2] using the SHA-1 hash. 625 The resulting signature is encoded as follows: 627 string "ssh-dss" 628 string dss_signature_blob 630 dss_signature_blob is encoded as a string containing r followed by s 631 (which are 160 bits long integers, without lengths or padding, 632 unsigned and in network byte order). 634 The "ssh-rsa" key format has the following specific encoding: 636 string "ssh-rsa" 637 mpint e 638 mpint n 640 Here the e and n parameters form the signature key blob. 642 Signing and verifying using this key format is done according to 643 [SCHNEIER] and [RFC3447] using the SHA-1 hash. 645 The resulting signature is encoded as follows: 647 string "ssh-rsa" 648 string rsa_signature_blob 650 rsa_signature_blob is encoded as a string containing s (which is an 651 integer, without lengths or padding, unsigned and in network byte 652 order). 654 The "spki-sign-rsa" method indicates that the certificate blob 655 contains a sequence of SPKI certificates. The format of SPKI 656 certificates is described in [RFC2693]. This method indicates that 657 the key (or one of the keys in the certificate) is an RSA-key. 659 The "spki-sign-dss". As above, but indicates that the key (or one of 660 the keys in the certificate) is a DSS-key. 662 The "pgp-sign-rsa" method indicates the certificates, the public key, 663 and the signature are in OpenPGP compatible binary format 664 ([RFC2440]). This method indicates that the key is an RSA-key. 666 The "pgp-sign-dss". As above, but indicates that the key is a 667 DSS-key. 669 7. Key Exchange 671 Key exchange (kex) begins by each side sending lists of supported 672 algorithms. Each side has a preferred algorithm in each category, 673 and it is assumed that most implementations at any given time will 674 use the same preferred algorithm. Each side MAY guess which 675 algorithm the other side is using, and MAY send an initial key 676 exchange packet according to the algorithm if appropriate for the 677 preferred method. 679 The guess is considered wrong, if: 680 o the kex algorithm and/or the host key algorithm is guessed wrong 681 (server and client have different preferred algorithm), or 682 o if any of the other algorithms cannot be agreed upon (the 683 procedure is defined below in Section 7.1). 685 Otherwise, the guess is considered to be right and the optimistically 686 sent packet MUST be handled as the first key exchange packet. 688 However, if the guess was wrong, and a packet was optimistically sent 689 by one or both parties, such packets MUST be ignored (even if the 690 error in the guess would not affect the contents of the initial 691 packet(s)), and the appropriate side MUST send the correct initial 692 packet. 694 A key exchange method uses "explicit server authentication" if the 695 key exchange messages include a signature or other proof of the 696 server's authenticity. A key exchange method uses "implicit server 697 authentication" if, in order to prove its autenticity, the server 698 also has to prove that it knows the shared secret K, by sending a 699 message and a corresponding MAC which the client can verify. 701 The key exchange method defined by this document uses explicit server 702 authentication. However, key exchange methods with implicit server 703 authentication MAY be used with this protocol. After a key exchange 704 with implicit server authentication, the client MUST wait for 705 response to its service request message before sending any further 706 data. 708 7.1 Algorithm Negotiation 710 Key exchange begins by each side sending the following packet: 712 byte SSH_MSG_KEXINIT 713 byte[16] cookie (random bytes) 714 string kex_algorithms 715 string server_host_key_algorithms 716 string encryption_algorithms_client_to_server 717 string encryption_algorithms_server_to_client 718 string mac_algorithms_client_to_server 719 string mac_algorithms_server_to_client 720 string compression_algorithms_client_to_server 721 string compression_algorithms_server_to_client 722 string languages_client_to_server 723 string languages_server_to_client 724 boolean first_kex_packet_follows 725 uint32 0 (reserved for future extension) 727 Each of the algorithm strings MUST be a comma-separated list of 728 algorithm names (see Algorithm Naming in [SSH-ARCH]) and additional 729 information in [SSH-NUMBERS]. Each supported (allowed) algorithm 730 MUST be listed in order of preference. 732 The first algorithm in each list MUST be the preferred (guessed) 733 algorithm. Each string MUST contain at least one algorithm name. 735 cookie 736 The cookie MUST be a random value generated by the sender. Its 737 purpose is to make it impossible for either side to fully 738 determine the keys and the session identifier. 740 kex_algorithms 741 Key exchange algorithms were defined above. The first 742 algorithm MUST be the preferred (and guessed) algorithm. If 743 both sides make the same guess, that algorithm MUST be used. 744 Otherwise, the following algorithm MUST be used to choose a key 745 exchange method: Iterate over client's kex algorithms, one at a 746 time. Choose the first algorithm that satisfies the following 747 conditions: 748 + the server also supports the algorithm, 749 + if the algorithm requires an encryption-capable host key, 750 there is an encryption-capable algorithm on the server's 751 server_host_key_algorithms that is also supported by the 752 client, and 753 + if the algorithm requires a signature-capable host key, 754 there is a signature-capable algorithm on the server's 755 server_host_key_algorithms that is also supported by the 756 client. 757 If no algorithm satisfying all these conditions can be found, 758 the connection fails, and both sides MUST disconnect. 760 server_host_key_algorithms 761 List of the algorithms supported for the server host key. The 762 server lists the algorithms for which it has host keys; the 763 client lists the algorithms that it is willing to accept. 764 (There MAY be multiple host keys for a host, possibly with 765 different algorithms.) 766 Some host keys may not support both signatures and encryption 767 (this can be determined from the algorithm), and thus not all 768 host keys are valid for all key exchange methods. 770 Algorithm selection depends on whether the chosen key exchange 771 algorithm requires a signature or encryption capable host key. 772 It MUST be possible to determine this from the public key 773 algorithm name. The first algorithm on the client's list that 774 satisfies the requirements and is also supported by the server 775 MUST be chosen. If there is no such algorithm, both sides MUST 776 disconnect. 778 encryption_algorithms 779 Lists the acceptable symmetric encryption algorithms in order 780 of preference. The chosen encryption algorithm to each 781 direction MUST be the first algorithm on the client's list 782 that is also on the server's list. If there is no such 783 algorithm, both sides MUST disconnect. 785 Note that "none" must be explicitly listed if it is to be 786 acceptable. The defined algorithm names are listed in Section 787 6.3. 789 mac_algorithms 790 Lists the acceptable MAC algorithms in order of preference. 791 The chosen MAC algorithm MUST be the first algorithm on the 792 client's list that is also on the server's list. If there is 793 no such algorithm, both sides MUST disconnect. 795 Note that "none" must be explicitly listed if it is to be 796 acceptable. The MAC algorithm names are listed in Section 797 Figure 1. 799 compression_algorithms 800 Lists the acceptable compression algorithms in order of 801 preference. The chosen compression algorithm MUST be the first 802 algorithm on the client's list that is also on the server's 803 list. If there is no such algorithm, both sides MUST 804 disconnect. 806 Note that "none" must be explicitly listed if it is to be 807 acceptable. The compression algorithm names are listed in 808 Section 6.2. 810 languages 811 This is a comma-separated list of language tags in order of 812 preference [RFC3066]. Both parties MAY ignore this list. If 813 there are no language preferences, this list SHOULD be empty. 815 Language tags SHOULD NOT be present unless they are known to be 816 needed by the sending party. 818 first_kex_packet_follows 819 Indicates whether a guessed key exchange packet follows. If a 820 guessed packet will be sent, this MUST be TRUE. If no guessed 821 packet will be sent, this MUST be FALSE. 823 After receiving the SSH_MSG_KEXINIT packet from the other side, 824 each party will know whether their guess was right. If the 825 other party's guess was wrong, and this field was TRUE, the 826 next packet MUST be silently ignored, and both sides MUST then 827 act as determined by the negotiated key exchange method. If 828 the guess was right, key exchange MUST continue using the 829 guessed packet. 831 After the KEXINIT packet exchange, the key exchange algorithm is run. 832 It may involve several packet exchanges, as specified by the key 833 exchange method. 835 Once a party has sent a KEXINIT message for key exchange or 836 re-exchange, until is has sent a NEWKEYS message (Section 7.3), it 837 MUST NOT send any messages other than: 838 o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST 839 and SERVICE_ACCEPT MUST NOT be sent); 840 o Algorithm negotiation messages (20 to 29) (but further KEXINITs 841 MUST NOT be sent); 842 o Specific key exchange method messages (30 to 49). 844 The provisions of Section 11 apply for unrecognised messages. 846 Note however that during a key re-exchange, after sending a KEXINIT 847 message, each party MUST be prepared to process an arbitrary number 848 of messages that may be in-flight before receiving a KEXINIT from the 849 other party. 851 7.2 Output from Key Exchange 853 The key exchange produces two values: a shared secret K, and an 854 exchange hash H. Encryption and authentication keys are derived from 855 these. The exchange hash H from the first key exchange is 856 additionally used as the session identifier, which is a unique 857 identifier for this connection. It is used by authentication methods 858 as a part of the data that is signed as a proof of possession of a 859 private key. Once computed, the session identifier is not changed, 860 even if keys are later re-exchanged. 862 Each key exchange method specifies a hash function that is used in 863 the key exchange. The same hash algorithm MUST be used in key 864 derivation. Here, we'll call it HASH. 866 Encryption keys MUST be computed as HASH of a known value and K as 867 follows: 868 o Initial IV client to server: HASH(K || H || "A" || session_id) 869 (Here K is encoded as mpint and "A" as byte and session_id as raw 870 data. "A" means the single character A, ASCII 65). 871 o Initial IV server to client: HASH(K || H || "B" || session_id) 872 o Encryption key client to server: HASH(K || H || "C" || session_id) 873 o Encryption key server to client: HASH(K || H || "D" || session_id) 874 o Integrity key client to server: HASH(K || H || "E" || session_id) 875 o Integrity key server to client: HASH(K || H || "F" || session_id) 877 Key data MUST be taken from the beginning of the hash output. 128 878 bits (16 bytes) MUST be used for algorithms with variable-length 879 keys. The only variable key length algorithm defined in this 880 document is arcfour). For other algorithms, as many bytes as are 881 needed are taken from the beginning of the hash value. If the key 882 length needed is longer than the output of the HASH, the key is 883 extended by computing HASH of the concatenation of K and H and the 884 entire key so far, and appending the resulting bytes (as many as HASH 885 generates) to the key. This process is repeated until enough key 886 material is available; the key is taken from the beginning of this 887 value. In other words: 889 K1 = HASH(K || H || X || session_id) (X is e.g. "A") 890 K2 = HASH(K || H || K1) 891 K3 = HASH(K || H || K1 || K2) 892 ... 893 key = K1 || K2 || K3 || ... 895 This process will lose entropy if the amount of entropy in K is 896 larger than the internal state size of HASH. 898 7.3 Taking Keys Into Use 900 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 901 This message is sent with the old keys and algorithms. All messages 902 sent after this message MUST use the new keys and algorithms. 904 When this message is received, the new keys and algorithms MUST be 905 taken into use for receiving. 907 The purpose of this message is to ensure that a party is able to 908 respond with a SSH_MSG_DISCONNECT message that the other party can 909 understand if something goes wrong with the key exchange. 911 byte SSH_MSG_NEWKEYS 913 8. Diffie-Hellman Key Exchange 915 The Diffie-Hellman (DH) key exchange provides a shared secret that 916 can not be determined by either party alone. The key exchange is 917 combined with a signature with the host key to provide host 918 authentication. This key exchange method provides explicit server 919 authentication as is defined in Section 7. 921 In the following description (C is the client, S is the server; p is 922 a large safe prime, g is a generator for a subgroup of GF(p), and q 923 is the order of the subgroup; V_S is S's version string; V_C is C's 924 version string; K_S is S's public host key; I_C is C's KEXINIT 925 message and I_S S's KEXINIT message which have been exchanged before 926 this part begins): 928 1. C generates a random number x (1 < x < q) and computes e = g^x 929 mod p. C sends "e" to S. 931 2. S generates a random number y (0 < y < q) and computes f = g^y 932 mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C 933 || V_S || I_C || I_S || K_S || e || f || K) (these elements are 934 encoded according to their types; see below), and signature s on 935 H with its private host key. S sends "K_S || f || s" to C. The 936 signing operation may involve a second hashing operation. 938 3. C verifies that K_S really is the host key for S (e.g. using 939 certificates or a local database). C is also allowed to accept 940 the key without verification; however, doing so will render the 941 protocol insecure against active attacks (but may be desirable 942 for practical reasons in the short term in many environments). C 943 then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || 944 K_S || e || f || K), and verifies the signature s on H. 946 Either side MUST NOT send or accept e or f values that are not in the 947 range [1, p-1]. If this condition is violated, the key exchange 948 fails. 950 This is implemented with the following messages. The hash algorithm 951 for computing the exchange hash is defined by the method name, and is 952 called HASH. The public key algorithm for signing is negotiated with 953 the KEXINIT messages. 955 First, the client sends the following: 957 byte SSH_MSG_KEXDH_INIT 958 mpint e 960 The server responds with the following: 962 byte SSH_MSG_KEXDH_REPLY 963 string server public host key and certificates (K_S) 964 mpint f 965 string signature of H 967 The hash H is computed as the HASH hash of the concatenation of the 968 following: 970 string V_C, the client's version string (CR and NL excluded) 971 string V_S, the server's version string (CR and NL excluded) 972 string I_C, the payload of the client's SSH_MSG_KEXINIT 973 string I_S, the payload of the server's SSH_MSG_KEXINIT 974 string K_S, the host key 975 mpint e, exchange value sent by the client 976 mpint f, exchange value sent by the server 977 mpint K, the shared secret 979 This value is called the exchange hash, and it is used to 980 authenticate the key exchange. The exchange hash SHOULD be kept 981 secret. 983 The signature algorithm MUST be applied over H, not the original 984 data. Most signature algorithms include hashing and additional 985 padding. For example, "ssh-dss" specifies SHA-1 hashing; in that 986 case, the data is first hashed with HASH to compute H, and H is then 987 hashed with SHA-1 as part of the signing operation. 989 8.1 diffie-hellman-group1-sha1 991 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 992 exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit 993 MODP Group). This method MUST be supported for interoperability as 994 all of the known implementations currently support it. Note that, 995 for historical reasons, this method is named using the phrase 996 "group1" even though it specifies the use of Oakley Group 2. 998 8.2 diffie-hellman-group14-sha1 1000 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key 1001 exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit 1002 MODP Group), and it MUST also be supported. 1004 9. Key Re-Exchange 1006 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when 1007 not already doing a key exchange (as described in Section 7.1). When 1008 this message is received, a party MUST respond with its own 1009 SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT 1010 already was a reply. Either party MAY initiate the re-exchange, but 1011 roles MUST NOT be changed (i.e., the server remains the server, and 1012 the client remains the client). 1014 Key re-exchange is performed using whatever encryption was in effect 1015 when the exchange was started. Encryption, compression, and MAC 1016 methods are not changed before a new SSH_MSG_NEWKEYS is sent after 1017 the key exchange (as in the initial key exchange). Re-exchange is 1018 processed identically to the initial key exchange, except for the 1019 session identifier that will remain unchanged. It is permissible to 1020 change some or all of the algorithms during the re-exchange. Host 1021 keys can also change. All keys and initialization vectors are 1022 recomputed after the exchange. Compression and encryption contexts 1023 are reset. 1025 It is recommended that the keys are changed after each gigabyte of 1026 transmitted data or after each hour of connection time, whichever 1027 comes sooner. However, since the re-exchange is a public key 1028 operation, it requires a fair amount of processing power and should 1029 not be performed too often. 1031 More application data may be sent after the SSH_MSG_NEWKEYS packet 1032 has been sent; key exchange does not affect the protocols that lie 1033 above the SSH transport layer. 1035 10. Service Request 1037 After the key exchange, the client requests a service. The service 1038 is identified by a name. The format of names and procedures for 1039 defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS]. 1041 Currently, the following names have been reserved: 1043 ssh-userauth 1044 ssh-connection 1046 Similar local naming policy is applied to the service names, as is 1047 applied to the algorithm names. A local service should use the 1048 PRIVATE USE syntax of "servicename@domain". 1050 byte SSH_MSG_SERVICE_REQUEST 1051 string service name 1053 If the server rejects the service request, it SHOULD send an 1054 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 1056 When the service starts, it may have access to the session identifier 1057 generated during the key exchange. 1059 If the server supports the service (and permits the client to use 1060 it), it MUST respond with the following: 1062 byte SSH_MSG_SERVICE_ACCEPT 1063 string service name 1065 Message numbers used by services should be in the area reserved for 1066 them (see [SSH-ARCH]) and [SSH-NUMBERS]. The transport level will 1067 continue to process its own messages. 1069 Note that after a key exchange with implicit server authentication, 1070 the client MUST wait for response to its service request message 1071 before sending any further data. 1073 11. Additional Messages 1075 Either party may send any of the following messages at any time. 1077 11.1 Disconnection Message 1078 byte SSH_MSG_DISCONNECT 1079 uint32 reason code 1080 string description [RFC3629] 1081 string language tag [RFC3066] 1083 This message causes immediate termination of the connection. All 1084 implementations MUST be able to process this message; they SHOULD be 1085 able to send this message. 1087 The sender MUST NOT send or receive any data after this message, and 1088 the recipient MUST NOT accept any data after receiving this message. 1089 The Disconnection Message 'description' string gives a more specific 1090 explanation in a human-readable form. The Disconnection Message 1091 'reason code' gives the reason in a more machine-readable format 1092 (suitable for localization), and can have the values as displayed in 1093 the table below. Note that the decimal representation is displayed 1094 in this table for readability but that the values are actually uint32 1095 values. 1097 description reason code 1098 ----------- ----------- 1099 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 1100 SSH_DISCONNECT_PROTOCOL_ERROR 2 1101 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 1102 SSH_DISCONNECT_RESERVED 4 1103 SSH_DISCONNECT_MAC_ERROR 5 1104 SSH_DISCONNECT_COMPRESSION_ERROR 6 1105 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1106 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1107 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1108 SSH_DISCONNECT_CONNECTION_LOST 10 1109 SSH_DISCONNECT_BY_APPLICATION 11 1110 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1111 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1112 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1113 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1115 If the 'description' string is displayed, control character filtering 1116 discussed in [SSH-ARCH] should be used to avoid attacks by sending 1117 terminal control characters. 1119 Requests for assignments of new Disconnection Message 'reason code' 1120 values (and associated 'description' text) in the range of 0x00000010 1121 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 1122 described in [RFC2434]. The Disconnection Message 'reason code' 1123 values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for 1124 PRIVATE USE. As is noted, the actual instructions to the IANA is in 1125 [SSH-NUMBERS]. 1127 11.2 Ignored Data Message 1128 byte SSH_MSG_IGNORE 1129 string data 1131 All implementations MUST understand (and ignore) this message at any 1132 time (after receiving the protocol version). No implementation is 1133 required to send them. This message can be used as an additional 1134 protection measure against advanced traffic analysis techniques. 1136 11.3 Debug Message 1137 byte SSH_MSG_DEBUG 1138 boolean always_display 1139 string message [RFC3629] 1140 string language tag [RFC3066] 1142 All implementations MUST understand this message, but they are 1143 allowed to ignore it. This message is used to transmit information 1144 that may help debugging. If always_display is TRUE, the message 1145 SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 1146 debugging information has been explicitly requested by the user. 1148 The message doesn't need to contain a newline. It is, however, 1149 allowed to consist of multiple lines separated by CRLF (Carriage 1150 Return - Line Feed) pairs. 1152 If the message string is displayed, terminal control character 1153 filtering discussed in [SSH-ARCH] should be used to avoid attacks by 1154 sending terminal control characters. 1156 11.4 Reserved Messages 1158 An implementation MUST respond to all unrecognized messages with an 1159 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1160 received. Such messages MUST be otherwise ignored. Later protocol 1161 versions may define other meanings for these message types. 1162 byte SSH_MSG_UNIMPLEMENTED 1163 uint32 packet sequence number of rejected message 1165 12. Summary of Message Numbers 1167 The following message numbers have been defined in this protocol: 1169 SSH_MSG_DISCONNECT 1 1170 SSH_MSG_IGNORE 2 1171 SSH_MSG_UNIMPLEMENTED 3 1172 SSH_MSG_DEBUG 4 1173 SSH_MSG_SERVICE_REQUEST 5 1174 SSH_MSG_SERVICE_ACCEPT 6 1175 SSH_MSG_KEXINIT 20 1176 SSH_MSG_NEWKEYS 21 1177 SSH_MSG_KEXDH_INIT 30 1178 SSH_MSG_KEXDH_REPLY 31 1180 Note that Numbers 30-49 are used for kex packets. Different kex 1181 methods may reuse message numbers in this range. 1183 13. IANA Considerations 1185 This document is part of a set. The IANA considerations for the SSH 1186 protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and 1187 this document, are detailed in [SSH-NUMBERS]. 1189 14. Security Considerations 1191 This protocol provides a secure encrypted channel over an insecure 1192 network. It performs server host authentication, key exchange, 1193 encryption, and integrity protection. It also derives a unique 1194 session id that may be used by higher-level protocols. 1196 Full security considerations for this protocol are provided in 1197 [SSH-ARCH]. 1199 15. References 1201 15.1 Normative 1203 [SSH-ARCH] 1204 Lonvick, C., "SSH Protocol Architecture", I-D 1205 draft-ietf-architecture-18.txt, October 2004. 1207 [SSH-USERAUTH] 1208 Lonvick, C., "SSH Authentication Protocol", I-D 1209 draft-ietf-userauth-23.txt, October 2004. 1211 [SSH-CONNECT] 1212 Lonvick, C., "SSH Connection Protocol", I-D 1213 draft-ietf-connect-21.txt, October 2004. 1215 [SSH-NUMBERS] 1216 Lonvick, C., "SSH Protocol Assigned Numbers", I-D 1217 draft-ietf-assignednumbers-08.txt, October 2004. 1219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1220 Requirement Levels", BCP 14, RFC 2119, March 1997. 1222 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1223 10646", STD 63, RFC 3629, November 2003. 1225 15.2 Informative 1227 [FIPS-186-2] 1228 Federal Information Processing Standards Publication, 1229 "FIPS PUB 186-2, Digital Signature Standard (DSS)", 1230 January 2000. 1232 [FIPS-197] 1233 NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", 1234 November 2001. 1236 [FIPS-46-3] 1237 U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption 1238 Standard (DES)", October 1999. 1240 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 1241 over Ethernet networks", STD 41, RFC 894, April 1984. 1243 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1244 STD 13, RFC 1034, November 1987. 1246 [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for 1247 multi-protocol transmission of datagrams over 1248 Point-to-Point links", RFC 1134, November 1989. 1250 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1251 Specification version 3.3", RFC 1950, May 1996. 1253 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1254 version 1.3", RFC 1951, May 1996. 1256 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1257 Keyed-Hashing for Message Authentication", RFC 2104, 1258 February 1997. 1260 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1261 May 1997. 1263 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1264 (IKE)", RFC 2409, November 1998. 1266 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 1267 2412, November 1998. 1269 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1270 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1271 October 1998. 1273 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1274 "OpenPGP Message Format", RFC 2440, November 1998. 1276 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1277 B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1278 September 1999. 1280 [RFC3066] Alvestrand, H., "Tags for the Identification of 1281 Languages", BCP 47, RFC 3066, January 2001. 1283 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1284 X.509 Public Key Infrastructure Certificate and 1285 Certificate Revocation List (CRL) Profile", RFC 3280, 1286 April 2002. 1288 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1289 Standards (PKCS) #1: RSA Cryptography Specifications 1290 Version 2.1", RFC 3447, February 2003. 1292 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1293 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1294 RFC 3526, May 2003. 1296 [SCHNEIER] 1297 Schneier, B., "Applied Cryptography Second Edition: 1298 protocols algorithms and source in code in C", 1996. 1300 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1301 128-Bit Block Cipher, 1st Edition", March 1999. 1303 [ssh-1.2.30] 1304 Ylonen, T., "ssh-1.2.30/RFC", File within compressed 1305 tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/ 1306 ssh-1.2.30.tar.gz, November 1995. 1308 Author's Address 1310 Chris Lonvick (editor) 1311 Cisco Systems, Inc. 1312 12515 Research Blvd. 1313 Austin 78759 1314 USA 1316 EMail: clonvick@cisco.com 1318 Intellectual Property Statement 1320 The IETF takes no position regarding the validity or scope of any 1321 Intellectual Property Rights or other rights that might be claimed to 1322 pertain to the implementation or use of the technology described in 1323 this document or the extent to which any license under such rights 1324 might or might not be available; nor does it represent that it has 1325 made any independent effort to identify any such rights. Information 1326 on the procedures with respect to rights in RFC documents can be 1327 found in BCP 78 and BCP 79. 1329 Copies of IPR disclosures made to the IETF Secretariat and any 1330 assurances of licenses to be made available, or the result of an 1331 attempt made to obtain a general license or permission for the use of 1332 such proprietary rights by implementers or users of this 1333 specification can be obtained from the IETF on-line IPR repository at 1334 http://www.ietf.org/ipr. 1336 The IETF invites any interested party to bring to its attention any 1337 copyrights, patents or patent applications, or other proprietary 1338 rights that may cover technology that may be required to implement 1339 this standard. Please address the information to the IETF at 1340 ietf-ipr@ietf.org. 1342 The IETF has been notified of intellectual property rights claimed in 1343 regard to some or all of the specification contained in this 1344 document. For more information consult the online list of claimed 1345 rights. 1347 Disclaimer of Validity 1349 This document and the information contained herein are provided on an 1350 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1351 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1352 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1353 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1354 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1357 Copyright Statement 1359 Copyright (C) The Internet Society (2004). This document is subject 1360 to the rights, licenses and restrictions contained in BCP 78, and 1361 except as set forth therein, the authors retain all their rights. 1363 Acknowledgment 1365 Funding for the RFC Editor function is currently provided by the 1366 Internet Society.