idnits 2.17.1 draft-ietf-secsh-transport-23.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 1370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1355. ** 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 158 has weird spacing: '... string dat...' == Line 619 has weird spacing: '... string cer...' == Line 632 has weird spacing: '... string sig...' == Line 652 has weird spacing: '... string dss...' == Line 672 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 (February 17, 2005) is 7000 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 729 == Unused Reference: 'RFC2693' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'RFC3280' is defined on line 1270, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-21 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-26 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-24 == Outdated reference: A later version (-12) exists of draft-ietf-secsh-assignednumbers-11 ** 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) ** Downref: Normative reference to an Experimental RFC: RFC 2693 ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-197' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH' -- Obsolete informational reference (is this intentional?): RFC 1134 (Obsoleted by RFC 1171) Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 14 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: August 21, 2005 February 17, 2005 6 SSH Transport Layer Protocol 7 draft-ietf-secsh-transport-23.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 August 21, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions Used in This Document . . . . . . . . . . . . . 4 64 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . 5 66 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . 5 67 5. Compatibility With Old SSH Versions . . . . . . . . . . . . 6 68 5.1 Old Client, New Server . . . . . . . . . . . . . . . . . . 7 69 5.2 New Client, Old Server . . . . . . . . . . . . . . . . . . 7 70 5.3 Packet Size and Overhead . . . . . . . . . . . . . . . . . 7 71 6. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 8 72 6.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . 9 73 6.2 Compression . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . 12 76 6.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . 13 77 6.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . 14 78 7. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 16 79 7.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . 16 80 7.2 Output from Key Exchange . . . . . . . . . . . . . . . . . 19 81 7.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . 20 82 8. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 21 83 8.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . 22 84 8.2 diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 23 85 9. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 23 86 10. Service Request . . . . . . . . . . . . . . . . . . . . . . 23 87 11. Additional Messages . . . . . . . . . . . . . . . . . . . . 24 88 11.1 Disconnection Message . . . . . . . . . . . . . . . . . 24 89 11.2 Ignored Data Message . . . . . . . . . . . . . . . . . . 26 90 11.3 Debug Message . . . . . . . . . . . . . . . . . . . . . 26 91 11.4 Reserved Messages . . . . . . . . . . . . . . . . . . . 26 92 12. Summary of Message Numbers . . . . . . . . . . . . . . . . . 26 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 94 14. Security Considerations . . . . . . . . . . . . . . . . . . 27 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 15.1 Normative . . . . . . . . . . . . . . . . . . . . . . . 27 97 15.2 Informative . . . . . . . . . . . . . . . . . . . . . . 29 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . 29 99 Intellectual Property and Copyright Statements . . . . . . . 30 101 1. Contributors 103 The major original contributors of this set of documents have been: 104 Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 105 Communications Security Corp), and Markku-Juhani O. Saarinen 106 (University of Jyvaskyla). Darren Moffit was the original editor of 107 this set of documents and also made very substantial contributions. 109 Additional contributors to this document include [need list]. 110 Listing their names here does not mean that they endorse this 111 document, but that they have contributed to it. 113 Comments on this internet draft should be sent to the IETF SECSH 114 working group, details at: 115 http://ietf.org/html.charters/secsh-charter.html Note: This paragraph 116 will be removed before this document progresses to become an RFC. 118 2. Introduction 120 The SSH transport layer is a secure low level transport protocol. It 121 provides strong encryption, cryptographic host authentication, and 122 integrity protection. 124 Authentication in this protocol level is host-based; this protocol 125 does not perform user authentication. A higher level protocol for 126 user authentication can be designed on top of this protocol. 128 The protocol has been designed to be simple, flexible, to allow 129 parameter negotiation, and to minimize the number of round-trips. 130 Key exchange method, public key algorithm, symmetric encryption 131 algorithm, message authentication algorithm, and hash algorithm are 132 all negotiated. It is expected that in most environments, only 2 133 round-trips will be needed for full key exchange, server 134 authentication, service request, and acceptance notification of 135 service request. The worst case is 3 round-trips. 137 3. Conventions Used in This Document 139 All documents related to the SSH protocols shall use the keywords 140 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 141 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 142 requirements. These keywords are to be interpreted as described in 143 [RFC2119]. 145 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 146 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 147 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 148 this document when used to describe namespace allocation are to be 149 interpreted as described in [RFC2434]. 151 Protocol fields and possible values to fill them are defined in this 152 set of documents. Protocol fields will be defined in the message 153 definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as 154 follows. 156 byte SSH_MSG_CHANNEL_DATA 157 uint32 recipient channel 158 string data 160 Throughout these documents, when the fields are referenced, they will 161 appear within single quotes. When values to fill those fields are 162 referenced, they will appear within double quotes. Using the above 163 example, possible values for 'data' are "foo" and "bar". 165 4. Connection Setup 167 SSH works over any 8-bit clean, binary-transparent transport. The 168 underlying transport SHOULD protect against transmission errors as 169 such errors cause the SSH connection to terminate. 171 The client initiates the connection. 173 4.1 Use over TCP/IP 175 When used over TCP/IP, the server normally listens for connections on 176 port 22. This port number has been registered with the IANA, and has 177 been officially assigned for SSH. 179 4.2 Protocol Version Exchange 181 When the connection has been established, both sides MUST send an 182 identification string. This identification string MUST be 184 SSH-protoversion-softwareversion SP comments CR LF 186 Since the protocol being defined in this set of documents is version 187 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is 188 OPTIONAL. If the 'comments' string is included, a 'space' character 189 (denoted above as SP, ASCII 32) MUST separate the 'softwareversion' 190 and 'comments' strings. The identification MUST be terminated by a 191 single Carriage Return and a single Line Feed character (ASCII 13 and 192 10, respectively). Implementors who wish to maintain compatibility 193 with older, undocumented versions of this protocol, may want to 194 process the identification string without expecting the presence of 195 the carriage return character for reasons described in Section 5 of 196 this document. The null character MUST NOT be sent. The maximum 197 length of the string is 255 characters, including the Carriage Return 198 and Line Feed. 200 The part of the identification string preceding Carriage Return and 201 Line Feed is used in the Diffie-Hellman key exchange (see 202 Section 8). 204 The server MAY send other lines of data before sending the version 205 string. Each line SHOULD be terminated by a Carriage Return and Line 206 Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 207 in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients 208 MUST be able to process such lines. They MAY be silently ignored, or 209 MAY be displayed to the client user. If they are displayed, control 210 character filtering discussed in [SSH-ARCH] SHOULD be used. The 211 primary use of this feature is to allow TCP-wrappers to display an 212 error message before disconnecting. 214 Both the 'protoversion' and 'softwareversion' strings MUST consist of 215 printable US-ASCII characters with the exception of whitespace 216 characters and the minus sign (-). The 'softwareversion' string is 217 primarily used to trigger compatibility extensions and to indicate 218 the capabilities of an implementation. The 'comments' string SHOULD 219 contain additional information that might be useful in solving user 220 problems. As such, an example of a valid identification string is 222 SSH-2.0-billsSSH_3.6.3q3 224 This identification string does not contain the optional 'comments' 225 string and is thusly terminated by a CR and LF immediately after the 226 'softwareversion' string. 228 Key exchange will begin immediately after sending this identifier. 229 All packets following the identification string SHALL use the binary 230 packet protocol which is described in Section 6. 232 5. Compatibility With Old SSH Versions 234 As stated earlier, the 'protoversion' specified for this protocol is 235 "2.0". Earlier versions of this protocol have not been formally 236 documented but it is widely known that they use 'protoversion' of 237 "1.x" (e.g., "1.5" or "1.3"). At the time of this writing, many 238 implementations of SSH are utilizing protocol version 2.0 but it is 239 known that there are still devices using the previous versions. 240 During the transition period, it is important to be able to work in a 241 way that is compatible with the installed SSH clients and servers 242 that use the older version of the protocol. Information in this 243 section is only relevant for implementations supporting compatibility 244 with SSH versions 1.x. For those interested, the only known 245 documentation of the 1.x protocol is contained in README files that 246 are shipped along with the source code. [ssh-1.2.30] 248 5.1 Old Client, New Server 250 Server implementations MAY support a configurable "compatibility" 251 flag that enables compatibility with old versions. When this flag is 252 on, the server SHOULD identify its protocol version as "1.99". 253 Clients using protocol 2.0 MUST be able to identify this as identical 254 to "2.0". In this mode the server SHOULD NOT send the carriage 255 return character (ASCII 13) after the version identification string. 257 In the compatibility mode the server SHOULD NOT send any further data 258 after its initialization string until it has received an 259 identification string from the client. The server can then determine 260 whether the client is using an old protocol, and can revert to the 261 old protocol if required. In the compatibility mode, the server MUST 262 NOT send additional data before the version string. 264 When compatibility with old clients is not needed, the server MAY 265 send its initial key exchange data immediately after the 266 identification string. 268 5.2 New Client, Old Server 270 Since the new client MAY immediately send additional data after its 271 identification string (before receiving server's identification), the 272 old protocol may already have been corrupted when the client learns 273 that the server is old. When this happens, the client SHOULD close 274 the connection to the server, and reconnect using the old protocol. 276 5.3 Packet Size and Overhead 278 Some readers will worry about the increase in packet size due to new 279 headers, padding, and Message Authentication Code (MAC). The minimum 280 packet size is in the order of 28 bytes (depending on negotiated 281 algorithms). The increase is negligible for large packets, but very 282 significant for one-byte packets (telnet-type sessions). There are, 283 however, several factors that make this a non-issue in almost all 284 cases: 285 o The minimum size of a TCP/IP header is 32 bytes. Thus, the 286 increase is actually from 33 to 51 bytes (roughly). 287 o The minimum size of the data field of an Ethernet packet is 46 288 bytes [RFC0894]. Thus, the increase is no more than 5 bytes. 289 When Ethernet headers are considered, the increase is less than 10 290 percent. 291 o The total fraction of telnet-type data in the Internet is 292 negligible, even with increased packet sizes. 294 The only environment where the packet size increase is likely to have 295 a significant effect is PPP [RFC1134] over slow modem lines (PPP 296 compresses the TCP/IP headers, emphasizing the increase in packet 297 size). However, with modern modems, the time needed to transfer is 298 in the order of 2 milliseconds, which is a lot faster than people can 299 type. 301 There are also issues related to the maximum packet size. To 302 minimize delays in screen updates, one does not want excessively 303 large packets for interactive sessions. The maximum packet size is 304 negotiated separately for each channel. 306 6. Binary Packet Protocol 308 Each packet is in the following format: 310 uint32 packet_length 311 byte padding_length 312 byte[n1] payload; n1 = packet_length - padding_length - 1 313 byte[n2] random padding; n2 = padding_length 314 byte[m] mac (Message Authentication Code - MAC); m = mac_length 316 packet_length 317 The length of the packet in bytes, not including 'mac' or the 318 'packet_length' field itself. 320 padding_length 321 Length of 'random padding' (bytes). 323 payload 324 The useful contents of the packet. If compression has been 325 negotiated, this field is compressed. Initially, compression 326 MUST be "none". 328 random padding 329 Arbitrary-length padding, such that the total length of 330 (packet_length || padding_length || payload || random padding) 331 is a multiple of the cipher block size or 8, whichever is 332 larger. There MUST be at least four bytes of padding. The 333 padding SHOULD consist of random bytes. The maximum amount of 334 padding is 255 bytes. 336 mac 337 Message Authentication Code. If message authentication has 338 been negotiated, this field contains the MAC bytes. Initially, 339 the MAC algorithm MUST be "none". 341 Note that the length of the concatenation of 'packet_length', 342 'padding_length', 'payload', and 'random padding' MUST be a multiple 343 of the cipher block size or 8, whichever is larger. This constraint 344 MUST be enforced even when using stream ciphers. Note that the 345 'packet_length' field is also encrypted, and processing it requires 346 special care when sending or receiving packets. Also note that the 347 insertion of variable amounts of 'random padding' may help thwart 348 traffic analysis. 350 The minimum size of a packet is 16 (or the cipher block size, 351 whichever is larger) bytes (plus 'mac'). Implementations SHOULD 352 decrypt the length after receiving the first 8 (or cipher block size, 353 whichever is larger) bytes of a packet. 355 6.1 Maximum Packet Length 357 All implementations MUST be able to process packets with uncompressed 358 payload length of 32768 bytes or less and total packet size of 35000 359 bytes or less (including 'packet_length', 'padding_length', 360 'payload', 'random padding', and 'mac'). The maximum of 35000 bytes 361 is an arbitrarily chosen value larger than uncompressed size. 362 Implementations SHOULD support longer packets, where they might be 363 needed. For example: if an implementation wants to send a very large 364 number of certificates, the larger packets MAY be sent if the version 365 string indicates that the other party is able to process them. 366 However, implementations SHOULD check that the packet length is 367 reasonable for the implementation to avoid denial of service and/or 368 buffer overflow attacks. 370 6.2 Compression 372 If compression has been negotiated, the 'payload' field (and only it) 373 will be compressed using the negotiated algorithm. The 374 'packet_length' field and 'mac' will be computed from the compressed 375 payload. Encryption will be done after compression. 377 Compression MAY be stateful, depending on the method. Compression 378 MUST be independent for each direction, and implementations MUST 379 allow independently choosing the algorithm for each direction. In 380 practice however, it is RECOMMENDED that the compression method be 381 the same in both directions. 383 The following compression methods are currently defined: 385 none REQUIRED no compression 386 zlib OPTIONAL ZLIB (LZ77) compression 388 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 390 The compression context is initialized after each key exchange, and 391 is passed from one packet to the next with only a partial flush being 392 performed at the end of each packet. A partial flush means that the 393 current compressed block is ended and all data will be output. If 394 the current block is not a stored block, one or more empty blocks are 395 added after the current block to ensure that there are at least 8 396 bits counting from the start of the end-of-block code of the current 397 block to the end of the packet payload. 399 Additional methods may be defined as specified in [SSH-ARCH] and 400 [SSH-NUMBERS]. 402 6.3 Encryption 404 An encryption algorithm and a key will be negotiated during the key 405 exchange. When encryption is in effect, the packet length, padding 406 length, payload and padding fields of each packet MUST be encrypted 407 with the given algorithm. 409 The encrypted data in all packets sent in one direction SHOULD be 410 considered a single data stream. For example: initialization vectors 411 SHOULD be passed from the end of one packet to the beginning of the 412 next packet. All ciphers SHOULD use keys with an effective key 413 length of 128 bits or more. 415 The ciphers in each direction MUST run independent of each other. 416 Implementations MUST allow the algorithm for each direction to be 417 independently selected, if multiple algorithms are allowed by local 418 policy. In practice however, it is RECOMMENDED that the same 419 algorithm be used in both directions. 421 The following ciphers are currently defined: 423 3des-cbc REQUIRED three-key 3DES in CBC mode 424 blowfish-cbc OPTIONAL Blowfish in CBC mode 425 twofish256-cbc OPTIONAL Twofish in CBC mode, 426 with 256-bit key 427 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 428 is being retained for 429 historical reasons) 430 twofish192-cbc OPTIONAL Twofish with 192-bit key 431 twofish128-cbc OPTIONAL Twofish with 128-bit key 432 aes256-cbc OPTIONAL AES in CBC mode, 433 with 256-bit key 434 aes192-cbc OPTIONAL AES with 192-bit key 435 aes128-cbc RECOMMENDED AES with 128-bit key 436 serpent256-cbc OPTIONAL Serpent in CBC mode, with 437 256-bit key 439 serpent192-cbc OPTIONAL Serpent with 192-bit key 440 serpent128-cbc OPTIONAL Serpent with 128-bit key 441 arcfour OPTIONAL the ARCFOUR stream cipher 442 idea-cbc OPTIONAL IDEA in CBC mode 443 cast128-cbc OPTIONAL CAST-128 in CBC mode 444 none OPTIONAL no encryption; NOT RECOMMENDED 446 The "3des-cbc" cipher is three-key triple-DES 447 (encrypt-decrypt-encrypt), where the first 8 bytes of the key are 448 used for the first encryption, the next 8 bytes for the decryption, 449 and the following 8 bytes for the final encryption. This requires 24 450 bytes of key data (of which 168 bits are actually used). To 451 implement CBC mode, outer chaining MUST be used (i.e., there is only 452 one initialization vector). This is a block cipher with 8 byte 453 blocks. This algorithm is defined in [FIPS-46-3]. Note that since 454 this algorithm only has an effective key length of 112 bits 455 ([SCHNEIER]), it does not meet the specifications that SSH encryption 456 algorithms should use keys of 128 bits or more. However, this 457 algorithm is still REQUIRED for historical reasons; essentially, all 458 known implementations at the time of this writing support this 459 algorithm, and it is commonly used because it is the fundamental 460 interoperable algorithm. At some future time it is expected that 461 another algorithm, one with better strength, will become so prevalent 462 and ubiquitous that the use of "3des-cbc" will be deprecated by 463 another STANDARDS ACTION. 465 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 466 [SCHNEIER]. This is a block cipher with 8 byte blocks. 468 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 469 with 256 bit keys as described [TWOFISH]. This is a block cipher 470 with 16 byte blocks. 472 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 474 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 476 The "aes256-cbc" cipher is AES (Advanced Encryption Standard) 477 [FIPS-197], in CBC mode. This version uses 256-bit key. 479 The "aes192-cbc" cipher. Same as above but with 192-bit key. 481 The "aes128-cbc" cipher. Same as above but with 128-bit key. 483 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as 484 described in the Serpent AES submission. 486 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 488 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 490 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 491 Arcfour cipher is believed to be compatible with the RC4 cipher 492 [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and 493 should be used with caution. 495 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 497 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 498 [RFC2144]. 500 The "none" algorithm specifies that no encryption is to be done. 501 Note that this method provides no confidentiality protection, and it 502 is NOT RECOMMENDED. Some functionality (e.g., password 503 authentication) may be disabled for security reasons if this cipher 504 is chosen. 506 Additional methods may be defined as specified in [SSH-ARCH] and in 507 [SSH-NUMBERS]. 509 6.4 Data Integrity 511 Data integrity is protected by including with each packet a MAC that 512 is computed from a shared secret, packet sequence number, and the 513 contents of the packet. 515 The message authentication algorithm and key are negotiated during 516 key exchange. Initially, no MAC will be in effect, and its length 517 MUST be zero. After key exchange, the 'mac' for the selected MAC 518 algorithm will be computed before encryption from the concatenation 519 of packet data: 521 mac = MAC(key, sequence_number || unencrypted_packet) 523 where 'unencrypted_packet' is the entire packet without 'mac' (the 524 length fields, 'payload' and 'random padding'), and 'sequence_number' 525 is an implicit packet sequence number represented as uint32. The 526 'sequence_number' is initialized to zero for the first packet, and is 527 incremented after every packet (regardless of whether encryption or 528 MAC is in use). It is never reset, even if keys/algorithms are 529 renegotiated later. It wraps around to zero after every 2^32 530 packets. The packet 'sequence_number' itself is not included in the 531 packet sent over the wire. 533 The MAC algorithms for each direction MUST run independently, and 534 implementations MUST allow choosing the algorithm independently for 535 both directions. 537 The value of 'mac' resulting from the MAC algorithm MUST be 538 transmitted without encryption as the last part of the packet. The 539 number of 'mac' bytes depends on the algorithm chosen. 541 The following MAC algorithms are currently defined: 543 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 544 length = 20) 545 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 546 length = 12, key length = 20) 547 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 548 length = 16) 549 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 550 length = 12, key length = 16) 551 none OPTIONAL no MAC; NOT RECOMMENDED 553 The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs 554 use only the first n bits of the resulting value. 556 The hash algorithms are described in [SCHNEIER]. 558 Additional methods may be defined as specified in [SSH-ARCH] and in 559 [SSH-NUMBERS]. 561 6.5 Key Exchange Methods 563 The key exchange method specifies how one-time session keys are 564 generated for encryption and for authentication, and how the server 565 authentication is done. 567 Two REQUIRED key exchange methods have been defined: 569 diffie-hellman-group1-sha1 REQUIRED 570 diffie-hellman-group14-sha1 REQUIRED 572 These methods are described in Section 8. 574 Additional methods may be defined as specified in [SSH-NUMBERS]. The 575 name "diffie-hellman-group1-sha1" is used for a key exchange method 576 using an Oakley group as defined in [RFC2409]. SSH maintains its own 577 group identifier space which is logically distinct from Oakley 578 [RFC2412] and IKE; however, for one additional group, the Working 579 Group adopted the number assigned by [RFC3526], using 580 diffie-hellman-group14-sha1 for the name of the second defined group. 581 Implementations should treat these names as opaque identifiers and 582 should not assume any relationship between the groups used by SSH and 583 the groups defined for IKE. 585 6.6 Public Key Algorithms 587 This protocol has been designed to be able to operate with almost any 588 public key format, encoding, and algorithm (signature and/or 589 encryption). 591 There are several aspects that define a public key type: 592 o Key format: how is the key encoded and how are certificates 593 represented. The key blobs in this protocol MAY contain 594 certificates in addition to keys. 595 o Signature and/or encryption algorithms. Some key types may not 596 support both signing and encryption. Key usage may also be 597 restricted by policy statements - e.g., in certificates. In this 598 case, different key types SHOULD be defined for the different 599 policy alternatives. 600 o Encoding of signatures and/or encrypted data. This includes but 601 is not limited to padding, byte order, and data formats. 603 The following public key and/or certificate formats are currently 604 defined: 606 ssh-dss REQUIRED sign Raw DSS Key 607 ssh-rsa RECOMMENDED sign Raw RSA Key 608 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 609 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 611 Additional key types may be defined as specified in [SSH-ARCH] and in 612 [SSH-NUMBERS]. 614 The key type MUST always be explicitly known (from algorithm 615 negotiation or some other source). It is not normally included in 616 the key blob. 618 Certificates and public keys are encoded as follows: 619 string certificate or public key format identifier 620 byte[n] key/certificate data 622 The certificate part may have be a zero length string, but a public 623 key is required. This is the public key that will be used for 624 authentication. The certificate sequence contained in the 625 certificate blob can be used to provide authorization. 627 Public key / certificate formats that do not explicitly specify a 628 signature format identifier MUST use the public key / certificate 629 format identifier as the signature identifier. 631 Signatures are encoded as follows: 632 string signature format identifier (as specified by the 633 public key / cert format) 634 byte[n] signature blob in format specific encoding. 636 The "ssh-dss" key format has the following specific encoding: 638 string "ssh-dss" 639 mpint p 640 mpint q 641 mpint g 642 mpint y 644 Here the 'p', 'q', 'g', and 'y' parameters form the signature key blob. 646 Signing and verifying using this key format is done according to the 647 Digital Signature Standard [FIPS-186-2] using the SHA-1 hash. 649 The resulting signature is encoded as follows: 651 string "ssh-dss" 652 string dss_signature_blob 654 The value for 'dss_signature_blob' is encoded as a string containing 655 r followed by s (which are 160 bits long integers, without lengths or 656 padding, unsigned and in network byte order). 658 The "ssh-rsa" key format has the following specific encoding: 660 string "ssh-rsa" 661 mpint e 662 mpint n 664 Here the 'e' and 'n' parameters form the signature key blob. 666 Signing and verifying using this key format is done according to 667 [SCHNEIER] and [RFC3447] using the SHA-1 hash. 669 The resulting signature is encoded as follows: 671 string "ssh-rsa" 672 string rsa_signature_blob 674 The value for 'rsa_signature_blob' is encoded as a string containing 675 s (which is an integer, without lengths or padding, unsigned and in 676 network byte order). 678 The "pgp-sign-rsa" method indicates the certificates, the public key, 679 and the signature are in OpenPGP compatible binary format 680 ([RFC2440]). This method indicates that the key is an RSA-key. 682 The "pgp-sign-dss". As above, but indicates that the key is a 683 DSS-key. 685 7. Key Exchange 687 Key exchange (kex) begins by each side sending name-lists of 688 supported algorithms. Each side has a preferred algorithm in each 689 category, and it is assumed that most implementations at any given 690 time will use the same preferred algorithm. Each side MAY guess 691 which algorithm the other side is using, and MAY send an initial key 692 exchange packet according to the algorithm if appropriate for the 693 preferred method. 695 The guess is considered wrong, if: 696 o the kex algorithm and/or the host key algorithm is guessed wrong 697 (server and client have different preferred algorithm), or 698 o if any of the other algorithms cannot be agreed upon (the 699 procedure is defined below in Section 7.1). 701 Otherwise, the guess is considered to be right and the optimistically 702 sent packet MUST be handled as the first key exchange packet. 704 However, if the guess was wrong, and a packet was optimistically sent 705 by one or both parties, such packets MUST be ignored (even if the 706 error in the guess would not affect the contents of the initial 707 packet(s)), and the appropriate side MUST send the correct initial 708 packet. 710 A key exchange method uses "explicit server authentication" if the 711 key exchange messages include a signature or other proof of the 712 server's authenticity. A key exchange method uses "implicit server 713 authentication" if, in order to prove its authenticity, the server 714 also has to prove that it knows the shared secret K, by sending a 715 message and a corresponding MAC which the client can verify. 717 The key exchange method defined by this document uses explicit server 718 authentication. However, key exchange methods with implicit server 719 authentication MAY be used with this protocol. After a key exchange 720 with implicit server authentication, the client MUST wait for a 721 response to its service request message before sending any further 722 data. 724 7.1 Algorithm Negotiation 726 Key exchange begins by each side sending the following packet: 728 byte SSH_MSG_KEXINIT 729 byte[16] cookie (random bytes) 730 name-list kex_algorithms 731 name-list server_host_key_algorithms 732 name-list encryption_algorithms_client_to_server 733 name-list encryption_algorithms_server_to_client 734 name-list mac_algorithms_client_to_server 735 name-list mac_algorithms_server_to_client 736 name-list compression_algorithms_client_to_server 737 name-list compression_algorithms_server_to_client 738 name-list languages_client_to_server 739 name-list languages_server_to_client 740 boolean first_kex_packet_follows 741 uint32 0 (reserved for future extension) 743 Each of the algorithm name-lists MUST be a comma-separated list of 744 algorithm names - see Algorithm Naming in [SSH-ARCH] and additional 745 information in [SSH-NUMBERS]. Each supported (allowed) algorithm 746 MUST be listed in order of preference, from most to least. 748 The first algorithm in each name-list MUST be the preferred (guessed) 749 algorithm. Each name-list MUST contain at least one algorithm name. 751 cookie 752 The 'cookie' MUST be a random value generated by the sender. 753 Its purpose is to make it impossible for either side to fully 754 determine the keys and the session identifier. 756 kex_algorithms 757 Key exchange algorithms were defined above. The first 758 algorithm MUST be the preferred (and guessed) algorithm. If 759 both sides make the same guess, that algorithm MUST be used. 760 Otherwise, the following algorithm MUST be used to choose a key 761 exchange method: Iterate over client's kex algorithms, one at a 762 time. Choose the first algorithm that satisfies the following 763 conditions: 764 + the server also supports the algorithm, 765 + if the algorithm requires an encryption-capable host key, 766 there is an encryption-capable algorithm on the server's 767 server_host_key_algorithms that is also supported by the 768 client, and 769 + if the algorithm requires a signature-capable host key, 770 there is a signature-capable algorithm on the server's 771 server_host_key_algorithms that is also supported by the 772 client. 773 If no algorithm satisfying all these conditions can be found, 774 the connection fails, and both sides MUST disconnect. 776 server_host_key_algorithms 777 A name-list of the algorithms supported for the server host 778 key. The server lists the algorithms for which it has host 779 keys; the client lists the algorithms that it is willing to 780 accept. (There MAY be multiple host keys for a host, possibly 781 with different algorithms.) 783 Some host keys may not support both signatures and encryption 784 (this can be determined from the algorithm), and thus not all 785 host keys are valid for all key exchange methods. 787 Algorithm selection depends on whether the chosen key exchange 788 algorithm requires a signature or encryption capable host key. 789 It MUST be possible to determine this from the public key 790 algorithm name. The first algorithm on the client's name-list 791 that satisfies the requirements and is also supported by the 792 server MUST be chosen. If there is no such algorithm, both 793 sides MUST disconnect. 795 encryption_algorithms 796 A name-list of acceptable symmetric encryption algorithms (also 797 known as ciphers) in order of preference. The chosen 798 encryption algorithm to each direction MUST be the first 799 algorithm on the client's name-list that is also on the 800 server's name-list. If there is no such algorithm, both sides 801 MUST disconnect. 803 Note that "none" must be explicitly listed if it is to be 804 acceptable. The defined algorithm names are listed in 805 Section 6.3. 807 mac_algorithms 808 A name-list of acceptable MAC algorithms in order of 809 preference. The chosen MAC algorithm 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 MAC algorithm names are listed in Section 6.4. 817 compression_algorithms 818 A name-list of acceptable compression algorithms in order of 819 preference. The chosen compression algorithm MUST be the first 820 algorithm on the client's name-list that is also on the 821 server's name-list. If there is no such algorithm, both sides 822 MUST disconnect. 824 Note that "none" must be explicitly listed if it is to be 825 acceptable. The compression algorithm names are listed in 826 Section 6.2. 828 languages 829 This is a name-list of language tags in order of preference 830 [RFC3066]. Both parties MAY ignore this name-list. If there 831 are no language preferences, this name-list SHOULD be empty as 832 defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT 833 be present unless they are known to be needed by the sending 834 party. 836 first_kex_packet_follows 837 Indicates whether a guessed key exchange packet follows. If a 838 guessed packet will be sent, this MUST be TRUE. If no guessed 839 packet will be sent, this MUST be FALSE. 841 After receiving the SSH_MSG_KEXINIT packet from the other side, 842 each party will know whether their guess was right. If the 843 other party's guess was wrong, and this field was TRUE, the 844 next packet MUST be silently ignored, and both sides MUST then 845 act as determined by the negotiated key exchange method. If 846 the guess was right, key exchange MUST continue using the 847 guessed packet. 849 After the KEXINIT packet exchange, the key exchange algorithm is run. 850 It may involve several packet exchanges, as specified by the key 851 exchange method. 853 Once a party has sent a KEXINIT message for key exchange or 854 re-exchange, until is has sent a NEWKEYS message (Section 7.3), it 855 MUST NOT send any messages other than: 856 o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST 857 and SERVICE_ACCEPT MUST NOT be sent); 858 o Algorithm negotiation messages (20 to 29) (but further KEXINITs 859 MUST NOT be sent); 860 o Specific key exchange method messages (30 to 49). 862 The provisions of Section 11 apply to unrecognized messages. 864 Note however that during a key re-exchange, after sending a KEXINIT 865 message, each party MUST be prepared to process an arbitrary number 866 of messages that may be in-flight before receiving a KEXINIT from the 867 other party. 869 7.2 Output from Key Exchange 871 The key exchange produces two values: a shared secret K, and an 872 exchange hash H. Encryption and authentication keys are derived from 873 these. The exchange hash H from the first key exchange is 874 additionally used as the session identifier, which is a unique 875 identifier for this connection. It is used by authentication methods 876 as a part of the data that is signed as a proof of possession of a 877 private key. Once computed, the session identifier is not changed, 878 even if keys are later re-exchanged. 880 Each key exchange method specifies a hash function that is used in 881 the key exchange. The same hash algorithm MUST be used in key 882 derivation. Here, we'll call it HASH. 884 Encryption keys MUST be computed as HASH of a known value and K as 885 follows: 886 o Initial IV client to server: HASH(K || H || "A" || session_id) 887 (Here K is encoded as mpint and "A" as byte and session_id as raw 888 data. "A" means the single character A, ASCII 65). 889 o Initial IV server to client: HASH(K || H || "B" || session_id) 890 o Encryption key client to server: HASH(K || H || "C" || session_id) 891 o Encryption key server to client: HASH(K || H || "D" || session_id) 892 o Integrity key client to server: HASH(K || H || "E" || session_id) 893 o Integrity key server to client: HASH(K || H || "F" || session_id) 895 Key data MUST be taken from the beginning of the hash output. 128 896 bits (16 bytes) MUST be used for algorithms with variable-length 897 keys. The only variable key length algorithm defined in this 898 document is arcfour). For other algorithms, as many bytes as are 899 needed are taken from the beginning of the hash value. If the key 900 length needed is longer than the output of the HASH, the key is 901 extended by computing HASH of the concatenation of K and H and the 902 entire key so far, and appending the resulting bytes (as many as HASH 903 generates) to the key. This process is repeated until enough key 904 material is available; the key is taken from the beginning of this 905 value. In other words: 907 K1 = HASH(K || H || X || session_id) (X is e.g., "A") 908 K2 = HASH(K || H || K1) 909 K3 = HASH(K || H || K1 || K2) 910 ... 911 key = K1 || K2 || K3 || ... 913 This process will lose entropy if the amount of entropy in K is 914 larger than the internal state size of HASH. 916 7.3 Taking Keys Into Use 918 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 919 This message is sent with the old keys and algorithms. All messages 920 sent after this message MUST use the new keys and algorithms. 922 When this message is received, the new keys and algorithms MUST be 923 taken into use for receiving. 925 The purpose of this message is to ensure that a party is able to 926 respond with a SSH_MSG_DISCONNECT message that the other party can 927 understand if something goes wrong with the key exchange. 929 byte SSH_MSG_NEWKEYS 931 8. Diffie-Hellman Key Exchange 933 The Diffie-Hellman (DH) key exchange provides a shared secret that 934 can not be determined by either party alone. The key exchange is 935 combined with a signature with the host key to provide host 936 authentication. This key exchange method provides explicit server 937 authentication as is defined in Section 7. 939 In the following description (C is the client, S is the server; p is 940 a large safe prime, g is a generator for a subgroup of GF(p), and q 941 is the order of the subgroup; V_S is S's version string; V_C is C's 942 version string; K_S is S's public host key; I_C is C's KEXINIT 943 message and I_S S's KEXINIT message which have been exchanged before 944 this part begins): 946 1. C generates a random number x (1 < x < q) and computes e = g^x 947 mod p. C sends "e" to S. 949 2. S generates a random number y (0 < y < q) and computes f = g^y 950 mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C 951 || V_S || I_C || I_S || K_S || e || f || K) (these elements are 952 encoded according to their types; see below), and signature s on 953 H with its private host key. S sends "K_S || f || s" to C. The 954 signing operation may involve a second hashing operation. 956 3. C verifies that K_S really is the host key for S (e.g., using 957 certificates or a local database). C is also allowed to accept 958 the key without verification; however, doing so will render the 959 protocol insecure against active attacks (but may be desirable 960 for practical reasons in the short term in many environments). C 961 then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || 962 K_S || e || f || K), and verifies the signature s on H. 964 Either side MUST NOT send or accept e or f values that are not in the 965 range [1, p-1]. If this condition is violated, the key exchange 966 fails. 968 This is implemented with the following messages. The hash algorithm 969 for computing the exchange hash is defined by the method name, and is 970 called HASH. The public key algorithm for signing is negotiated with 971 the KEXINIT messages. 973 First, the client sends the following: 975 byte SSH_MSG_KEXDH_INIT 976 mpint e 978 The server responds with the following: 980 byte SSH_MSG_KEXDH_REPLY 981 string server public host key and certificates (K_S) 982 mpint f 983 string signature of H 985 The hash H is computed as the HASH hash of the concatenation of the 986 following: 988 string V_C, the client's version string (CR and NL excluded) 989 string V_S, the server's version string (CR and NL excluded) 990 string I_C, the payload of the client's SSH_MSG_KEXINIT 991 string I_S, the payload of the server's SSH_MSG_KEXINIT 992 string K_S, the host key 993 mpint e, exchange value sent by the client 994 mpint f, exchange value sent by the server 995 mpint K, the shared secret 997 This value is called the exchange hash, and it is used to 998 authenticate the key exchange. The exchange hash SHOULD be kept 999 secret. 1001 The signature algorithm MUST be applied over H, not the original 1002 data. Most signature algorithms include hashing and additional 1003 padding - for example, "ssh-dss" specifies SHA-1 hashing. In that 1004 case, the data is first hashed with HASH to compute H, and H is then 1005 hashed with SHA-1 as part of the signing operation. 1007 8.1 diffie-hellman-group1-sha1 1009 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 1010 exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit 1011 MODP Group). This method MUST be supported for interoperability as 1012 all of the known implementations currently support it. Note that 1013 this method is named using the phrase "group1" even though it 1014 specifies the use of Oakley Group 2. 1016 8.2 diffie-hellman-group14-sha1 1018 The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key 1019 exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit 1020 MODP Group), and it MUST also be supported. 1022 9. Key Re-Exchange 1024 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when 1025 not already doing a key exchange (as described in Section 7.1). When 1026 this message is received, a party MUST respond with its own 1027 SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT 1028 already was a reply. Either party MAY initiate the re-exchange, but 1029 roles MUST NOT be changed (i.e., the server remains the server, and 1030 the client remains the client). 1032 Key re-exchange is performed using whatever encryption was in effect 1033 when the exchange was started. Encryption, compression, and MAC 1034 methods are not changed before a new SSH_MSG_NEWKEYS is sent after 1035 the key exchange (as in the initial key exchange). Re-exchange is 1036 processed identically to the initial key exchange, except for the 1037 session identifier that will remain unchanged. It is permissible to 1038 change some or all of the algorithms during the re-exchange. Host 1039 keys can also change. All keys and initialization vectors are 1040 recomputed after the exchange. Compression and encryption contexts 1041 are reset. 1043 It is RECOMMENDED that the keys are changed after each gigabyte of 1044 transmitted data or after each hour of connection time, whichever 1045 comes sooner. However, since the re-exchange is a public key 1046 operation, it requires a fair amount of processing power and should 1047 not be performed too often. 1049 More application data may be sent after the SSH_MSG_NEWKEYS packet 1050 has been sent; key exchange does not affect the protocols that lie 1051 above the SSH transport layer. 1053 10. Service Request 1055 After the key exchange, the client requests a service. The service 1056 is identified by a name. The format of names and procedures for 1057 defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS]. 1059 Currently, the following names have been reserved: 1061 ssh-userauth 1062 ssh-connection 1064 Similar local naming policy is applied to the service names, as is 1065 applied to the algorithm names. A local service should use the 1066 PRIVATE USE syntax of "servicename@domain". 1068 byte SSH_MSG_SERVICE_REQUEST 1069 string service name 1071 If the server rejects the service request, it SHOULD send an 1072 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 1074 When the service starts, it may have access to the session identifier 1075 generated during the key exchange. 1077 If the server supports the service (and permits the client to use 1078 it), it MUST respond with the following: 1080 byte SSH_MSG_SERVICE_ACCEPT 1081 string service name 1083 Message numbers used by services should be in the area reserved for 1084 them (see [SSH-ARCH]) and [SSH-NUMBERS]. The transport level will 1085 continue to process its own messages. 1087 Note that after a key exchange with implicit server authentication, 1088 the client MUST wait for response to its service request message 1089 before sending any further data. 1091 11. Additional Messages 1093 Either party may send any of the following messages at any time. 1095 11.1 Disconnection Message 1096 byte SSH_MSG_DISCONNECT 1097 uint32 reason code 1098 string description [RFC3629] 1099 string language tag [RFC3066] 1101 This message causes immediate termination of the connection. All 1102 implementations MUST be able to process this message; they SHOULD be 1103 able to send this message. 1105 The sender MUST NOT send or receive any data after this message, and 1106 the recipient MUST NOT accept any data after receiving this message. 1107 The Disconnection Message 'description' string gives a more specific 1108 explanation in a human-readable form. The Disconnection Message 1109 'reason code' gives the reason in a more machine-readable format 1110 (suitable for localization), and can have the values as displayed in 1111 the table below. Note that the decimal representation is displayed 1112 in this table for readability but that the values are actually uint32 1113 values. 1115 Symbolic name reason code 1116 ------------- ----------- 1117 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 1118 SSH_DISCONNECT_PROTOCOL_ERROR 2 1119 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 1120 SSH_DISCONNECT_RESERVED 4 1121 SSH_DISCONNECT_MAC_ERROR 5 1122 SSH_DISCONNECT_COMPRESSION_ERROR 6 1123 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1124 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1125 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1126 SSH_DISCONNECT_CONNECTION_LOST 10 1127 SSH_DISCONNECT_BY_APPLICATION 11 1128 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1129 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1130 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1131 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1133 If the 'description' string is displayed, control character filtering 1134 discussed in [SSH-ARCH] should be used to avoid attacks by sending 1135 terminal control characters. 1137 Requests for assignments of new Disconnection Message 'reason code' 1138 values (and associated 'description' text) in the range of 0x00000010 1139 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 1140 described in [RFC2434]. The Disconnection Message 'reason code' 1141 values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for 1142 PRIVATE USE. As is noted, the actual instructions to the IANA are in 1143 [SSH-NUMBERS]. 1145 11.2 Ignored Data Message 1146 byte SSH_MSG_IGNORE 1147 string data 1149 All implementations MUST understand (and ignore) this message at any 1150 time (after receiving the protocol version). No implementation is 1151 required to send them. This message can be used as an additional 1152 protection measure against advanced traffic analysis techniques. 1154 11.3 Debug Message 1155 byte SSH_MSG_DEBUG 1156 boolean always_display 1157 string message [RFC3629] 1158 string language tag [RFC3066] 1160 All implementations MUST understand this message, but they are 1161 allowed to ignore it. This message is used to transmit information 1162 that may help debugging. If always_display is TRUE, the message 1163 SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 1164 debugging information has been explicitly requested by the user. 1166 The 'message' doesn't need to contain a newline. It is, however, 1167 allowed to consist of multiple lines separated by CRLF (Carriage 1168 Return - Line Feed) pairs. 1170 If the 'message' string is displayed, terminal control character 1171 filtering discussed in [SSH-ARCH] should be used to avoid attacks by 1172 sending terminal control characters. 1174 11.4 Reserved Messages 1176 An implementation MUST respond to all unrecognized messages with an 1177 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1178 received. Such messages MUST be otherwise ignored. Later protocol 1179 versions may define other meanings for these message types. 1180 byte SSH_MSG_UNIMPLEMENTED 1181 uint32 packet sequence number of rejected message 1183 12. Summary of Message Numbers 1185 The following is a summary of messages and their associated message 1186 number. 1188 SSH_MSG_DISCONNECT 1 1189 SSH_MSG_IGNORE 2 1190 SSH_MSG_UNIMPLEMENTED 3 1191 SSH_MSG_DEBUG 4 1192 SSH_MSG_SERVICE_REQUEST 5 1193 SSH_MSG_SERVICE_ACCEPT 6 1194 SSH_MSG_KEXINIT 20 1195 SSH_MSG_NEWKEYS 21 1197 Note that numbers 30-49 are used for kex packets. Different kex 1198 methods may reuse message numbers in this range. 1200 13. IANA Considerations 1202 This document is part of a set. The IANA considerations for the SSH 1203 protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and 1204 this document, are detailed in [SSH-NUMBERS]. 1206 14. Security Considerations 1208 This protocol provides a secure encrypted channel over an insecure 1209 network. It performs server host authentication, key exchange, 1210 encryption, and integrity protection. It also derives a unique 1211 session id that may be used by higher-level protocols. 1213 Full security considerations for this protocol are provided in 1214 [SSH-ARCH]. 1216 15. References 1218 15.1 Normative 1220 [SSH-ARCH] 1221 Lonvick, C., "SSH Protocol Architecture", 1222 I-D draft-ietf-secsh-architecture-21.txt, February 2005. 1224 [SSH-USERAUTH] 1225 Lonvick, C., "SSH Authentication Protocol", 1226 I-D draft-ietf-secsh-userauth-26.txt, February 2005. 1228 [SSH-CONNECT] 1229 Lonvick, C., "SSH Connection Protocol", 1230 I-D draft-ietf-secsh-connect-24.txt, February 2005. 1232 [SSH-NUMBERS] 1233 Lonvick, C., "SSH Protocol Assigned Numbers", 1234 I-D draft-ietf-secsh-assignednumbers-11.txt, February 1235 2005. 1237 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1238 Specification version 3.3", RFC 1950, May 1996. 1240 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1241 version 1.3", RFC 1951, May 1996. 1243 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1244 Keyed-Hashing for Message Authentication", RFC 2104, 1245 February 1997. 1247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1248 Requirement Levels", BCP 14, RFC 2119, March 1997. 1250 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1251 May 1997. 1253 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1254 (IKE)", RFC 2409, November 1998. 1256 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1257 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1258 October 1998. 1260 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1261 "OpenPGP Message Format", RFC 2440, November 1998. 1263 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1264 B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1265 September 1999. 1267 [RFC3066] Alvestrand, H., "Tags for the Identification of 1268 Languages", BCP 47, RFC 3066, January 2001. 1270 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1271 X.509 Public Key Infrastructure Certificate and 1272 Certificate Revocation List (CRL) Profile", RFC 3280, 1273 April 2002. 1275 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1276 Standards (PKCS) #1: RSA Cryptography Specifications 1277 Version 2.1", RFC 3447, February 2003. 1279 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1280 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1281 RFC 3526, May 2003. 1283 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1284 10646", STD 63, RFC 3629, November 2003. 1286 [FIPS-186-2] 1287 Federal Information Processing Standards Publication, 1288 "FIPS PUB 186-2, Digital Signature Standard (DSS)", 1289 January 2000. 1291 [FIPS-197] 1292 NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", 1293 November 2001. 1295 [FIPS-46-3] 1296 U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption 1297 Standard (DES)", October 1999. 1299 [SCHNEIER] 1300 Schneier, B., "Applied Cryptography Second Edition: 1301 protocols algorithms and source in code in C", 1996. 1303 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1304 128-Bit Block Cipher, 1st Edition", March 1999. 1306 15.2 Informative 1308 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 1309 over Ethernet networks", STD 41, RFC 894, April 1984. 1311 [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for 1312 multi-protocol transmission of datagrams over 1313 Point-to-Point links", RFC 1134, November 1989. 1315 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1316 RFC 2412, November 1998. 1318 [ssh-1.2.30] 1319 Ylonen, T., "ssh-1.2.30/RFC", File within compressed 1320 tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/ 1321 ssh-1.2.30.tar.gz, November 1995. 1323 Author's Address 1325 Chris Lonvick (editor) 1326 Cisco Systems, Inc. 1327 12515 Research Blvd. 1328 Austin 78759 1329 USA 1331 Email: clonvick@cisco.com 1333 Intellectual Property Statement 1335 The IETF takes no position regarding the validity or scope of any 1336 Intellectual Property Rights or other rights that might be claimed to 1337 pertain to the implementation or use of the technology described in 1338 this document or the extent to which any license under such rights 1339 might or might not be available; nor does it represent that it has 1340 made any independent effort to identify any such rights. Information 1341 on the procedures with respect to rights in RFC documents can be 1342 found in BCP 78 and BCP 79. 1344 Copies of IPR disclosures made to the IETF Secretariat and any 1345 assurances of licenses to be made available, or the result of an 1346 attempt made to obtain a general license or permission for the use of 1347 such proprietary rights by implementers or users of this 1348 specification can be obtained from the IETF on-line IPR repository at 1349 http://www.ietf.org/ipr. 1351 The IETF invites any interested party to bring to its attention any 1352 copyrights, patents or patent applications, or other proprietary 1353 rights that may cover technology that may be required to implement 1354 this standard. Please address the information to the IETF at 1355 ietf-ipr@ietf.org. 1357 The IETF has been notified of intellectual property rights claimed in 1358 regard to some or all of the specification contained in this 1359 document. For more information consult the online list of claimed 1360 rights. 1362 Disclaimer of Validity 1364 This document and the information contained herein are provided on an 1365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1367 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1368 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1369 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1372 Copyright Statement 1374 Copyright (C) The Internet Society (2005). This document is subject 1375 to the rights, licenses and restrictions contained in BCP 78, and 1376 except as set forth therein, the authors retain all their rights. 1378 Acknowledgment 1380 Funding for the RFC Editor function is currently provided by the 1381 Internet Society.