idnits 2.17.1 draft-ietf-secsh-transport-19.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1283. ** 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 556 has weird spacing: '... string cer...' == Line 569 has weird spacing: '... string sig...' == Line 589 has weird spacing: '... string dss...' == Line 609 has weird spacing: '... string rsa...' == Line 666 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 (October 24, 2004) is 7124 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 665 == Unused Reference: 'RFC1034' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 1231, 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 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 (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick, Ed. 3 Internet-Draft Cisco Systems, Inc 4 Expires: April 24, 2005 October 24, 2004 6 SSH Transport Layer Protocol 7 draft-ietf-secsh-transport-19.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 24, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 SSH is a protocol for secure remote login and other secure network 43 services over an insecure network. 45 This document describes the SSH transport layer protocol which 46 typically runs on top of TCP/IP. The protocol can be used as a basis 47 for a number of secure network services. It provides strong 48 encryption, server authentication, and integrity protection. It may 49 also provide compression. 51 Key exchange method, public key algorithm, symmetric encryption 52 algorithm, message authentication algorithm, and hash algorithm are 53 all negotiated. 55 This document also describes the Diffie-Hellman key exchange method 56 and the minimal set of algorithms that are needed to implement the 57 SSH transport layer protocol. 59 Table of Contents 61 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Conventions Used in This Document . . . . . . . . . . . . . 3 64 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . 4 66 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . 4 67 5. Compatibility With Old SSH Versions . . . . . . . . . . . . 5 68 5.1 Old Client, New Server . . . . . . . . . . . . . . . . . . 5 69 5.2 New Client, Old Server . . . . . . . . . . . . . . . . . . 6 70 6. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 6 71 6.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . 7 72 6.2 Compression . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . 10 75 6.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . 11 76 6.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . 11 77 7. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . 14 79 7.2 Output from Key Exchange . . . . . . . . . . . . . . . . . 17 80 7.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . 18 81 8. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 18 82 8.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . 20 83 8.2 diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 20 84 9. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 21 85 10. Service Request . . . . . . . . . . . . . . . . . . . . . . 21 86 11. Additional Messages . . . . . . . . . . . . . . . . . . . . 22 87 11.1 Disconnection Message . . . . . . . . . . . . . . . . . 22 88 11.2 Ignored Data Message . . . . . . . . . . . . . . . . . . 23 89 11.3 Debug Message . . . . . . . . . . . . . . . . . . . . . 23 90 11.4 Reserved Messages . . . . . . . . . . . . . . . . . . . 24 91 12. Summary of Message Numbers . . . . . . . . . . . . . . . . . 24 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 93 14. Security Considerations . . . . . . . . . . . . . . . . . . 25 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 15.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . 25 96 15.2 Informative . . . . . . . . . . . . . . . . . . . . . . . 25 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 98 Intellectual Property and Copyright Statements . . . . . . . 28 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 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 139 and "MAY" that appear in this document are to be interpreted as 140 described in [RFC2119]. 142 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 143 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 144 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 145 this document when used to describe namespace allocation are to be 146 interpreted as described in [RFC2434]. 148 4. Connection Setup 150 SSH works over any 8-bit clean, binary-transparent transport. The 151 underlying transport SHOULD protect against transmission errors as 152 such errors cause the SSH connection to terminate. 154 The client initiates the connection. 156 4.1 Use over TCP/IP 158 When used over TCP/IP, the server normally listens for connections on 159 port 22. This port number has been registered with the IANA, and has 160 been officially assigned for SSH. 162 4.2 Protocol Version Exchange 164 When the connection has been established, both sides MUST send an 165 identification string. This identification string MUST be 167 SSH-protoversion-softwareversion SP comments CR LF 169 Since the protocol being defined in this set of documents is version 170 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is 171 OPTIONAL. If the 'comments' string is included, a 'space' character 172 (denoted above as SP, ASCII 32) MUST separate the 'softwareversion' 173 and 'comments' strings. The identification MUST be terminated by a 174 single Carriage Return and a single Line Feed character (ASCII 13 and 175 10, respectively). Implementors who wish to maintain compatibility 176 with older, undocumented versions of this protocol, may want to 177 process the identification string without expecting the presence of 178 the carriage return character for reasons described in Section 5 of 179 this document. The null character MUST NOT be sent. The maximum 180 length of the string is 255 characters, including the Carriage Return 181 and Line Feed. 183 The part of the identification string preceding Carriage Return and 184 Line Feed is used in the Diffie-Hellman key exchange (see Section 8). 186 The server MAY send other lines of data before sending the version 187 string. Each line SHOULD be terminated by a Carriage Return and Line 188 Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 189 in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients 190 MUST be able to process such lines. They MAY be silently ignored, or 191 MAY be displayed to the client user. If they are displayed, control 192 character filtering discussed in [SSH-ARCH] SHOULD be used. The 193 primary use of this feature is to allow TCP-wrappers to display an 194 error message before disconnecting. 196 Both the 'protoversion' and 'softwareversion' strings MUST consist of 197 printable US-ASCII characters with the exception of whitespace 198 characters and the minus sign (-). The 'softwareversion' string is 199 primarily used to trigger compatibility extensions and to indicate 200 the capabilities of an implementation. The 'comments' string SHOULD 201 contain additional information that might be useful in solving user 202 problems. As such, an example of a valid identification string is 204 SSH-2.0-billsSSH_3.6.3q3 206 This identification string does not contain the optional 'comments' 207 string and is thusly terminated by a CR and LF immediately after the 208 'softwareversion' string. 210 Key exchange will begin immediately after sending this identifier. 211 All packets following the identification string SHALL use the binary 212 packet protocol which is described in Section 6. 214 5. Compatibility With Old SSH Versions 216 As stated earlier, the 'protoversion' specified for this protocol is 217 "2.0". Earlier versions of this protocol have not been formally 218 documented but it is widely known that they use 'protoversion' of 219 "1.x" (e.g., "1.5" or "1.3"). At the time of this writing, many 220 implementations of SSH are utilizing protocol version 2.0 but it is 221 known that there are still devices using the previous versions. 222 During the transition period, it is important to be able to work in a 223 way that is compatible with the installed SSH clients and servers 224 that use the older version of the protocol. Information in this 225 section is only relevant for implementations supporting compatibility 226 with SSH versions 1.x. For those interested, the only known 227 documentation of the 1.x protocol is contained in README files that 228 are shipped along with the source code. 230 5.1 Old Client, New Server 232 Server implementations MAY support a configurable "compatibility" 233 flag that enables compatibility with old versions. When this flag is 234 on, the server SHOULD identify its protocol version as "1.99". 235 Clients using protocol 2.0 MUST be able to identify this as identical 236 to "2.0". In this mode the server SHOULD NOT send the carriage 237 return character (ASCII 13) after the version identification string. 239 In the compatibility mode the server SHOULD NOT send any further data 240 after its initialization string until it has received an 241 identification string from the client. The server can then determine 242 whether the client is using an old protocol, and can revert to the 243 old protocol if required. In the compatibility mode, the server MUST 244 NOT send additional data before the version string. 246 When compatibility with old clients is not needed, the server MAY 247 send its initial key exchange data immediately after the 248 identification string. 250 5.2 New Client, Old Server 252 Since the new client MAY immediately send additional data after its 253 identification string (before receiving server's identification), the 254 old protocol may already have been corrupted when the client learns 255 that the server is old. When this happens, the client SHOULD close 256 the connection to the server, and reconnect using the old protocol. 258 6. Binary Packet Protocol 260 Each packet is in the following format: 262 uint32 packet_length 263 byte padding_length 264 byte[n1] payload; n1 = packet_length - padding_length - 1 265 byte[n2] random padding; n2 = padding_length 266 byte[m] MAC (Message Authentication Code); m = mac_length 268 packet_length 269 The length of the packet in bytes, not including the Message 270 Authentication Code (MAC) or the packet_length field itself. 272 padding_length 273 Length of padding (bytes). 275 payload 276 The useful contents of the packet. If compression has been 277 negotiated, this field is compressed. Initially, compression 278 MUST be "none". 280 random padding 281 Arbitrary-length padding, such that the total length of 282 (packet_length || padding_length || payload || padding) is a 283 multiple of the cipher block size or 8, whichever is larger. 284 There MUST be at least four bytes of padding. The padding 285 SHOULD consist of random bytes. The maximum amount of padding 286 is 255 bytes. 288 mac 289 Message Authentication Code. If message authentication has 290 been negotiated, this field contains the MAC bytes. Initially, 291 the MAC algorithm MUST be "none". 293 Note that length of the concatenation of packet length, padding 294 length, payload, and padding MUST be a multiple of the cipher block 295 size or 8, whichever is larger. This constraint MUST be enforced 296 even when using stream ciphers. Note that the packet length field is 297 also encrypted, and processing it requires special care when sending 298 or receiving packets. 300 The minimum size of a packet is 16 (or the cipher block size, 301 whichever is larger) bytes (plus MAC). Implementations SHOULD 302 decrypt the length after receiving the first 8 (or cipher block size, 303 whichever is larger) bytes of a packet. 305 6.1 Maximum Packet Length 307 All implementations MUST be able to process packets with uncompressed 308 payload length of 32768 bytes or less and total packet size of 35000 309 bytes or less (including length, padding length, payload, padding, 310 and MAC). The maximum of 35000 bytes is an arbitrary chosen value 311 larger than uncompressed size. Implementations SHOULD support longer 312 packets, where they might be needed. For example, if an 313 implementation wants to send a very large number of certificates, the 314 larger packets MAY be sent if the version string indicates that the 315 other party is able to process them. However, implementations SHOULD 316 check that the packet length is reasonable for the implementation to 317 avoid denial-of-service and/or buffer overflow attacks. 319 6.2 Compression 321 If compression has been negotiated, the payload field (and only it) 322 will be compressed using the negotiated algorithm. The length field 323 and MAC will be computed from the compressed payload. Encryption 324 will be done after compression. 326 Compression MAY be stateful, depending on the method. Compression 327 MUST be independent for each direction, and implementations MUST 328 allow independently choosing the algorithm for each direction. 330 The following compression methods are currently defined: 332 none REQUIRED no compression 333 zlib OPTIONAL ZLIB (LZ77) compression 335 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 336 The compression context is initialized after each key exchange, and 337 is passed from one packet to the next with only a partial flush being 338 performed at the end of each packet. A partial flush means that the 339 current compressed block is ended and all data will be output. If 340 the current block is not a stored block, one or more empty blocks are 341 added after the current block to ensure that there are at least 8 342 bits counting from the start of the end-of-block code of the current 343 block to the end of the packet payload. 345 Additional methods may be defined as specified in [SSH-ARCH]. 347 6.3 Encryption 349 An encryption algorithm and a key will be negotiated during the key 350 exchange. When encryption is in effect, the packet length, padding 351 length, payload and padding fields of each packet MUST be encrypted 352 with the given algorithm. 354 The encrypted data in all packets sent in one direction SHOULD be 355 considered a single data stream. For example, initialization vectors 356 SHOULD be passed from the end of one packet to the beginning of the 357 next packet. All ciphers SHOULD use keys with an effective key 358 length of 128 bits or more. 360 The ciphers in each direction MUST run independent of each other, and 361 implementations MUST allow the algorithm for each direction to be 362 independently selected for each direction, if multiple algorithms are 363 allowed by local policy. 365 The following ciphers are currently defined: 367 3des-cbc REQUIRED three-key 3DES in CBC mode 368 blowfish-cbc OPTIONAL Blowfish in CBC mode 369 twofish256-cbc OPTIONAL Twofish in CBC mode, 370 with 256-bit key 371 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 372 is being retained for 373 historical reasons) 374 twofish192-cbc OPTIONAL Twofish with 192-bit key 375 twofish128-cbc OPTIONAL Twofish with 128-bit key 376 aes256-cbc OPTIONAL AES in CBC mode, 377 with 256-bit key 378 aes192-cbc OPTIONAL AES with 192-bit key 379 aes128-cbc RECOMMENDED AES with 128-bit key 380 serpent256-cbc OPTIONAL Serpent in CBC mode, with 381 256-bit key 382 serpent192-cbc OPTIONAL Serpent with 192-bit key 383 serpent128-cbc OPTIONAL Serpent with 128-bit key 384 arcfour OPTIONAL the ARCFOUR stream cipher 385 idea-cbc OPTIONAL IDEA in CBC mode 386 cast128-cbc OPTIONAL CAST-128 in CBC mode 387 none OPTIONAL no encryption; NOT RECOMMENDED 389 The "3des-cbc" cipher is three-key triple-DES 390 (encrypt-decrypt-encrypt), where the first 8 bytes of the key are 391 used for the first encryption, the next 8 bytes for the decryption, 392 and the following 8 bytes for the final encryption. This requires 24 393 bytes of key data (of which 168 bits are actually used). To 394 implement CBC mode, outer chaining MUST be used (i.e., there is only 395 one initialization vector). This is a block cipher with 8 byte 396 blocks. This algorithm is defined in [FIPS-46-3] 398 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 399 [SCHNEIER]. This is a block cipher with 8 byte blocks. 401 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 402 with 256 bit keys as described [TWOFISH]. This is a block cipher 403 with 16 byte blocks. 405 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 407 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 409 The "aes256-cbc" cipher is AES (Advanced Encryption Standard) 410 [FIPS-197], in CBC mode. This version uses 256-bit key. 412 The "aes192-cbc" cipher. Same as above but with 192-bit key. 414 The "aes128-cbc" cipher. Same as above but with 128-bit key. 416 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as 417 described in the Serpent AES submission. 419 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 421 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 423 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 424 Arcfour cipher is believed to be compatible with the RC4 cipher 425 [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. 426 Arcfour (and RC4) has problems with weak keys, and should be used 427 with caution. 429 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 431 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 432 [RFC2144]. 434 The "none" algorithm specifies that no encryption is to be done. 435 Note that this method provides no confidentiality protection, and it 436 is not recommended. Some functionality (e.g. password 437 authentication) may be disabled for security reasons if this cipher 438 is chosen. 440 Additional methods may be defined as specified in [SSH-ARCH]. 442 6.4 Data Integrity 444 Data integrity is protected by including with each packet a message 445 authentication code (MAC) that is computed from a shared secret, 446 packet sequence number, and the contents of the packet. 448 The message authentication algorithm and key are negotiated during 449 key exchange. Initially, no MAC will be in effect, and its length 450 MUST be zero. After key exchange, the selected MAC will be computed 451 before encryption from the concatenation of packet data: 453 mac = MAC(key, sequence_number || unencrypted_packet) 455 where unencrypted_packet is the entire packet without MAC (the length 456 fields, payload and padding), and sequence_number is an implicit 457 packet sequence number represented as uint32. The sequence number is 458 initialized to zero for the first packet, and is incremented after 459 every packet (regardless of whether encryption or MAC is in use). It 460 is never reset, even if keys/algorithms are renegotiated later. It 461 wraps around to zero after every 2^32 packets. The packet sequence 462 number itself is not included in the packet sent over the wire. 464 The MAC algorithms for each direction MUST run independently, and 465 implementations MUST allow choosing the algorithm independently for 466 both directions. 468 The MAC bytes resulting from the MAC algorithm MUST be transmitted 469 without encryption as the last part of the packet. The number of MAC 470 bytes depends on the algorithm chosen. 472 The following MAC algorithms are currently defined: 474 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 475 length = 20) 476 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 477 length = 12, key length = 20) 478 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 479 length = 16) 480 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 481 length = 12, key length = 16) 482 none OPTIONAL no MAC; NOT RECOMMENDED 484 Figure 1 486 The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs 487 use only the first n bits of the resulting value. 489 The hash algorithms are described in [SCHNEIER]. 491 Additional methods may be defined as specified in [SSH-ARCH]. 493 6.5 Key Exchange Methods 495 The key exchange method specifies how one-time session keys are 496 generated for encryption and for authentication, and how the server 497 authentication is done. 499 Two REQUIRED key exchange methods have been defined: 501 diffie-hellman-group1-sha1 REQUIRED 502 diffie-hellman-group14-sha1 REQUIRED 504 These methods are described later in this document. 506 Editor's Note: diffie-hellman-group14-sha1 is controversial at the 507 moment. It is being discussed on the mailing list. 509 Additional methods may be defined as specified in [SSH-NUMBERS]. 510 Note that, for historical reasons, the name 511 "diffie-hellman-group1-sha1" is used for a key exchange method using 512 Oakley Group 2. This is considered an aberration and should not be 513 repeated. Any future specifications of Diffie Hellman key exchange 514 using Oakley groups defined in [RFC2412] or its successors should be 515 named using the group numbers assigned by IANA, and names of the form 516 "diffie-hellman-groupN-sha1" should be reserved for this purpose. 518 6.6 Public Key Algorithms 520 This protocol has been designed to be able to operate with almost any 521 public key format, encoding, and algorithm (signature and/or 522 encryption). 524 There are several aspects that define a public key type: 525 o Key format: how is the key encoded and how are certificates 526 represented. The key blobs in this protocol MAY contain 527 certificates in addition to keys. 528 o Signature and/or encryption algorithms. Some key types may not 529 support both signing and encryption. Key usage may also be 530 restricted by policy statements in e.g. certificates. In this 531 case, different key types SHOULD be defined for the different 532 policy alternatives. 534 o Encoding of signatures and/or encrypted data. This includes but 535 is not limited to padding, byte order, and data formats. 537 The following public key and/or certificate formats are currently 538 defined: 540 ssh-dss REQUIRED sign Raw DSS Key 541 ssh-rsa RECOMMENDED sign Raw RSA Key 542 x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) 543 x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) 544 spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) 545 spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) 546 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 547 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 549 Additional key types may be defined as specified in [SSH-ARCH]. 551 The key type MUST always be explicitly known (from algorithm 552 negotiation or some other source). It is not normally included in 553 the key blob. 555 Certificates and public keys are encoded as follows: 556 string certificate or public key format identifier 557 byte[n] key/certificate data 559 The certificate part may have be a zero length string, but a public 560 key is required. This is the public key that will be used for 561 authentication. The certificate sequence contained in the 562 certificate blob can be used to provide authorization. 564 Public key / certificate formats that do not explicitly specify a 565 signature format identifier MUST use the public key / certificate 566 format identifier as the signature identifier. 568 Signatures are encoded as follows: 569 string signature format identifier (as specified by the 570 public key / cert format) 571 byte[n] signature blob in format specific encoding. 573 The "ssh-dss" key format has the following specific encoding: 575 string "ssh-dss" 576 mpint p 577 mpint q 578 mpint g 579 mpint y 581 Here the p, q, g, and y parameters form the signature key blob. 583 Signing and verifying using this key format is done according to the 584 Digital Signature Standard [FIPS-186-2] using the SHA-1 hash. 586 The resulting signature is encoded as follows: 588 string "ssh-dss" 589 string dss_signature_blob 591 dss_signature_blob is encoded as a string containing r followed by s 592 (which are 160 bits long integers, without lengths or padding, 593 unsigned and in network byte order). 595 The "ssh-rsa" key format has the following specific encoding: 597 string "ssh-rsa" 598 mpint e 599 mpint n 601 Here the e and n parameters form the signature key blob. 603 Signing and verifying using this key format is done according to 604 [SCHNEIER] and [RFC3447] using the SHA-1 hash. 606 The resulting signature is encoded as follows: 608 string "ssh-rsa" 609 string rsa_signature_blob 611 rsa_signature_blob is encoded as a string containing s (which is an 612 integer, without lengths or padding, unsigned and in network byte 613 order). 615 The "spki-sign-rsa" method indicates that the certificate blob 616 contains a sequence of SPKI certificates. The format of SPKI 617 certificates is described in [RFC2693]. This method indicates that 618 the key (or one of the keys in the certificate) is an RSA-key. 620 The "spki-sign-dss". As above, but indicates that the key (or one of 621 the keys in the certificate) is a DSS-key. 623 The "pgp-sign-rsa" method indicates the certificates, the public key, 624 and the signature are in OpenPGP compatible binary format 625 ([RFC2440]). This method indicates that the key is an RSA-key. 627 The "pgp-sign-dss". As above, but indicates that the key is a 628 DSS-key. 630 7. Key Exchange 632 Key exchange (kex) begins by each side sending lists of supported 633 algorithms. Each side has a preferred algorithm in each category, 634 and it is assumed that most implementations at any given time will 635 use the same preferred algorithm. Each side MAY guess which 636 algorithm the other side is using, and MAY send an initial key 637 exchange packet according to the algorithm if appropriate for the 638 preferred method. 640 The guess is considered wrong, if: 641 o the kex algorithm and/or the host key algorithm is guessed wrong 642 (server and client have different preferred algorithm), or 643 o if any of the other algorithms cannot be agreed upon (the 644 procedure is defined below in Section 7.1). 646 Otherwise, the guess is considered to be right and the optimistically 647 sent packet MUST be handled as the first key exchange packet. 649 However, if the guess was wrong, and a packet was optimistically sent 650 by one or both parties, such packets MUST be ignored (even if the 651 error in the guess would not affect the contents of the initial 652 packet(s)), and the appropriate side MUST send the correct initial 653 packet. 655 Server authentication in the key exchange MAY be implicit. After a 656 key exchange with implicit server authentication, the client MUST 657 wait for response to its service request message before sending any 658 further data. 660 7.1 Algorithm Negotiation 662 Key exchange begins by each side sending the following packet: 664 byte SSH_MSG_KEXINIT 665 byte[16] cookie (random bytes) 666 string kex_algorithms 667 string server_host_key_algorithms 668 string encryption_algorithms_client_to_server 669 string encryption_algorithms_server_to_client 670 string mac_algorithms_client_to_server 671 string mac_algorithms_server_to_client 672 string compression_algorithms_client_to_server 673 string compression_algorithms_server_to_client 674 string languages_client_to_server 675 string languages_server_to_client 676 boolean first_kex_packet_follows 677 uint32 0 (reserved for future extension) 679 Each of the algorithm strings MUST be a comma-separated list of 680 algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each 681 supported (allowed) algorithm MUST be listed in order of preference. 683 The first algorithm in each list MUST be the preferred (guessed) 684 algorithm. Each string MUST contain at least one algorithm name. 686 cookie 687 The cookie MUST be a random value generated by the sender. Its 688 purpose is to make it impossible for either side to fully 689 determine the keys and the session identifier. 691 kex_algorithms 692 Key exchange algorithms were defined above. The first 693 algorithm MUST be the preferred (and guessed) algorithm. If 694 both sides make the same guess, that algorithm MUST be used. 695 Otherwise, the following algorithm MUST be used to choose a key 696 exchange method: Iterate over client's kex algorithms, one at a 697 time. Choose the first algorithm that satisfies the following 698 conditions: 699 + the server also supports the algorithm, 700 + if the algorithm requires an encryption-capable host key, 701 there is an encryption-capable algorithm on the server's 702 server_host_key_algorithms that is also supported by the 703 client, and 704 + if the algorithm requires a signature-capable host key, 705 there is a signature-capable algorithm on the server's 706 server_host_key_algorithms that is also supported by the 707 client. 708 If no algorithm satisfying all these conditions can be found, 709 the connection fails, and both sides MUST disconnect. 711 server_host_key_algorithms 712 List of the algorithms supported for the server host key. The 713 server lists the algorithms for which it has host keys; the 714 client lists the algorithms that it is willing to accept. 715 (There MAY be multiple host keys for a host, possibly with 716 different algorithms.) 718 Some host keys may not support both signatures and encryption 719 (this can be determined from the algorithm), and thus not all 720 host keys are valid for all key exchange methods. 722 Algorithm selection depends on whether the chosen key exchange 723 algorithm requires a signature or encryption capable host key. 724 It MUST be possible to determine this from the public key 725 algorithm name. The first algorithm on the client's list that 726 satisfies the requirements and is also supported by the server 727 MUST be chosen. If there is no such algorithm, both sides MUST 728 disconnect. 730 encryption_algorithms 731 Lists the acceptable symmetric encryption algorithms in order 732 of preference. The chosen encryption algorithm to each 733 direction MUST be the first algorithm on the client's list 734 that is also on the server's list. If there is no such 735 algorithm, both sides MUST disconnect. 737 Note that "none" must be explicitly listed if it is to be 738 acceptable. The defined algorithm names are listed in Section 739 6.3. 741 mac_algorithms 742 Lists the acceptable MAC algorithms in order of preference. 743 The chosen MAC algorithm MUST be the first algorithm on the 744 client's list that is also on the server's list. If there is 745 no such algorithm, both sides MUST disconnect. 747 Note that "none" must be explicitly listed if it is to be 748 acceptable. The MAC algorithm names are listed in Section 749 Figure 1. 751 compression_algorithms 752 Lists the acceptable compression algorithms in order of 753 preference. The chosen compression algorithm MUST be the first 754 algorithm on the client's list that is also on the server's 755 list. If there is no such algorithm, both sides MUST 756 disconnect. 758 Note that "none" must be explicitly listed if it is to be 759 acceptable. The compression algorithm names are listed in 760 Section 6.2. 762 languages 763 This is a comma-separated list of language tags in order of 764 preference [RFC3066]. Both parties MAY ignore this list. If 765 there are no language preferences, this list SHOULD be empty. 766 Language tags SHOULD NOT be present unless they are known to be 767 needed by the sending party. 769 first_kex_packet_follows 770 Indicates whether a guessed key exchange packet follows. If a 771 guessed packet will be sent, this MUST be TRUE. If no guessed 772 packet will be sent, this MUST be FALSE. 774 After receiving the SSH_MSG_KEXINIT packet from the other side, 775 each party will know whether their guess was right. If the 776 other party's guess was wrong, and this field was TRUE, the 777 next packet MUST be silently ignored, and both sides MUST then 778 act as determined by the negotiated key exchange method. If 779 the guess was right, key exchange MUST continue using the 780 guessed packet. 782 After the KEXINIT packet exchange, the key exchange algorithm is run. 783 It may involve several packet exchanges, as specified by the key 784 exchange method. 786 Once a party has sent a KEXINIT message for key exchange or 787 re-exchange, until is has sent a NEWKEYS message (Section 7.3), it 788 MUST NOT send any messages other than: 789 o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST 790 and SERVICE_ACCEPT MUST NOT be sent); 791 o Algorithm negotiation messages (20 to 29) (but further KEXINITs 792 MUST NOT be sent); 793 o Specific key exchange method messages (30 to 49). 795 The provisions of Section 11 apply for unrecognised messages. 797 Note however that during a key re-exchange, after sending a KEXINIT 798 message, each party MUST be prepared to process an arbitrary number 799 of messages that may be in-flight before receiving a KEXINIT from the 800 other party. 802 7.2 Output from Key Exchange 804 The key exchange produces two values: a shared secret K, and an 805 exchange hash H. Encryption and authentication keys are derived from 806 these. The exchange hash H from the first key exchange is 807 additionally used as the session identifier, which is a unique 808 identifier for this connection. It is used by authentication methods 809 as a part of the data that is signed as a proof of possession of a 810 private key. Once computed, the session identifier is not changed, 811 even if keys are later re-exchanged. 813 Each key exchange method specifies a hash function that is used in 814 the key exchange. The same hash algorithm MUST be used in key 815 derivation. Here, we'll call it HASH. 817 Encryption keys MUST be computed as HASH of a known value and K as 818 follows: 820 o Initial IV client to server: HASH(K || H || "A" || session_id) 821 (Here K is encoded as mpint and "A" as byte and session_id as raw 822 data. "A" means the single character A, ASCII 65). 823 o Initial IV server to client: HASH(K || H || "B" || session_id) 824 o Encryption key client to server: HASH(K || H || "C" || session_id) 825 o Encryption key server to client: HASH(K || H || "D" || session_id) 826 o Integrity key client to server: HASH(K || H || "E" || session_id) 827 o Integrity key server to client: HASH(K || H || "F" || session_id) 829 Key data MUST be taken from the beginning of the hash output. 128 830 bits (16 bytes) MUST be used for algorithms with variable-length 831 keys. The only variable key length algorithm defined in this 832 document is arcfour). For other algorithms, as many bytes as are 833 needed are taken from the beginning of the hash value. If the key 834 length needed is longer than the output of the HASH, the key is 835 extended by computing HASH of the concatenation of K and H and the 836 entire key so far, and appending the resulting bytes (as many as HASH 837 generates) to the key. This process is repeated until enough key 838 material is available; the key is taken from the beginning of this 839 value. In other words: 841 K1 = HASH(K || H || X || session_id) (X is e.g. "A") 842 K2 = HASH(K || H || K1) 843 K3 = HASH(K || H || K1 || K2) 844 ... 845 key = K1 || K2 || K3 || ... 847 This process will lose entropy if the amount of entropy in K is 848 larger than the internal state size of HASH. 850 7.3 Taking Keys Into Use 852 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 853 This message is sent with the old keys and algorithms. All messages 854 sent after this message MUST use the new keys and algorithms. 856 When this message is received, the new keys and algorithms MUST be 857 taken into use for receiving. 859 The purpose of this message is to ensure that a party is able to 860 respond with a SSH_MSG_DISCONNECT message that the other party can 861 understand if something goes wrong with the key exchange. 863 byte SSH_MSG_NEWKEYS 865 8. Diffie-Hellman Key Exchange 867 The Diffie-Hellman (DH) key exchange provides a shared secret that 868 can not be determined by either party alone. The key exchange is 869 combined with a signature with the host key to provide host 870 authentication. 872 In the following description (C is the client, S is the server; p is 873 a large safe prime, g is a generator for a subgroup of GF(p), and q 874 is the order of the subgroup; V_S is S's version string; V_C is C's 875 version string; K_S is S's public host key; I_C is C's KEXINIT 876 message and I_S S's KEXINIT message which have been exchanged before 877 this part begins): 879 1. C generates a random number x (1 < x < q) and computes e = g^x 880 mod p. C sends "e" to S. 882 2. S generates a random number y (0 < y < q) and computes f = g^y 883 mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C 884 || V_S || I_C || I_S || K_S || e || f || K) (these elements are 885 encoded according to their types; see below), and signature s on 886 H with its private host key. S sends "K_S || f || s" to C. The 887 signing operation may involve a second hashing operation. 889 3. C verifies that K_S really is the host key for S (e.g. using 890 certificates or a local database). C is also allowed to accept 891 the key without verification; however, doing so will render the 892 protocol insecure against active attacks (but may be desirable 893 for practical reasons in the short term in many environments). C 894 then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || 895 K_S || e || f || K), and verifies the signature s on H. 897 Either side MUST NOT send or accept e or f values that are not in the 898 range [1, p-1]. If this condition is violated, the key exchange 899 fails. 901 This is implemented with the following messages. The hash algorithm 902 for computing the exchange hash is defined by the method name, and is 903 called HASH. The public key algorithm for signing is negotiated with 904 the KEXINIT messages. 906 First, the client sends the following: 908 byte SSH_MSG_KEXDH_INIT 909 mpint e 911 The server responds with the following: 913 byte SSH_MSG_KEXDH_REPLY 914 string server public host key and certificates (K_S) 915 mpint f 916 string signature of H 918 The hash H is computed as the HASH hash of the concatenation of the 919 following: 921 string V_C, the client's version string (CR and NL excluded) 922 string V_S, the server's version string (CR and NL excluded) 923 string I_C, the payload of the client's SSH_MSG_KEXINIT 924 string I_S, the payload of the server's SSH_MSG_KEXINIT 925 string K_S, the host key 926 mpint e, exchange value sent by the client 927 mpint f, exchange value sent by the server 928 mpint K, the shared secret 930 This value is called the exchange hash, and it is used to 931 authenticate the key exchange. The exchange hash SHOULD be kept 932 secret. 934 The signature algorithm MUST be applied over H, not the original 935 data. Most signature algorithms include hashing and additional 936 padding. For example, "ssh-dss" specifies SHA-1 hashing; in that 937 case, the data is first hashed with HASH to compute H, and H is then 938 hashed with SHA-1 as part of the signing operation. 940 8.1 diffie-hellman-group1-sha1 942 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 943 exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit 944 MODP Group). This method MUST be supported for interoperability as 945 all of the known implementations currently support it. Note that, 946 for historical reasons, this method is named using the phrase 947 "group1" even though it specifies the use of Oakley Group 2. 949 8.2 diffie-hellman-group14-sha1 951 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key 952 exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit 953 MODP Group), and it MUST also be supported. 955 Editor's Note: diffie-hellman-group14-sha1 is controversial at the 956 moment. It is being discussed on the mailing list. 958 9. Key Re-Exchange 960 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when 961 not already doing a key exchange (as described in Section 7.1). When 962 this message is received, a party MUST respond with its own 963 SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT 964 already was a reply. Either party MAY initiate the re-exchange, but 965 roles MUST NOT be changed (i.e., the server remains the server, and 966 the client remains the client). 968 Key re-exchange is performed using whatever encryption was in effect 969 when the exchange was started. Encryption, compression, and MAC 970 methods are not changed before a new SSH_MSG_NEWKEYS is sent after 971 the key exchange (as in the initial key exchange). Re-exchange is 972 processed identically to the initial key exchange, except for the 973 session identifier that will remain unchanged. It is permissible to 974 change some or all of the algorithms during the re-exchange. Host 975 keys can also change. All keys and initialization vectors are 976 recomputed after the exchange. Compression and encryption contexts 977 are reset. 979 It is recommended that the keys are changed after each gigabyte of 980 transmitted data or after each hour of connection time, whichever 981 comes sooner. However, since the re-exchange is a public key 982 operation, it requires a fair amount of processing power and should 983 not be performed too often. 985 More application data may be sent after the SSH_MSG_NEWKEYS packet 986 has been sent; key exchange does not affect the protocols that lie 987 above the SSH transport layer. 989 10. Service Request 991 After the key exchange, the client requests a service. The service 992 is identified by a name. The format of names and procedures for 993 defining new names are defined in [SSH-ARCH]. 995 Currently, the following names have been reserved: 997 ssh-userauth 998 ssh-connection 1000 Similar local naming policy is applied to the service names, as is 1001 applied to the algorithm names. A local service should use the 1002 PRIVATE USE syntax of "servicename@domain". 1004 byte SSH_MSG_SERVICE_REQUEST 1005 string service name 1007 If the server rejects the service request, it SHOULD send an 1008 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 1010 When the service starts, it may have access to the session identifier 1011 generated during the key exchange. 1013 If the server supports the service (and permits the client to use 1014 it), it MUST respond with the following: 1016 byte SSH_MSG_SERVICE_ACCEPT 1017 string service name 1019 Message numbers used by services should be in the area reserved for 1020 them (see [SSH-ARCH]). The transport level will continue to process 1021 its own messages. 1023 Note that after a key exchange with implicit server authentication, 1024 the client MUST wait for response to its service request message 1025 before sending any further data. 1027 11. Additional Messages 1029 Either party may send any of the following messages at any time. 1031 11.1 Disconnection Message 1032 byte SSH_MSG_DISCONNECT 1033 uint32 reason code 1034 string description [RFC3629] 1035 string language tag [RFC3066] 1037 This message causes immediate termination of the connection. All 1038 implementations MUST be able to process this message; they SHOULD be 1039 able to send this message. 1041 The sender MUST NOT send or receive any data after this message, and 1042 the recipient MUST NOT accept any data after receiving this message. 1043 The Disconnection Message 'description' string gives a more specific 1044 explanation in a human-readable form. The Disconnection Message 1045 'reason code' gives the reason in a more machine-readable format 1046 (suitable for localization), and can have the following values: 1048 description reason code 1049 ----------- ----------- 1050 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 1051 SSH_DISCONNECT_PROTOCOL_ERROR 2 1052 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 1053 SSH_DISCONNECT_RESERVED 4 1054 SSH_DISCONNECT_MAC_ERROR 5 1055 SSH_DISCONNECT_COMPRESSION_ERROR 6 1056 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1057 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1058 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1059 SSH_DISCONNECT_CONNECTION_LOST 10 1060 SSH_DISCONNECT_BY_APPLICATION 11 1061 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1062 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1063 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1064 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1066 If the 'description' string is displayed, control character filtering 1067 discussed in [SSH-ARCH] should be used to avoid attacks by sending 1068 terminal control characters. 1070 Requests for assignments of new Disconnection Message 'reason codes' 1071 (and associated 'description' text) in the range of 0x00000000 to 1072 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 1073 described in [RFC2434]. The Disconnection Message 'reason code' 1074 values in the range of 0xFF000000 to 0xFFFFFFFF are reserved for 1075 PRIVATE USE. The Disconnection Message 'reason code' values in the 1076 range of 0xFE000000 to 0xFEFFFFFF are not defined at this time. The 1077 definition of values in this range MUST be done through the STANDARDS 1078 ACTION method as described in [RFC2434]. As is noted, the actual 1079 instructions to the IANA is in [SSH-NUMBERS]. 1081 11.2 Ignored Data Message 1082 byte SSH_MSG_IGNORE 1083 string data 1085 All implementations MUST understand (and ignore) this message at any 1086 time (after receiving the protocol version). No implementation is 1087 required to send them. This message can be used as an additional 1088 protection measure against advanced traffic analysis techniques. 1090 11.3 Debug Message 1091 byte SSH_MSG_DEBUG 1092 boolean always_display 1093 string message [RFC3629] 1094 string language tag [RFC3066] 1096 All implementations MUST understand this message, but they are 1097 allowed to ignore it. This message is used to transmit information 1098 that may help debugging. If always_display is TRUE, the message 1099 SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 1100 debugging information has been explicitly requested by the user. 1102 The message doesn't need to contain a newline. It is, however, 1103 allowed to consist of multiple lines separated by CRLF (Carriage 1104 Return - Line Feed) pairs. 1106 If the message string is displayed, terminal control character 1107 filtering discussed in [SSH-ARCH] should be used to avoid attacks by 1108 sending terminal control characters. 1110 11.4 Reserved Messages 1112 An implementation MUST respond to all unrecognized messages with an 1113 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1114 received. Such messages MUST be otherwise ignored. Later protocol 1115 versions may define other meanings for these message types. 1116 byte SSH_MSG_UNIMPLEMENTED 1117 uint32 packet sequence number of rejected message 1119 12. Summary of Message Numbers 1121 The following message numbers have been defined in this protocol: 1123 SSH_MSG_DISCONNECT 1 1124 SSH_MSG_IGNORE 2 1125 SSH_MSG_UNIMPLEMENTED 3 1126 SSH_MSG_DEBUG 4 1127 SSH_MSG_SERVICE_REQUEST 5 1128 SSH_MSG_SERVICE_ACCEPT 6 1129 SSH_MSG_KEXINIT 20 1130 SSH_MSG_NEWKEYS 21 1131 SSH_MSG_KEXDH_INIT 30 1132 SSH_MSG_KEXDH_REPLY 31 1134 Note that Numbers 30-49 are used for kex packets. Different kex 1135 methods may reuse message numbers in this range. 1137 13. IANA Considerations 1139 This document is part of a set. The IANA considerations for the SSH 1140 protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and 1141 this document, are detailed in [SSH-NUMBERS]. 1143 14. Security Considerations 1145 This protocol provides a secure encrypted channel over an insecure 1146 network. It performs server host authentication, key exchange, 1147 encryption, and integrity protection. It also derives a unique 1148 session id that may be used by higher-level protocols. 1150 Full security considerations for this protocol are provided in 1151 [SSH-ARCH]. 1153 15. References 1155 15.1 Normative 1157 [SSH-ARCH] 1158 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 1159 I-D draft-ietf-architecture-17.txt, October 2004. 1161 [SSH-USERAUTH] 1162 Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", 1163 I-D draft-ietf-userauth-22.txt, October 2004. 1165 [SSH-CONNECT] 1166 Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D 1167 draft-ietf-connect-20.txt, October 2004. 1169 [SSH-NUMBERS] 1170 Ylonen, T. and C. Lonvick, "SSH Protocol Assigned 1171 Numbers", I-D draft-ietf-assignednumbers-07.txt, October 1172 2004. 1174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1175 Requirement Levels", BCP 14, RFC 2119, March 1997. 1177 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1178 10646", STD 63, RFC 3629, November 2003. 1180 15.2 Informative 1182 [FIPS-186-2] 1183 Federal Information Processing Standards Publication, 1184 "FIPS PUB 186-2, Digital Signature Standard (DSS)", 1185 January 2000. 1187 [FIPS-197] 1188 NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", 1189 November 2001. 1191 [FIPS-46-3] 1192 U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption 1193 Standard (DES)", October 1999. 1195 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1196 STD 13, RFC 1034, November 1987. 1198 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1199 Specification version 3.3", RFC 1950, May 1996. 1201 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1202 version 1.3", RFC 1951, May 1996. 1204 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1205 Keyed-Hashing for Message Authentication", RFC 2104, 1206 February 1997. 1208 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1209 May 1997. 1211 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1212 (IKE)", RFC 2409, November 1998. 1214 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 1215 2412, November 1998. 1217 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1218 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1219 October 1998. 1221 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1222 "OpenPGP Message Format", RFC 2440, November 1998. 1224 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1225 B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1226 September 1999. 1228 [RFC3066] Alvestrand, H., "Tags for the Identification of 1229 Languages", BCP 47, RFC 3066, January 2001. 1231 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1232 X.509 Public Key Infrastructure Certificate and 1233 Certificate Revocation List (CRL) Profile", RFC 3280, 1234 April 2002. 1236 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1237 Standards (PKCS) #1: RSA Cryptography Specifications 1238 Version 2.1", RFC 3447, February 2003. 1240 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1241 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1242 RFC 3526, May 2003. 1244 [SCHNEIER] 1245 Schneier, B., "Applied Cryptography Second Edition: 1246 protocols algorithms and source in code in C", 1996. 1248 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1249 128-Bit Block Cipher, 1st Edition", March 1999. 1251 Author's Address 1253 Chris Lonvick (editor) 1254 Cisco Systems, Inc 1255 12515 Research Blvd. 1256 Austin 78759 1257 USA 1259 EMail: clonvick@cisco.com 1261 Intellectual Property Statement 1263 The IETF takes no position regarding the validity or scope of any 1264 Intellectual Property Rights or other rights that might be claimed to 1265 pertain to the implementation or use of the technology described in 1266 this document or the extent to which any license under such rights 1267 might or might not be available; nor does it represent that it has 1268 made any independent effort to identify any such rights. Information 1269 on the procedures with respect to rights in RFC documents can be 1270 found in BCP 78 and BCP 79. 1272 Copies of IPR disclosures made to the IETF Secretariat and any 1273 assurances of licenses to be made available, or the result of an 1274 attempt made to obtain a general license or permission for the use of 1275 such proprietary rights by implementers or users of this 1276 specification can be obtained from the IETF on-line IPR repository at 1277 http://www.ietf.org/ipr. 1279 The IETF invites any interested party to bring to its attention any 1280 copyrights, patents or patent applications, or other proprietary 1281 rights that may cover technology that may be required to implement 1282 this standard. Please address the information to the IETF at 1283 ietf-ipr@ietf.org. 1285 The IETF has been notified of intellectual property rights claimed in 1286 regard to some or all of the specification contained in this 1287 document. For more information consult the online list of claimed 1288 rights. 1290 Disclaimer of Validity 1292 This document and the information contained herein are provided on an 1293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1295 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1296 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1297 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1300 Copyright Statement 1302 Copyright (C) The Internet Society (2004). This document is subject 1303 to the rights, licenses and restrictions contained in BCP 78, and 1304 except as set forth therein, the authors retain all their rights. 1306 Acknowledgment 1308 Funding for the RFC Editor function is currently provided by the 1309 Internet Society.