idnits 2.17.1 draft-ietf-secsh-transport-24.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1379. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 163 has weird spacing: '... string dat...' == Line 628 has weird spacing: '... string cer...' == Line 641 has weird spacing: '... string sig...' == Line 662 has weird spacing: '... string dss...' == Line 682 has weird spacing: '... string rsa...' == (20 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 (March 14, 2005) is 6984 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 739 ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-197' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH' -- Obsolete informational reference (is this intentional?): RFC 1134 (Obsoleted by RFC 1171) Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ylonen 3 Internet-Draft SSH Communications Security Corp 4 Expires: September 15, 2005 C. Lonvick, Ed. 5 Cisco Systems, Inc. 6 March 14, 2005 8 SSH Transport Layer Protocol 9 draft-ietf-secsh-transport-24.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 SSH is a protocol for secure remote login and other secure network 45 services over an insecure network. 47 This document describes the SSH transport layer protocol which 48 typically runs on top of TCP/IP. The protocol can be used as a basis 49 for a number of secure network services. It provides strong 50 encryption, server authentication, and integrity protection. It may 51 also provide compression. 53 Key exchange method, public key algorithm, symmetric encryption 54 algorithm, message authentication algorithm, and hash algorithm are 55 all negotiated. 57 This document also describes the Diffie-Hellman key exchange method 58 and the minimal set of algorithms that are needed to implement the 59 SSH transport layer protocol. 61 Table of Contents 63 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Conventions Used in This Document . . . . . . . . . . . . . 4 66 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . 5 68 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . 5 69 5. Compatibility With Old SSH Versions . . . . . . . . . . . . 6 70 5.1 Old Client, New Server . . . . . . . . . . . . . . . . . . 7 71 5.2 New Client, Old Server . . . . . . . . . . . . . . . . . . 7 72 5.3 Packet Size and Overhead . . . . . . . . . . . . . . . . . 7 73 6. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 8 74 6.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . 9 75 6.2 Compression . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . 12 78 6.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . 13 79 6.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . 14 80 7. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . 17 82 7.2 Output from Key Exchange . . . . . . . . . . . . . . . . . 20 83 7.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . 21 84 8. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 21 85 8.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . 22 86 8.2 diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 23 87 9. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 23 88 10. Service Request . . . . . . . . . . . . . . . . . . . . . . 23 89 11. Additional Messages . . . . . . . . . . . . . . . . . . . . 24 90 11.1 Disconnection Message . . . . . . . . . . . . . . . . . 24 91 11.2 Ignored Data Message . . . . . . . . . . . . . . . . . . 25 92 11.3 Debug Message . . . . . . . . . . . . . . . . . . . . . 26 93 11.4 Reserved Messages . . . . . . . . . . . . . . . . . . . 26 94 12. Summary of Message Numbers . . . . . . . . . . . . . . . . . 26 95 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 96 14. Security Considerations . . . . . . . . . . . . . . . . . . 27 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 15.1 Normative . . . . . . . . . . . . . . . . . . . . . . . 27 99 15.2 Informative . . . . . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 101 A. Trademark Notice . . . . . . . . . . . . . . . . . . . . . . 30 102 Intellectual Property and Copyright Statements . . . . . . . 31 104 1. Contributors 106 The major original contributors of this set of documents have been: 107 Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 108 Communications Security Corp), and Markku-Juhani O. Saarinen 109 (University of Jyvaskyla). Darren Moffit was the original editor of 110 this set of documents and also made very substantial contributions. 112 Many people contributed to the development of this document over the 113 years. People who should be acknowledged include Mats Andersson, Ben 114 Harris, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, 115 Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, 116 Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken 117 Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels 118 Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, 119 Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their 120 names here does not mean that they endorse this document, but that 121 they have contributed to it. 123 2. Introduction 125 The SSH transport layer is a secure low level transport protocol. It 126 provides strong encryption, cryptographic host authentication, and 127 integrity protection. 129 Authentication in this protocol level is host-based; this protocol 130 does not perform user authentication. A higher level protocol for 131 user authentication can be designed on top of this protocol. 133 The protocol has been designed to be simple, flexible, to allow 134 parameter negotiation, and to minimize the number of round-trips. 135 Key exchange method, public key algorithm, symmetric encryption 136 algorithm, message authentication algorithm, and hash algorithm are 137 all negotiated. It is expected that in most environments, only 2 138 round-trips will be needed for full key exchange, server 139 authentication, service request, and acceptance notification of 140 service request. The worst case is 3 round-trips. 142 3. Conventions Used in This Document 144 All documents related to the SSH protocols shall use the keywords 145 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 146 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 147 requirements. These keywords are to be interpreted as described in 148 [RFC2119]. 150 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 151 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 152 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 153 this document when used to describe namespace allocation are to be 154 interpreted as described in [RFC2434]. 156 Protocol fields and possible values to fill them are defined in this 157 set of documents. Protocol fields will be defined in the message 158 definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as 159 follows. 161 byte SSH_MSG_CHANNEL_DATA 162 uint32 recipient channel 163 string data 165 Throughout these documents, when the fields are referenced, they will 166 appear within single quotes. When values to fill those fields are 167 referenced, they will appear within double quotes. Using the above 168 example, possible values for 'data' are "foo" and "bar". 170 4. Connection Setup 172 SSH works over any 8-bit clean, binary-transparent transport. The 173 underlying transport SHOULD protect against transmission errors as 174 such errors cause the SSH connection to terminate. 176 The client initiates the connection. 178 4.1 Use over TCP/IP 180 When used over TCP/IP, the server normally listens for connections on 181 port 22. This port number has been registered with the IANA, and has 182 been officially assigned for SSH. 184 4.2 Protocol Version Exchange 186 When the connection has been established, both sides MUST send an 187 identification string. This identification string MUST be 188 SSH-protoversion-softwareversion SP comments CR LF 190 Since the protocol being defined in this set of documents is version 191 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is 192 OPTIONAL. If the 'comments' string is included, a 'space' character 193 (denoted above as SP, ASCII 32) MUST separate the 'softwareversion' 194 and 'comments' strings. The identification MUST be terminated by a 195 single Carriage Return and a single Line Feed character (ASCII 13 and 196 10, respectively). Implementors who wish to maintain compatibility 197 with older, undocumented versions of this protocol, may want to 198 process the identification string without expecting the presence of 199 the carriage return character for reasons described in Section 5 of 200 this document. The null character MUST NOT be sent. The maximum 201 length of the string is 255 characters, including the Carriage Return 202 and Line Feed. 204 The part of the identification string preceding Carriage Return and 205 Line Feed is used in the Diffie-Hellman key exchange (see 206 Section 8). 208 The server MAY send other lines of data before sending the version 209 string. Each line SHOULD be terminated by a Carriage Return and Line 210 Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 211 in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients 212 MUST be able to process such lines. They MAY be silently ignored, or 213 MAY be displayed to the client user. If they are displayed, control 214 character filtering discussed in [SSH-ARCH] SHOULD be used. The 215 primary use of this feature is to allow TCP-wrappers to display an 216 error message before disconnecting. 218 Both the 'protoversion' and 'softwareversion' strings MUST consist of 219 printable US-ASCII characters with the exception of whitespace 220 characters and the minus sign (-). The 'softwareversion' string is 221 primarily used to trigger compatibility extensions and to indicate 222 the capabilities of an implementation. The 'comments' string SHOULD 223 contain additional information that might be useful in solving user 224 problems. As such, an example of a valid identification string is 225 SSH-2.0-billsSSH_3.6.3q3 227 This identification string does not contain the optional 'comments' 228 string and is thusly terminated by a CR and LF immediately after the 229 'softwareversion' string. 231 Key exchange will begin immediately after sending this identifier. 232 All packets following the identification string SHALL use the binary 233 packet protocol which is described in Section 6. 235 5. Compatibility With Old SSH Versions 237 As stated earlier, the 'protoversion' specified for this protocol is 238 "2.0". Earlier versions of this protocol have not been formally 239 documented but it is widely known that they use 'protoversion' of 240 "1.x" (e.g., "1.5" or "1.3"). At the time of this writing, many 241 implementations of SSH are utilizing protocol version 2.0 but it is 242 known that there are still devices using the previous versions. 243 During the transition period, it is important to be able to work in a 244 way that is compatible with the installed SSH clients and servers 245 that use the older version of the protocol. Information in this 246 section is only relevant for implementations supporting compatibility 247 with SSH versions 1.x. For those interested, the only known 248 documentation of the 1.x protocol is contained in README files that 249 are shipped along with the source code. [ssh-1.2.30] 251 5.1 Old Client, New Server 253 Server implementations MAY support a configurable "compatibility" 254 flag that enables compatibility with old versions. When this flag is 255 on, the server SHOULD identify its protocol version as "1.99". 256 Clients using protocol 2.0 MUST be able to identify this as identical 257 to "2.0". In this mode the server SHOULD NOT send the carriage 258 return character (ASCII 13) after the version identification string. 260 In the compatibility mode the server SHOULD NOT send any further data 261 after its initialization string until it has received an 262 identification string from the client. The server can then determine 263 whether the client is using an old protocol, and can revert to the 264 old protocol if required. In the compatibility mode, the server MUST 265 NOT send additional data before the version string. 267 When compatibility with old clients is not needed, the server MAY 268 send its initial key exchange data immediately after the 269 identification string. 271 5.2 New Client, Old Server 273 Since the new client MAY immediately send additional data after its 274 identification string (before receiving server's identification), the 275 old protocol may already have been corrupted when the client learns 276 that the server is old. When this happens, the client SHOULD close 277 the connection to the server, and reconnect using the old protocol. 279 5.3 Packet Size and Overhead 281 Some readers will worry about the increase in packet size due to new 282 headers, padding, and Message Authentication Code (MAC). The minimum 283 packet size is in the order of 28 bytes (depending on negotiated 284 algorithms). The increase is negligible for large packets, but very 285 significant for one-byte packets (telnet-type sessions). There are, 286 however, several factors that make this a non-issue in almost all 287 cases: 288 o The minimum size of a TCP/IP header is 32 bytes. Thus, the 289 increase is actually from 33 to 51 bytes (roughly). 290 o The minimum size of the data field of an Ethernet packet is 46 291 bytes [RFC0894]. Thus, the increase is no more than 5 bytes. 292 When Ethernet headers are considered, the increase is less than 10 293 percent. 294 o The total fraction of telnet-type data in the Internet is 295 negligible, even with increased packet sizes. 297 The only environment where the packet size increase is likely to have 298 a significant effect is PPP [RFC1134] over slow modem lines (PPP 299 compresses the TCP/IP headers, emphasizing the increase in packet 300 size). However, with modern modems, the time needed to transfer is 301 in the order of 2 milliseconds, which is a lot faster than people can 302 type. 304 There are also issues related to the maximum packet size. To 305 minimize delays in screen updates, one does not want excessively 306 large packets for interactive sessions. The maximum packet size is 307 negotiated separately for each channel. 309 6. Binary Packet Protocol 311 Each packet is in the following format: 313 uint32 packet_length 314 byte padding_length 315 byte[n1] payload; n1 = packet_length - padding_length - 1 316 byte[n2] random padding; n2 = padding_length 317 byte[m] mac (Message Authentication Code - MAC); m = mac_length 319 packet_length 320 The length of the packet in bytes, not including 'mac' or the 321 'packet_length' field itself. 323 padding_length 324 Length of 'random padding' (bytes). 326 payload 327 The useful contents of the packet. If compression has been 328 negotiated, this field is compressed. Initially, compression 329 MUST be "none". 331 random padding 332 Arbitrary-length padding, such that the total length of 333 (packet_length || padding_length || payload || random padding) 334 is a multiple of the cipher block size or 8, whichever is 335 larger. There MUST be at least four bytes of padding. The 336 padding SHOULD consist of random bytes. The maximum amount of 337 padding is 255 bytes. 339 mac 340 Message Authentication Code. If message authentication has 341 been negotiated, this field contains the MAC bytes. Initially, 342 the MAC algorithm MUST be "none". 344 Note that the length of the concatenation of 'packet_length', 345 'padding_length', 'payload', and 'random padding' MUST be a multiple 346 of the cipher block size or 8, whichever is larger. This constraint 347 MUST be enforced even when using stream ciphers. Note that the 348 'packet_length' field is also encrypted, and processing it requires 349 special care when sending or receiving packets. Also note that the 350 insertion of variable amounts of 'random padding' may help thwart 351 traffic analysis. 353 The minimum size of a packet is 16 (or the cipher block size, 354 whichever is larger) bytes (plus 'mac'). Implementations SHOULD 355 decrypt the length after receiving the first 8 (or cipher block size, 356 whichever is larger) bytes of a packet. 358 6.1 Maximum Packet Length 360 All implementations MUST be able to process packets with uncompressed 361 payload length of 32768 bytes or less and total packet size of 35000 362 bytes or less (including 'packet_length', 'padding_length', 363 'payload', 'random padding', and 'mac'). The maximum of 35000 bytes 364 is an arbitrarily chosen value larger than uncompressed size. 365 Implementations SHOULD support longer packets, where they might be 366 needed. For example: if an implementation wants to send a very large 367 number of certificates, the larger packets MAY be sent if the version 368 string indicates that the other party is able to process them. 369 However, implementations SHOULD check that the packet length is 370 reasonable for the implementation to avoid denial of service and/or 371 buffer overflow attacks. 373 6.2 Compression 375 If compression has been negotiated, the 'payload' field (and only it) 376 will be compressed using the negotiated algorithm. The 377 'packet_length' field and 'mac' will be computed from the compressed 378 payload. Encryption will be done after compression. 380 Compression MAY be stateful, depending on the method. Compression 381 MUST be independent for each direction, and implementations MUST 382 allow independently choosing the algorithm for each direction. In 383 practice however, it is RECOMMENDED that the compression method be 384 the same in both directions. 386 The following compression methods are currently defined: 388 none REQUIRED no compression 389 zlib OPTIONAL ZLIB (LZ77) compression 391 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 393 The compression context is initialized after each key exchange, and 394 is passed from one packet to the next with only a partial flush being 395 performed at the end of each packet. A partial flush means that the 396 current compressed block is ended and all data will be output. If 397 the current block is not a stored block, one or more empty blocks are 398 added after the current block to ensure that there are at least 8 399 bits counting from the start of the end-of-block code of the current 400 block to the end of the packet payload. 402 Additional methods may be defined as specified in [SSH-ARCH] and 403 [SSH-NUMBERS]. 405 6.3 Encryption 407 An encryption algorithm and a key will be negotiated during the key 408 exchange. When encryption is in effect, the packet length, padding 409 length, payload and padding fields of each packet MUST be encrypted 410 with the given algorithm. 412 The encrypted data in all packets sent in one direction SHOULD be 413 considered a single data stream. For example: initialization vectors 414 SHOULD be passed from the end of one packet to the beginning of the 415 next packet. All ciphers SHOULD use keys with an effective key 416 length of 128 bits or more. 418 The ciphers in each direction MUST run independent of each other. 419 Implementations MUST allow the algorithm for each direction to be 420 independently selected, if multiple algorithms are allowed by local 421 policy. In practice however, it is RECOMMENDED that the same 422 algorithm be used in both directions. 424 The following ciphers are currently defined: 426 3des-cbc REQUIRED three-key 3DES in CBC mode 427 blowfish-cbc OPTIONAL Blowfish in CBC mode 428 twofish256-cbc OPTIONAL Twofish in CBC mode, 429 with a 256-bit key 430 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 431 is being retained for 432 historical reasons) 433 twofish192-cbc OPTIONAL Twofish with a 192-bit key 434 twofish128-cbc OPTIONAL Twofish with a 128-bit key 435 aes256-cbc OPTIONAL AES in CBC mode, 436 with a 256-bit key 437 aes192-cbc OPTIONAL AES with a 192-bit key 438 aes128-cbc RECOMMENDED AES with a 128-bit key 439 serpent256-cbc OPTIONAL Serpent in CBC mode, with 440 a 256-bit key 442 serpent192-cbc OPTIONAL Serpent with a 192-bit key 443 serpent128-cbc OPTIONAL Serpent with a 128-bit key 444 arcfour OPTIONAL the ARCFOUR stream cipher 445 with a 128-bit key 446 idea-cbc OPTIONAL IDEA in CBC mode 447 cast128-cbc OPTIONAL CAST-128 in CBC mode 448 none OPTIONAL no encryption; NOT RECOMMENDED 450 The "3des-cbc" cipher is three-key triple-DES 451 (encrypt-decrypt-encrypt), where the first 8 bytes of the key are 452 used for the first encryption, the next 8 bytes for the decryption, 453 and the following 8 bytes for the final encryption. This requires 24 454 bytes of key data (of which 168 bits are actually used). To 455 implement CBC mode, outer chaining MUST be used (i.e., there is only 456 one initialization vector). This is a block cipher with 8-byte 457 blocks. This algorithm is defined in [FIPS-46-3]. Note that since 458 this algorithm only has an effective key length of 112 bits 459 ([SCHNEIER]), it does not meet the specifications that SSH encryption 460 algorithms should use keys of 128 bits or more. However, this 461 algorithm is still REQUIRED for historical reasons; essentially, all 462 known implementations at the time of this writing support this 463 algorithm, and it is commonly used because it is the fundamental 464 interoperable algorithm. At some future time it is expected that 465 another algorithm, one with better strength, will become so prevalent 466 and ubiquitous that the use of "3des-cbc" will be deprecated by 467 another STANDARDS ACTION. 469 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128-bit keys 470 [SCHNEIER]. This is a block cipher with 8-byte blocks. 472 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 473 with 256-bit keys as described [TWOFISH]. This is a block cipher 474 with 16-byte blocks. 476 The "twofish192-cbc" cipher is the same as above but with a 192-bit 477 key. 479 The "twofish128-cbc" cipher is the same as above but with a 128-bit 480 key. 482 The "aes256-cbc" cipher is AES (Advanced Encryption Standard) 483 [FIPS-197], in CBC mode. This version uses a 256-bit key. 485 The "aes192-cbc" cipher is the same as above but with a 192-bit key. 487 The "aes128-cbc" cipher is the same as above but with a 128-bit key. 489 The "serpent256-cbc" cipher in CBC mode, with a 256-bit key as 490 described in the Serpent AES submission. 492 The "serpent192-cbc" cipher is the same as above but with a 192-bit 493 key. 495 The "serpent128-cbc" ciphera is the same as above but with a 128-bit 496 key. 498 The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. 499 The Arcfour cipher is believed to be compatible with the RC4 cipher 500 [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and 501 should be used with caution. 503 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 505 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 506 [RFC2144]. 508 The "none" algorithm specifies that no encryption is to be done. 509 Note that this method provides no confidentiality protection, and it 510 is NOT RECOMMENDED. Some functionality (e.g., password 511 authentication) may be disabled for security reasons if this cipher 512 is chosen. 514 Additional methods may be defined as specified in [SSH-ARCH] and in 515 [SSH-NUMBERS]. 517 6.4 Data Integrity 519 Data integrity is protected by including with each packet a MAC that 520 is computed from a shared secret, packet sequence number, and the 521 contents of the packet. 523 The message authentication algorithm and key are negotiated during 524 key exchange. Initially, no MAC will be in effect, and its length 525 MUST be zero. After key exchange, the 'mac' for the selected MAC 526 algorithm will be computed before encryption from the concatenation 527 of packet data: 529 mac = MAC(key, sequence_number || unencrypted_packet) 531 where 'unencrypted_packet' is the entire packet without 'mac' (the 532 length fields, 'payload' and 'random padding'), and 'sequence_number' 533 is an implicit packet sequence number represented as uint32. The 534 'sequence_number' is initialized to zero for the first packet, and is 535 incremented after every packet (regardless of whether encryption or 536 MAC is in use). It is never reset, even if keys/algorithms are 537 renegotiated later. It wraps around to zero after every 2^32 538 packets. The packet 'sequence_number' itself is not included in the 539 packet sent over the wire. 541 The MAC algorithms for each direction MUST run independently, and 542 implementations MUST allow choosing the algorithm independently for 543 both directions. 545 The value of 'mac' resulting from the MAC algorithm MUST be 546 transmitted without encryption as the last part of the packet. The 547 number of 'mac' bytes depends on the algorithm chosen. 549 The following MAC algorithms are currently defined: 551 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 552 length = 20) 553 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 554 length = 12, key length = 20) 555 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 556 length = 16) 557 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 558 length = 12, key length = 16) 559 none OPTIONAL no MAC; NOT RECOMMENDED 561 The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs 562 use only the first n bits of the resulting value. 564 SHA-1 is decribed in [FIPS-180-2] and MD5 is described in [RFC1321]. 566 Additional methods may be defined as specified in [SSH-ARCH] and in 567 [SSH-NUMBERS]. 569 6.5 Key Exchange Methods 571 The key exchange method specifies how one-time session keys are 572 generated for encryption and for authentication, and how the server 573 authentication is done. 575 Two REQUIRED key exchange methods have been defined: 577 diffie-hellman-group1-sha1 REQUIRED 578 diffie-hellman-group14-sha1 REQUIRED 580 These methods are described in Section 8. 582 Additional methods may be defined as specified in [SSH-NUMBERS]. The 583 name "diffie-hellman-group1-sha1" is used for a key exchange method 584 using an Oakley group as defined in [RFC2409]. SSH maintains its own 585 group identifier space which is logically distinct from Oakley 587 [RFC2412] and IKE; however, for one additional group, the Working 588 Group adopted the number assigned by [RFC3526], using 589 diffie-hellman-group14-sha1 for the name of the second defined group. 590 Implementations should treat these names as opaque identifiers and 591 should not assume any relationship between the groups used by SSH and 592 the groups defined for IKE. 594 6.6 Public Key Algorithms 596 This protocol has been designed to be able to operate with almost any 597 public key format, encoding, and algorithm (signature and/or 598 encryption). 600 There are several aspects that define a public key type: 601 o Key format: how is the key encoded and how are certificates 602 represented. The key blobs in this protocol MAY contain 603 certificates in addition to keys. 604 o Signature and/or encryption algorithms. Some key types may not 605 support both signing and encryption. Key usage may also be 606 restricted by policy statements - e.g., in certificates. In this 607 case, different key types SHOULD be defined for the different 608 policy alternatives. 609 o Encoding of signatures and/or encrypted data. This includes but 610 is not limited to padding, byte order, and data formats. 612 The following public key and/or certificate formats are currently 613 defined: 615 ssh-dss REQUIRED sign Raw DSS Key 616 ssh-rsa RECOMMENDED sign Raw RSA Key 617 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 618 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 620 Additional key types may be defined as specified in [SSH-ARCH] and in 621 [SSH-NUMBERS]. 623 The key type MUST always be explicitly known (from algorithm 624 negotiation or some other source). It is not normally included in 625 the key blob. 627 Certificates and public keys are encoded as follows: 628 string certificate or public key format identifier 629 byte[n] key/certificate data 631 The certificate part may have be a zero length string, but a public 632 key is required. This is the public key that will be used for 633 authentication. The certificate sequence contained in the 634 certificate blob can be used to provide authorization. 636 Public key / certificate formats that do not explicitly specify a 637 signature format identifier MUST use the public key / certificate 638 format identifier as the signature identifier. 640 Signatures are encoded as follows: 641 string signature format identifier (as specified by the 642 public key / cert format) 643 byte[n] signature blob in format specific encoding. 645 The "ssh-dss" key format has the following specific encoding: 647 string "ssh-dss" 648 mpint p 649 mpint q 650 mpint g 651 mpint y 653 Here the 'p', 'q', 'g', and 'y' parameters form the signature key blob. 655 Signing and verifying using this key format is done according to the 656 Digital Signature Standard [FIPS-186-2] using the SHA-1 hash 657 [FIPS-180-2]. 659 The resulting signature is encoded as follows: 661 string "ssh-dss" 662 string dss_signature_blob 664 The value for 'dss_signature_blob' is encoded as a string containing 665 r followed by s (which are 160-bit integers, without lengths or 666 padding, unsigned and in network byte order). 668 The "ssh-rsa" key format has the following specific encoding: 670 string "ssh-rsa" 671 mpint e 672 mpint n 674 Here the 'e' and 'n' parameters form the signature key blob. 676 Signing and verifying using this key format is performed according to 677 the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash. 679 The resulting signature is encoded as follows: 681 string "ssh-rsa" 682 string rsa_signature_blob 684 The value for 'rsa_signature_blob' is encoded as a string containing 685 s (which is an integer, without lengths or padding, unsigned and in 686 network byte order). 688 The "pgp-sign-rsa" method indicates the certificates, the public key, 689 and the signature are in OpenPGP compatible binary format 690 ([RFC2440]). This method indicates that the key is an RSA-key. 692 The "pgp-sign-dss". As above, but indicates that the key is a 693 DSS-key. 695 7. Key Exchange 697 Key exchange (kex) begins by each side sending name-lists of 698 supported algorithms. Each side has a preferred algorithm in each 699 category, and it is assumed that most implementations at any given 700 time will use the same preferred algorithm. Each side MAY guess 701 which algorithm the other side is using, and MAY send an initial key 702 exchange packet according to the algorithm if appropriate for the 703 preferred method. 705 The guess is considered wrong, if: 706 o the kex algorithm and/or the host key algorithm is guessed wrong 707 (server and client have different preferred algorithm), or 708 o if any of the other algorithms cannot be agreed upon (the 709 procedure is defined below in Section 7.1). 711 Otherwise, the guess is considered to be right and the optimistically 712 sent packet MUST be handled as the first key exchange packet. 714 However, if the guess was wrong, and a packet was optimistically sent 715 by one or both parties, such packets MUST be ignored (even if the 716 error in the guess would not affect the contents of the initial 717 packet(s)), and the appropriate side MUST send the correct initial 718 packet. 720 A key exchange method uses "explicit server authentication" if the 721 key exchange messages include a signature or other proof of the 722 server's authenticity. A key exchange method uses "implicit server 723 authentication" if, in order to prove its authenticity, the server 724 also has to prove that it knows the shared secret K, by sending a 725 message and a corresponding MAC which the client can verify. 727 The key exchange method defined by this document uses explicit server 728 authentication. However, key exchange methods with implicit server 729 authentication MAY be used with this protocol. After a key exchange 730 with implicit server authentication, the client MUST wait for a 731 response to its service request message before sending any further 732 data. 734 7.1 Algorithm Negotiation 736 Key exchange begins by each side sending the following packet: 738 byte SSH_MSG_KEXINIT 739 byte[16] cookie (random bytes) 740 name-list kex_algorithms 741 name-list server_host_key_algorithms 742 name-list encryption_algorithms_client_to_server 743 name-list encryption_algorithms_server_to_client 744 name-list mac_algorithms_client_to_server 745 name-list mac_algorithms_server_to_client 746 name-list compression_algorithms_client_to_server 747 name-list compression_algorithms_server_to_client 748 name-list languages_client_to_server 749 name-list languages_server_to_client 750 boolean first_kex_packet_follows 751 uint32 0 (reserved for future extension) 753 Each of the algorithm name-lists MUST be a comma-separated list of 754 algorithm names - see Algorithm Naming in [SSH-ARCH] and additional 755 information in [SSH-NUMBERS]. Each supported (allowed) algorithm 756 MUST be listed in order of preference, from most to least. 758 The first algorithm in each name-list MUST be the preferred (guessed) 759 algorithm. Each name-list MUST contain at least one algorithm name. 761 cookie 762 The 'cookie' MUST be a random value generated by the sender. 763 Its purpose is to make it impossible for either side to fully 764 determine the keys and the session identifier. 766 kex_algorithms 767 Key exchange algorithms were defined above. The first 768 algorithm MUST be the preferred (and guessed) algorithm. If 769 both sides make the same guess, that algorithm MUST be used. 770 Otherwise, the following algorithm MUST be used to choose a key 771 exchange method: Iterate over client's kex algorithms, one at a 772 time. Choose the first algorithm that satisfies the following 773 conditions: 774 + the server also supports the algorithm, 775 + if the algorithm requires an encryption-capable host key, 776 there is an encryption-capable algorithm on the server's 777 server_host_key_algorithms that is also supported by the 778 client, and 780 + if the algorithm requires a signature-capable host key, 781 there is a signature-capable algorithm on the server's 782 server_host_key_algorithms that is also supported by the 783 client. 784 If no algorithm satisfying all these conditions can be found, 785 the connection fails, and both sides MUST disconnect. 787 server_host_key_algorithms 788 A name-list of the algorithms supported for the server host 789 key. The server lists the algorithms for which it has host 790 keys; the client lists the algorithms that it is willing to 791 accept. (There MAY be multiple host keys for a host, possibly 792 with different algorithms.) 794 Some host keys may not support both signatures and encryption 795 (this can be determined from the algorithm), and thus not all 796 host keys are valid for all key exchange methods. 798 Algorithm selection depends on whether the chosen key exchange 799 algorithm requires a signature or encryption capable host key. 800 It MUST be possible to determine this from the public key 801 algorithm name. The first algorithm on the client's name-list 802 that satisfies the requirements and is also supported by the 803 server MUST be chosen. If there is no such algorithm, both 804 sides MUST disconnect. 806 encryption_algorithms 807 A name-list of acceptable symmetric encryption algorithms (also 808 known as ciphers) in order of preference. The chosen 809 encryption algorithm to each direction MUST be the first 810 algorithm on the client's name-list that is also on the 811 server's name-list. If there is no such algorithm, both sides 812 MUST disconnect. 814 Note that "none" must be explicitly listed if it is to be 815 acceptable. The defined algorithm names are listed in 816 Section 6.3. 818 mac_algorithms 819 A name-list of acceptable MAC algorithms in order of 820 preference. The chosen MAC algorithm MUST be the first 821 algorithm on the client's name-list that is also on the 822 server's name-list. If there is no such algorithm, both sides 823 MUST disconnect. 825 Note that "none" must be explicitly listed if it is to be 826 acceptable. The MAC algorithm names are listed in Section 6.4. 828 compression_algorithms 829 A name-list of acceptable compression algorithms in order of 830 preference. The chosen compression algorithm MUST be the first 831 algorithm on the client's name-list that is also on the 832 server's name-list. If there is no such algorithm, both sides 833 MUST disconnect. 835 Note that "none" must be explicitly listed if it is to be 836 acceptable. The compression algorithm names are listed in 837 Section 6.2. 839 languages 840 This is a name-list of language tags in order of preference 841 [RFC3066]. Both parties MAY ignore this name-list. If there 842 are no language preferences, this name-list SHOULD be empty as 843 defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT 844 be present unless they are known to be needed by the sending 845 party. 847 first_kex_packet_follows 848 Indicates whether a guessed key exchange packet follows. If a 849 guessed packet will be sent, this MUST be TRUE. If no guessed 850 packet will be sent, this MUST be FALSE. 852 After receiving the SSH_MSG_KEXINIT packet from the other side, 853 each party will know whether their guess was right. If the 854 other party's guess was wrong, and this field was TRUE, the 855 next packet MUST be silently ignored, and both sides MUST then 856 act as determined by the negotiated key exchange method. If 857 the guess was right, key exchange MUST continue using the 858 guessed packet. 860 After the KEXINIT packet exchange, the key exchange algorithm is run. 861 It may involve several packet exchanges, as specified by the key 862 exchange method. 864 Once a party has sent a KEXINIT message for key exchange or 865 re-exchange, until is has sent a NEWKEYS message (Section 7.3), it 866 MUST NOT send any messages other than: 867 o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST 868 and SERVICE_ACCEPT MUST NOT be sent); 869 o Algorithm negotiation messages (20 to 29) (but further KEXINITs 870 MUST NOT be sent); 871 o Specific key exchange method messages (30 to 49). 873 The provisions of Section 11 apply to unrecognized messages. 875 Note however that during a key re-exchange, after sending a KEXINIT 876 message, each party MUST be prepared to process an arbitrary number 877 of messages that may be in-flight before receiving a KEXINIT from the 878 other party. 880 7.2 Output from Key Exchange 882 The key exchange produces two values: a shared secret K, and an 883 exchange hash H. Encryption and authentication keys are derived from 884 these. The exchange hash H from the first key exchange is 885 additionally used as the session identifier, which is a unique 886 identifier for this connection. It is used by authentication methods 887 as a part of the data that is signed as a proof of possession of a 888 private key. Once computed, the session identifier is not changed, 889 even if keys are later re-exchanged. 891 Each key exchange method specifies a hash function that is used in 892 the key exchange. The same hash algorithm MUST be used in key 893 derivation. Here, we'll call it HASH. 895 Encryption keys MUST be computed as HASH of a known value and K as 896 follows: 897 o Initial IV client to server: HASH(K || H || "A" || session_id) 898 (Here K is encoded as mpint and "A" as byte and session_id as raw 899 data. "A" means the single character A, ASCII 65). 900 o Initial IV server to client: HASH(K || H || "B" || session_id) 901 o Encryption key client to server: HASH(K || H || "C" || session_id) 902 o Encryption key server to client: HASH(K || H || "D" || session_id) 903 o Integrity key client to server: HASH(K || H || "E" || session_id) 904 o Integrity key server to client: HASH(K || H || "F" || session_id) 906 Key data MUST be taken from the beginning of the hash output. As 907 many bytes as are needed are taken from the beginning of the hash 908 value. If the key length needed is longer than the output of the 909 HASH, the key is extended by computing HASH of the concatenation of K 910 and H and the entire key so far, and appending the resulting bytes 911 (as many as HASH generates) to the key. This process is repeated 912 until enough key material is available; the key is taken from the 913 beginning of this value. In other words: 915 K1 = HASH(K || H || X || session_id) (X is e.g., "A") 916 K2 = HASH(K || H || K1) 917 K3 = HASH(K || H || K1 || K2) 918 ... 919 key = K1 || K2 || K3 || ... 921 This process will lose entropy if the amount of entropy in K is 922 larger than the internal state size of HASH. 924 7.3 Taking Keys Into Use 926 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 927 This message is sent with the old keys and algorithms. All messages 928 sent after this message MUST use the new keys and algorithms. 930 When this message is received, the new keys and algorithms MUST be 931 taken into use for receiving. 933 The purpose of this message is to ensure that a party is able to 934 respond with a SSH_MSG_DISCONNECT message that the other party can 935 understand if something goes wrong with the key exchange. 937 byte SSH_MSG_NEWKEYS 939 8. Diffie-Hellman Key Exchange 941 The Diffie-Hellman (DH) key exchange provides a shared secret that 942 can not be determined by either party alone. The key exchange is 943 combined with a signature with the host key to provide host 944 authentication. This key exchange method provides explicit server 945 authentication as is defined in Section 7. 947 In the following description (C is the client, S is the server; p is 948 a large safe prime, g is a generator for a subgroup of GF(p), and q 949 is the order of the subgroup; V_S is S's version string; V_C is C's 950 version string; K_S is S's public host key; I_C is C's KEXINIT 951 message and I_S S's KEXINIT message which have been exchanged before 952 this part begins): 954 1. C generates a random number x (1 < x < q) and computes e = g^x 955 mod p. C sends "e" to S. 956 2. S generates a random number y (0 < y < q) and computes f = g^y 957 mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C 958 || V_S || I_C || I_S || K_S || e || f || K) (these elements are 959 encoded according to their types; see below), and signature s on 960 H with its private host key. S sends "K_S || f || s" to C. The 961 signing operation may involve a second hashing operation. 962 3. C verifies that K_S really is the host key for S (e.g., using 963 certificates or a local database). C is also allowed to accept 964 the key without verification; however, doing so will render the 965 protocol insecure against active attacks (but may be desirable 966 for practical reasons in the short term in many environments). C 967 then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || 968 K_S || e || f || K), and verifies the signature s on H. 970 Either side MUST NOT send or accept e or f values that are not in the 971 range [1, p-1]. If this condition is violated, the key exchange 972 fails. 974 This is implemented with the following messages. The hash algorithm 975 for computing the exchange hash is defined by the method name, and is 976 called HASH. The public key algorithm for signing is negotiated with 977 the KEXINIT messages. 979 First, the client sends the following: 981 byte SSH_MSG_KEXDH_INIT 982 mpint e 984 The server responds with the following: 986 byte SSH_MSG_KEXDH_REPLY 987 string server public host key and certificates (K_S) 988 mpint f 989 string signature of H 991 The hash H is computed as the HASH hash of the concatenation of the 992 following: 994 string V_C, the client's version string (CR and NL excluded) 995 string V_S, the server's version string (CR and NL excluded) 996 string I_C, the payload of the client's SSH_MSG_KEXINIT 997 string I_S, the payload of the server's SSH_MSG_KEXINIT 998 string K_S, the host key 999 mpint e, exchange value sent by the client 1000 mpint f, exchange value sent by the server 1001 mpint K, the shared secret 1003 This value is called the exchange hash, and it is used to 1004 authenticate the key exchange. The exchange hash SHOULD be kept 1005 secret. 1007 The signature algorithm MUST be applied over H, not the original 1008 data. Most signature algorithms include hashing and additional 1009 padding - for example, "ssh-dss" specifies SHA-1 hashing. In that 1010 case, the data is first hashed with HASH to compute H, and H is then 1011 hashed with SHA-1 as part of the signing operation. 1013 8.1 diffie-hellman-group1-sha1 1015 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 1016 exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024-bit 1017 MODP Group). This method MUST be supported for interoperability as 1018 all of the known implementations currently support it. Note that 1019 this method is named using the phrase "group1" even though it 1020 specifies the use of Oakley Group 2. 1022 8.2 diffie-hellman-group14-sha1 1024 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key 1025 exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048-bit 1026 MODP Group), and it MUST also be supported. 1028 9. Key Re-Exchange 1030 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when 1031 not already doing a key exchange (as described in Section 7.1). When 1032 this message is received, a party MUST respond with its own 1033 SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT 1034 already was a reply. Either party MAY initiate the re-exchange, but 1035 roles MUST NOT be changed (i.e., the server remains the server, and 1036 the client remains the client). 1038 Key re-exchange is performed using whatever encryption was in effect 1039 when the exchange was started. Encryption, compression, and MAC 1040 methods are not changed before a new SSH_MSG_NEWKEYS is sent after 1041 the key exchange (as in the initial key exchange). Re-exchange is 1042 processed identically to the initial key exchange, except for the 1043 session identifier that will remain unchanged. It is permissible to 1044 change some or all of the algorithms during the re-exchange. Host 1045 keys can also change. All keys and initialization vectors are 1046 recomputed after the exchange. Compression and encryption contexts 1047 are reset. 1049 It is RECOMMENDED that the keys are changed after each gigabyte of 1050 transmitted data or after each hour of connection time, whichever 1051 comes sooner. However, since the re-exchange is a public key 1052 operation, it requires a fair amount of processing power and should 1053 not be performed too often. 1055 More application data may be sent after the SSH_MSG_NEWKEYS packet 1056 has been sent; key exchange does not affect the protocols that lie 1057 above the SSH transport layer. 1059 10. Service Request 1061 After the key exchange, the client requests a service. The service 1062 is identified by a name. The format of names and procedures for 1063 defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS]. 1065 Currently, the following names have been reserved: 1067 ssh-userauth 1068 ssh-connection 1070 Similar local naming policy is applied to the service names, as is 1071 applied to the algorithm names. A local service should use the 1072 PRIVATE USE syntax of "servicename@domain". 1074 byte SSH_MSG_SERVICE_REQUEST 1075 string service name 1077 If the server rejects the service request, it SHOULD send an 1078 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 1080 When the service starts, it may have access to the session identifier 1081 generated during the key exchange. 1083 If the server supports the service (and permits the client to use 1084 it), it MUST respond with the following: 1086 byte SSH_MSG_SERVICE_ACCEPT 1087 string service name 1089 Message numbers used by services should be in the area reserved for 1090 them (see [SSH-ARCH]) and [SSH-NUMBERS]. The transport level will 1091 continue to process its own messages. 1093 Note that after a key exchange with implicit server authentication, 1094 the client MUST wait for response to its service request message 1095 before sending any further data. 1097 11. Additional Messages 1099 Either party may send any of the following messages at any time. 1101 11.1 Disconnection Message 1102 byte SSH_MSG_DISCONNECT 1103 uint32 reason code 1104 string description [RFC3629] 1105 string language tag [RFC3066] 1107 This message causes immediate termination of the connection. All 1108 implementations MUST be able to process this message; they SHOULD be 1109 able to send this message. 1111 The sender MUST NOT send or receive any data after this message, and 1112 the recipient MUST NOT accept any data after receiving this message. 1113 The Disconnection Message 'description' string gives a more specific 1114 explanation in a human-readable form. The Disconnection Message 1115 'reason code' gives the reason in a more machine-readable format 1116 (suitable for localization), and can have the values as displayed in 1117 the table below. Note that the decimal representation is displayed 1118 in this table for readability but that the values are actually uint32 1119 values. 1121 Symbolic name reason code 1122 ------------- ----------- 1123 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 1124 SSH_DISCONNECT_PROTOCOL_ERROR 2 1125 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 1126 SSH_DISCONNECT_RESERVED 4 1127 SSH_DISCONNECT_MAC_ERROR 5 1128 SSH_DISCONNECT_COMPRESSION_ERROR 6 1129 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1130 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1131 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1132 SSH_DISCONNECT_CONNECTION_LOST 10 1133 SSH_DISCONNECT_BY_APPLICATION 11 1134 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1135 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1136 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1137 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1139 If the 'description' string is displayed, control character filtering 1140 discussed in [SSH-ARCH] should be used to avoid attacks by sending 1141 terminal control characters. 1143 Requests for assignments of new Disconnection Message 'reason code' 1144 values (and associated 'description' text) in the range of 0x00000010 1145 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 1146 described in [RFC2434]. The Disconnection Message 'reason code' 1147 values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for 1148 PRIVATE USE. As is noted, the actual instructions to the IANA are in 1149 [SSH-NUMBERS]. 1151 11.2 Ignored Data Message 1152 byte SSH_MSG_IGNORE 1153 string data 1155 All implementations MUST understand (and ignore) this message at any 1156 time (after receiving the protocol version). No implementation is 1157 required to send them. This message can be used as an additional 1158 protection measure against advanced traffic analysis techniques. 1160 11.3 Debug Message 1161 byte SSH_MSG_DEBUG 1162 boolean always_display 1163 string message [RFC3629] 1164 string language tag [RFC3066] 1166 All implementations MUST understand this message, but they are 1167 allowed to ignore it. This message is used to transmit information 1168 that may help debugging. If always_display is TRUE, the message 1169 SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 1170 debugging information has been explicitly requested by the user. 1172 The 'message' doesn't need to contain a newline. It is, however, 1173 allowed to consist of multiple lines separated by CRLF (Carriage 1174 Return - Line Feed) pairs. 1176 If the 'message' string is displayed, terminal control character 1177 filtering discussed in [SSH-ARCH] should be used to avoid attacks by 1178 sending terminal control characters. 1180 11.4 Reserved Messages 1182 An implementation MUST respond to all unrecognized messages with an 1183 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1184 received. Such messages MUST be otherwise ignored. Later protocol 1185 versions may define other meanings for these message types. 1186 byte SSH_MSG_UNIMPLEMENTED 1187 uint32 packet sequence number of rejected message 1189 12. Summary of Message Numbers 1191 The following is a summary of messages and their associated message 1192 number. 1194 SSH_MSG_DISCONNECT 1 1195 SSH_MSG_IGNORE 2 1196 SSH_MSG_UNIMPLEMENTED 3 1197 SSH_MSG_DEBUG 4 1198 SSH_MSG_SERVICE_REQUEST 5 1199 SSH_MSG_SERVICE_ACCEPT 6 1200 SSH_MSG_KEXINIT 20 1201 SSH_MSG_NEWKEYS 21 1202 SSH_MSG_KEXDH_INIT 30 1203 SSH_MSG_KEXDH_REPLY 31 1205 Note that numbers 30-49 are used for kex packets. Different kex 1206 methods may reuse message numbers in this range. 1208 13. IANA Considerations 1210 This document is part of a set. The IANA considerations for the SSH 1211 protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and 1212 this document, are detailed in [SSH-NUMBERS]. 1214 14. Security Considerations 1216 This protocol provides a secure encrypted channel over an insecure 1217 network. It performs server host authentication, key exchange, 1218 encryption, and integrity protection. It also derives a unique 1219 session id that may be used by higher-level protocols. 1221 Full security considerations for this protocol are provided in 1222 [SSH-ARCH]. 1224 15. References 1226 15.1 Normative 1228 [SSH-ARCH] 1229 Lonvick, C., "SSH Protocol Architecture", 1230 I-D draft-ietf-secsh-architecture-22.txt, March 2005. 1232 [SSH-USERAUTH] 1233 Lonvick, C., "SSH Authentication Protocol", 1234 I-D draft-ietf-secsh-userauth-27.txt, March 2005. 1236 [SSH-CONNECT] 1237 Lonvick, C., "SSH Connection Protocol", 1238 I-D draft-ietf-secsh-connect-25.txt, March 2005. 1240 [SSH-NUMBERS] 1241 Lonvick, C., "SSH Protocol Assigned Numbers", 1242 I-D draft-ietf-secsh-assignednumbers-12.txt, March 2005. 1244 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1245 April 1992. 1247 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1248 Specification version 3.3", RFC 1950, May 1996. 1250 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1251 version 1.3", RFC 1951, May 1996. 1253 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1254 Keyed-Hashing for Message Authentication", RFC 2104, 1255 February 1997. 1257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1267 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1268 October 1998. 1270 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1271 "OpenPGP Message Format", RFC 2440, November 1998. 1273 [RFC3066] Alvestrand, H., "Tags for the Identification of 1274 Languages", BCP 47, RFC 3066, January 2001. 1276 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1277 Standards (PKCS) #1: RSA Cryptography Specifications 1278 Version 2.1", RFC 3447, February 2003. 1280 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1281 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1282 RFC 3526, May 2003. 1284 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1285 10646", STD 63, RFC 3629, November 2003. 1287 [FIPS-180-2] 1288 National Institute of Standards and Technology, "Secure 1289 Hash Standard (SHS)", Federal Information Processing 1290 Standards Publication 180-2, August 2002. 1292 [FIPS-186-2] 1293 National Institute of Standards and Technology, "Digital 1294 Signature Standard (DSS)", Federal Information Processing 1295 Standards Publication 186-2, January 2000. 1297 [FIPS-197] 1298 National Institute of Standards and Technology, "Advanced 1299 Encryption Standard (AES)", Federal Information Processing 1300 Standards Publication 197, November 2001. 1302 [FIPS-46-3] 1303 National Institute of Standards and Technology, "Data 1304 Encryption Standard (DES)", Federal Information Processing 1305 Standards Publication 46-3, October 1999. 1307 [SCHNEIER] 1308 Schneier, B., "Applied Cryptography Second Edition: 1309 protocols algorithms and source in code in C", 1996. 1311 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1312 128-Bit Block Cipher, 1st Edition", March 1999. 1314 15.2 Informative 1316 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 1317 over Ethernet networks", STD 41, RFC 894, April 1984. 1319 [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for 1320 multi-protocol transmission of datagrams over 1321 Point-to-Point links", RFC 1134, November 1989. 1323 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1324 RFC 2412, November 1998. 1326 [ssh-1.2.30] 1327 Ylonen, T., "ssh-1.2.30/RFC", File within compressed 1328 tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/ 1329 ssh-1.2.30.tar.gz, November 1995. 1331 Authors' Addresses 1333 Tatu Ylonen 1334 SSH Communications Security Corp 1335 Fredrikinkatu 42 1336 HELSINKI FIN-00100 1337 Finland 1339 Email: ylo@ssh.com 1340 Chris Lonvick (editor) 1341 Cisco Systems, Inc. 1342 12515 Research Blvd. 1343 Austin 78759 1344 USA 1346 Email: clonvick@cisco.com 1348 Appendix A. Trademark Notice 1350 "ssh" is a registered trademark in the United States and/or other 1351 countries. 1353 Note to the RFC Editor: This should be a separate section like the 1354 subsequent ones, and not an appendix. This paragraph to be removed 1355 before publication. 1357 Intellectual Property Statement 1359 The IETF takes no position regarding the validity or scope of any 1360 Intellectual Property Rights or other rights that might be claimed to 1361 pertain to the implementation or use of the technology described in 1362 this document or the extent to which any license under such rights 1363 might or might not be available; nor does it represent that it has 1364 made any independent effort to identify any such rights. Information 1365 on the procedures with respect to rights in RFC documents can be 1366 found in BCP 78 and BCP 79. 1368 Copies of IPR disclosures made to the IETF Secretariat and any 1369 assurances of licenses to be made available, or the result of an 1370 attempt made to obtain a general license or permission for the use of 1371 such proprietary rights by implementers or users of this 1372 specification can be obtained from the IETF on-line IPR repository at 1373 http://www.ietf.org/ipr. 1375 The IETF invites any interested party to bring to its attention any 1376 copyrights, patents or patent applications, or other proprietary 1377 rights that may cover technology that may be required to implement 1378 this standard. Please address the information to the IETF at 1379 ietf-ipr@ietf.org. 1381 The IETF has been notified of intellectual property rights claimed in 1382 regard to some or all of the specification contained in this 1383 document. For more information consult the online list of claimed 1384 rights. 1386 Disclaimer of Validity 1388 This document and the information contained herein are provided on an 1389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1391 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1392 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1393 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1396 Copyright Statement 1398 Copyright (C) The Internet Society (2005). This document is subject 1399 to the rights, licenses and restrictions contained in BCP 78, and 1400 except as set forth therein, the authors retain all their rights. 1402 Acknowledgment 1404 Funding for the RFC Editor function is currently provided by the 1405 Internet Society.