idnits 2.17.1 draft-ietf-secsh-architecture-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 6 instances of too long lines in the document, the longest one being 39 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '...Each server host SHOULD have a host ke...' RFC 2119 keyword, line 140: '...ferent algorithms. Multiple hosts MAY...' RFC 2119 keyword, line 141: '...f a host has keys at all, it MUST have...' RFC 2119 keyword, line 142: '...e key using each REQUIRED public key a...' RFC 2119 keyword, line 175: '... SHOULD NOT normally allow such c...' (60 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 933 has weird spacing: '...er from modif...' -- 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 (July 14, 2003) is 7591 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) -- Missing reference section? 'SSH-TRANS' on line 1241 looks like a reference -- Missing reference section? 'SSH-USERAUTH' on line 1245 looks like a reference -- Missing reference section? 'SSH-CONNECT' on line 1249 looks like a reference -- Missing reference section? 'RFC-2119' on line 134 looks like a reference -- Missing reference section? 'FIPS-186' on line 1137 looks like a reference -- Missing reference section? 'RFC-854' on line 181 looks like a reference -- Missing reference section? 'RFC-1282' on line 181 looks like a reference -- Missing reference section? 'RFC-894' on line 298 looks like a reference -- Missing reference section? 'RFC-1134' on line 305 looks like a reference -- Missing reference section? 'RFC-2279' on line 322 looks like a reference -- Missing reference section? 'RFC-1766' on line 438 looks like a reference -- Missing reference section? 'RFC-1700' on line 364 looks like a reference -- Missing reference section? 'RFC-1034' on line 477 looks like a reference -- Missing reference section? 'RFC-2343' on line 530 looks like a reference -- Missing reference section? '1' on line 710 looks like a reference -- Missing reference section? '2' on line 553 looks like a reference -- Missing reference section? '3' on line 560 looks like a reference -- Missing reference section? '1750' on line 578 looks like a reference -- Missing reference section? 'FIPS-197' on line 1142 looks like a reference -- Missing reference section? 'SCHNEIER' on line 1258 looks like a reference -- Missing reference section? 'KAUFMAN' on line 1262 looks like a reference -- Missing reference section? 'PERLMAN' on line 1262 looks like a reference -- Missing reference section? 'SPECINER' on line 1262 looks like a reference -- Missing reference section? 'ROGAWAY' on line 1277 looks like a reference -- Missing reference section? 'DAI' on line 1282 looks like a reference -- Missing reference section? 'BELLARE' on line 1288 looks like a reference -- Missing reference section? 'KOHNO' on line 1288 looks like a reference -- Missing reference section? 'NAMPREMPRE' on line 1288 looks like a reference -- Missing reference section? '2085' on line 738 looks like a reference -- Missing reference section? '2246' on line 738 looks like a reference -- Missing reference section? '2743' on line 738 looks like a reference -- Missing reference section? '1964' on line 738 looks like a reference -- Missing reference section? '2025' on line 739 looks like a reference -- Missing reference section? '1510' on line 739 looks like a reference -- Missing reference section? '2104' on line 740 looks like a reference -- Missing reference section? 'ARCH' on line 790 looks like a reference -- Missing reference section? 'SSH-ARCH' on line 1237 looks like a reference -- Missing reference section? 'SCHEIFLER' on line 1151 looks like a reference -- Missing reference section? 'CERT' on line 1267 looks like a reference -- Missing reference section? 'VENEMA' on line 1271 looks like a reference -- Missing reference section? 'RFC0854' on line 1157 looks like a reference -- Missing reference section? 'RFC0894' on line 1161 looks like a reference -- Missing reference section? 'RFC1034' on line 1166 looks like a reference -- Missing reference section? 'RFC1134' on line 1170 looks like a reference -- Missing reference section? 'RFC1282' on line 1175 looks like a reference -- Missing reference section? 'RFC1510' on line 1178 looks like a reference -- Missing reference section? 'RFC1700' on line 1182 looks like a reference -- Missing reference section? 'RFC1750' on line 1186 looks like a reference -- Missing reference section? 'RFC1766' on line 1191 looks like a reference -- Missing reference section? 'RFC1964' on line 1195 looks like a reference -- Missing reference section? 'RFC2025' on line 1198 looks like a reference -- Missing reference section? 'RFC2085' on line 1202 looks like a reference -- Missing reference section? 'RFC2104' on line 1206 looks like a reference -- Missing reference section? 'RFC2119' on line 1212 looks like a reference -- Missing reference section? 'RFC2246' on line 1216 looks like a reference -- Missing reference section? 'RFC2279' on line 1220 looks like a reference -- Missing reference section? 'RFC2410' on line 1224 looks like a reference -- Missing reference section? 'RFC2434' on line 1228 looks like a reference -- Missing reference section? 'RFC2743' on line 1233 looks like a reference -- Missing reference section? 'SSH-NUMBERS' on line 1253 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 62 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ylonen 3 Internet-Draft T. Kivinen 4 Expires: January 12, 2004 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 July 14, 2003 12 SSH Protocol Architecture 13 draft-ietf-secsh-architecture-14.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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 Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 12, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 SSH is a protocol for secure remote login and other secure network 46 services over an insecure network. This document describes the 47 architecture of the SSH protocol, as well as the notation and 48 terminology used in SSH protocol documents. It also discusses the 49 SSH algorithm naming system that allows local extensions. The SSH 50 protocol consists of three major components: The Transport Layer 51 Protocol provides server authentication, confidentiality, and 52 integrity with perfect forward secrecy. The User Authentication 53 Protocol authenticates the client to the server. The Connection 54 Protocol multiplexes the encrypted tunnel into several logical 55 channels. Details of these protocols are described in separate 56 documents. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Specification of Requirements . . . . . . . . . . . . . . . 4 62 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4 Security Properties . . . . . . . . . . . . . . . . . . . . 7 67 3.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 7 68 3.6 Localization and Character Set Support . . . . . . . . . . . 8 69 4. Data Type Representations Used in the SSH Protocols . . . . 9 70 5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 12 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 73 8. Security Considerations . . . . . . . . . . . . . . . . . . 13 74 8.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 13 75 8.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 8.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 14 77 8.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 17 78 8.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 18 80 8.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 20 81 8.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 21 82 8.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 21 83 8.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 21 84 8.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 22 85 8.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 22 86 8.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 23 87 8.3.4 Public key authentication . . . . . . . . . . . . . . . . . 23 88 8.3.5 Password authentication . . . . . . . . . . . . . . . . . . 24 89 8.3.6 Host based authentication . . . . . . . . . . . . . . . . . 24 90 8.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 24 91 8.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 24 92 8.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 24 93 8.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 25 94 9. Intellectual Property . . . . . . . . . . . . . . . . . . . 25 95 10. Additional Information . . . . . . . . . . . . . . . . . . . 26 96 References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 98 Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 100 1. Introduction 102 SSH is a protocol for secure remote login and other secure network 103 services over an insecure network. It consists of three major 104 components: 105 o The Transport Layer Protocol [SSH-TRANS] provides server 106 authentication, confidentiality, and integrity. It may 107 optionally also provide compression. The transport layer will 108 typically be run over a TCP/IP connection, but might also be 109 used on top of any other reliable data stream. 110 o The User Authentication Protocol [SSH-USERAUTH] authenticates 111 the client-side user to the server. It runs over the transport 112 layer protocol. 113 o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted 114 tunnel into several logical channels. It runs over the user 115 authentication protocol. 117 The client sends a service request once a secure transport layer 118 connection has been established. A second service request is sent 119 after user authentication is complete. This allows new protocols 120 to be defined and coexist with the protocols listed above. 122 The connection protocol provides channels that can be used for a 123 wide range of purposes. Standard methods are provided for setting 124 up secure interactive shell sessions and for forwarding 125 ("tunneling") arbitrary TCP/IP ports and X11 connections. 127 2. Specification of Requirements 129 All documents related to the SSH protocols shall use the keywords 130 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 131 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 132 requirements. They are to be interpreted as described in [RFC- 133 2119]. 135 3. Architecture 137 3.1 Host Keys 139 Each server host SHOULD have a host key. Hosts MAY have multiple 140 host keys using multiple different algorithms. Multiple hosts MAY 141 share the same host key. If a host has keys at all, it MUST have 142 at least one key using each REQUIRED public key algorithm 143 (currently DSS [FIPS-186]). 145 The server host key is used during key exchange to verify that the 146 client is really talking to the correct server. For this to be 147 possible, the client must have a priori knowledge of the server's 148 public host key. 150 Two different trust models can be used: 151 o The client has a local database that associates each host name 152 (as typed by the user) with the corresponding public host key. 153 This method requires no centrally administered infrastructure, 154 and no third-party coordination. The downside is that the 155 database of name-to-key associations may become burdensome to 156 maintain. 157 o The host name-to-key association is certified by some trusted 158 certification authority. The client only knows the CA root 159 key, and can verify the validity of all host keys certified by 160 accepted CAs. 162 The second alternative eases the maintenance problem, since 163 ideally only a single CA key needs to be securely stored on the 164 client. On the other hand, each host key must be appropriately 165 certified by a central authority before authorization is 166 possible. Also, a lot of trust is placed on the central 167 infrastructure. 169 The protocol provides the option that the server name - host key 170 association is not checked when connecting to the host for the 171 first time. This allows communication without prior communication 172 of host keys or certification. The connection still provides 173 protection against passive listening; however, it becomes 174 vulnerable to active man-in-the-middle attacks. Implementations 175 SHOULD NOT normally allow such connections by default, as they 176 pose a potential security problem. However, as there is no widely 177 deployed key infrastructure available on the Internet yet, this 178 option makes the protocol much more usable during the transition 179 time until such an infrastructure emerges, while still providing a 180 much higher level of security than that offered by older solutions 181 (e.g. telnet [RFC-854] and rlogin [RFC-1282]). 183 Implementations SHOULD try to make the best effort to check host 184 keys. An example of a possible strategy is to only accept a host 185 key without checking the first time a host is connected, save the 186 key in a local database, and compare against that key on all 187 future connections to that host. 189 Implementations MAY provide additional methods for verifying the 190 correctness of host keys, e.g. a hexadecimal fingerprint derived 191 from the SHA-1 hash of the public key. Such fingerprints can 192 easily be verified by using telephone or other external 193 communication channels. 195 All implementations SHOULD provide an option to not accept host 196 keys that cannot be verified. 198 We believe that ease of use is critical to end-user acceptance of 199 security solutions, and no improvement in security is gained if 200 the new solutions are not used. Thus, providing the option not to 201 check the server host key is believed to improve the overall 202 security of the Internet, even though it reduces the security of 203 the protocol in configurations where it is allowed. 205 3.2 Extensibility 207 We believe that the protocol will evolve over time, and some 208 organizations will want to use their own encryption, 209 authentication and/or key exchange methods. Central registration 210 of all extensions is cumbersome, especially for experimental or 211 classified features. On the other hand, having no central 212 registration leads to conflicts in method identifiers, making 213 interoperability difficult. 215 We have chosen to identify algorithms, methods, formats, and 216 extension protocols with textual names that are of a specific 217 format. DNS names are used to create local namespaces where 218 experimental or classified extensions can be defined without fear 219 of conflicts with other implementations. 221 One design goal has been to keep the base protocol as simple as 222 possible, and to require as few algorithms as possible. However, 223 all implementations MUST support a minimal set of algorithms to 224 ensure interoperability (this does not imply that the local policy 225 on all hosts would necessary allow these algorithms). The 226 mandatory algorithms are specified in the relevant protocol 227 documents. 229 Additional algorithms, methods, formats, and extension protocols 230 can be defined in separate drafts. See Section Algorithm Naming 231 (Section 5) for more information. 233 3.3 Policy Issues 235 The protocol allows full negotiation of encryption, integrity, key 236 exchange, compression, and public key algorithms and formats. 237 Encryption, integrity, public key, and compression algorithms can 238 be different for each direction. 240 The following policy issues SHOULD be addressed in the 241 configuration mechanisms of each implementation: 242 o Encryption, integrity, and compression algorithms, separately 243 for each direction. The policy MUST specify which is the 244 preferred algorithm (e.g. the first algorithm listed in each 245 category). 246 o Public key algorithms and key exchange method to be used for 247 host authentication. The existence of trusted host keys for 248 different public key algorithms also affects this choice. 249 o The authentication methods that are to be required by the 250 server for each user. The server's policy MAY require multiple 251 authentication for some or all users. The required algorithms 252 MAY depend on the location where the user is trying to log in 253 from. 254 o The operations that the user is allowed to perform using the 255 connection protocol. Some issues are related to security; for 256 example, the policy SHOULD NOT allow the server to start 257 sessions or run commands on the client machine, and MUST NOT 258 allow connections to the authentication agent unless forwarding 259 such connections has been requested. Other issues, such as 260 which TCP/IP ports can be forwarded and by whom, are clearly 261 issues of local policy. Many of these issues may involve 262 traversing or bypassing firewalls, and are interrelated with 263 the local security policy. 265 3.4 Security Properties 267 The primary goal of the SSH protocol is improved security on the 268 Internet. It attempts to do this in a way that is easy to deploy, 269 even at the cost of absolute security. 270 o All encryption, integrity, and public key algorithms used are 271 well-known, well-established algorithms. 272 o All algorithms are used with cryptographically sound key sizes 273 that are believed to provide protection against even the 274 strongest cryptanalytic attacks for decades. 275 o All algorithms are negotiated, and in case some algorithm is 276 broken, it is easy to switch to some other algorithm without 277 modifying the base protocol. 279 Specific concessions were made to make wide-spread fast deployment 280 easier. The particular case where this comes up is verifying that 281 the server host key really belongs to the desired host; the 282 protocol allows the verification to be left out (but this is NOT 283 RECOMMENDED). This is believed to significantly improve usability 284 in the short term, until widespread Internet public key 285 infrastructures emerge. 287 3.5 Packet Size and Overhead 289 Some readers will worry about the increase in packet size due to 290 new headers, padding, and MAC. The minimum packet size is in the 291 order of 28 bytes (depending on negotiated algorithms). The 292 increase is negligible for large packets, but very significant for 293 one-byte packets (telnet-type sessions). There are, however, 294 several factors that make this a non-issue in almost all cases: 295 o The minimum size of a TCP/IP header is 32 bytes. Thus, the 296 increase is actually from 33 to 51 bytes (roughly). 297 o The minimum size of the data field of an Ethernet packet is 46 298 bytes [RFC-894]. Thus, the increase is no more than 5 bytes. 299 When Ethernet headers are considered, the increase is less than 300 10 percent. 301 o The total fraction of telnet-type data in the Internet is 302 negligible, even with increased packet sizes. 304 The only environment where the packet size increase is likely to 305 have a significant effect is PPP [RFC-1134] over slow modem lines 306 (PPP compresses the TCP/IP headers, emphasizing the increase in 307 packet size). However, with modern modems, the time needed to 308 transfer is in the order of 2 milliseconds, which is a lot faster 309 than people can type. 311 There are also issues related to the maximum packet size. To 312 minimize delays in screen updates, one does not want excessively 313 large packets for interactive sessions. The maximum packet size 314 is negotiated separately for each channel. 316 3.6 Localization and Character Set Support 318 For the most part, the SSH protocols do not directly pass text 319 that would be displayed to the user. However, there are some 320 places where such data might be passed. When applicable, the 321 character set for the data MUST be explicitly specified. In most 322 places, ISO 10646 with UTF-8 encoding is used [RFC-2279]. When 323 applicable, a field is also provided for a language tag [RFC- 324 1766]. 326 One big issue is the character set of the interactive session. 327 There is no clear solution, as different applications may display 328 data in different formats. Different types of terminal emulation 329 may also be employed in the client, and the character set to be 330 used is effectively determined by the terminal emulation. Thus, 331 no place is provided for directly specifying the character set or 332 encoding for terminal session data. However, the terminal 333 emulation type (e.g. "vt100") is transmitted to the remote site, 334 and it implicitly specifies the character set and encoding. 335 Applications typically use the terminal type to determine what 336 character set they use, or the character set is determined using 337 some external means. The terminal emulation may also allow 338 configuring the default character set. In any case, the character 339 set for the terminal session is considered primarily a client 340 local issue. 342 Internal names used to identify algorithms or protocols are 343 normally never displayed to users, and must be in US-ASCII. 345 The client and server user names are inherently constrained by 346 what the server is prepared to accept. They might, however, 347 occasionally be displayed in logs, reports, etc. They MUST be 348 encoded using ISO 10646 UTF-8, but other encodings may be required 349 in some cases. It is up to the server to decide how to map user 350 names to accepted user names. Straight bit-wise binary comparison 351 is RECOMMENDED. 353 For localization purposes, the protocol attempts to minimize the 354 number of textual messages transmitted. When present, such 355 messages typically relate to errors, debugging information, or 356 some externally configured data. For data that is normally 357 displayed, it SHOULD be possible to fetch a localized message 358 instead of the transmitted message by using a numerical code. The 359 remaining messages SHOULD be configurable. 361 4. Data Type Representations Used in the SSH Protocols 362 byte 364 A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. 365 Fixed length data is sometimes represented as an array of 366 bytes, written byte[n], where n is the number of bytes in the 367 array. 369 boolean 371 A boolean value is stored as a single byte. The value 0 372 represents FALSE, and the value 1 represents TRUE. All non- 373 zero values MUST be interpreted as TRUE; however, applications 374 MUST NOT store values other than 0 and 1. 376 uint32 378 Represents a 32-bit unsigned integer. Stored as four bytes in 379 the order of decreasing significance (network byte order). For 380 example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 381 aa. 383 uint64 385 Represents a 64-bit unsigned integer. Stored as eight bytes in 386 the order of decreasing significance (network byte order). 388 string 390 Arbitrary length binary string. Strings are allowed to contain 391 arbitrary binary data, including null characters and 8-bit 392 characters. They are stored as a uint32 containing its length 393 (number of bytes that follow) and zero (= empty string) or more 394 bytes that are the value of the string. Terminating null 395 characters are not used. 397 Strings are also used to store text. In that case, US-ASCII is 398 used for internal names, and ISO-10646 UTF-8 for text that 399 might be displayed to the user. The terminating null character 400 SHOULD NOT normally be stored in the string. 402 For example, the US-ASCII string "testing" is represented as 00 403 00 00 07 t e s t i n g. The UTF8 mapping does not alter the 404 encoding of US-ASCII characters. 406 mpint 408 Represents multiple precision integers in two's complement 409 format, stored as a string, 8 bits per byte, MSB first. 410 Negative numbers have the value 1 as the most significant bit 411 of the first byte of the data partition. If the most 412 significant bit would be set for a positive number, the number 413 MUST be preceded by a zero byte. Unnecessary leading bytes 414 with the value 0 or 255 MUST NOT be included. The value zero 415 MUST be stored as a string with zero bytes of data. 417 By convention, a number that is used in modular computations in 418 Z_n SHOULD be represented in the range 0 <= x < n. 420 Examples: 421 value (hex) representation (hex) 422 --------------------------------------------------------------- 423 0 00 00 00 00 424 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 425 80 00 00 00 02 00 80 426 -1234 00 00 00 02 ed cc 427 -deadbeef 00 00 00 05 ff 21 52 41 11 429 name-list 431 A string containing a comma separated list of names. A name 432 list is represented as a uint32 containing its length (number 433 of bytes that follow) followed by a comma-separated list of 434 zero or more names. A name MUST be non-zero length, and it 435 MUST NOT contain a comma (','). Context may impose additional 436 restrictions on the names; for example, the names in a list may 437 have to be valid algorithm identifier (see Algorithm Naming 438 below), or [RFC-1766] language tags. The order of the names in 439 a list may or may not be significant, also depending on the 440 context where the list is is used. Terminating NUL characters 441 are not used, neither for the individual names, nor for the 442 list as a whole. 444 Examples: 445 value representation (hex) 446 --------------------------------------- 447 (), the empty list 00 00 00 00 448 ("zlib") 00 00 00 04 7a 6c 69 62 449 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 451 5. Algorithm Naming 453 The SSH protocols refer to particular hash, encryption, integrity, 454 compression, and key exchange algorithms or protocols by names. 455 There are some standard algorithms that all implementations MUST 456 support. There are also algorithms that are defined in the 457 protocol specification but are OPTIONAL. Furthermore, it is 458 expected that some organizations will want to use their own 459 algorithms. 461 In this protocol, all algorithm identifiers MUST be printable US- 462 ASCII non-empty strings no longer than 64 characters. Names MUST 463 be case-sensitive. 465 There are two formats for algorithm names: 466 o Names that do not contain an at-sign (@) are reserved to be 467 assigned by IETF consensus (RFCs). Examples include `3des- 468 cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part 469 of the name). Names of this format MUST NOT be used without 470 first registering them. Registered names MUST NOT contain an 471 at-sign (@) or a comma (,). 472 o Anyone can define additional algorithms by using names in the 473 format name@domainname, e.g. "ourcipher-cbc@ssh.com". The 474 format of the part preceding the at sign is not specified; it 475 MUST consist of US-ASCII characters except at-sign and comma. 476 The part following the at-sign MUST be a valid fully qualified 477 internet domain name [RFC-1034] controlled by the person or 478 organization defining the name. It is up to each domain how it 479 manages its local namespace. 481 6. Message Numbers 483 SSH packets have message numbers in the range 1 to 255. These 484 numbers have been allocated as follows: 486 Transport layer protocol: 488 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, 489 etc.) 490 20 to 29 Algorithm negotiation 491 30 to 49 Key exchange method specific (numbers can be reused for 492 different authentication methods) 494 User authentication protocol: 496 50 to 59 User authentication generic 497 60 to 79 User authentication method specific (numbers can be 498 reused for different authentication methods) 500 Connection protocol: 502 80 to 89 Connection protocol generic 503 90 to 127 Channel related messages 505 Reserved for client protocols: 507 128 to 191 Reserved 509 Local extensions: 511 192 to 255 Local extensions 513 7. IANA Considerations 515 Allocation of the following types of names in the SSH protocols is 516 assigned by IETF consensus: 517 o encryption algorithm names, 518 o MAC algorithm names, 519 o public key algorithm names (public key algorithm also implies 520 encoding and signature/encryption capability), 521 o key exchange method names, and 522 o protocol (service) names. 524 These names MUST be printable US-ASCII strings, and MUST NOT 525 contain the characters at-sign ('@'), comma (','), or whitespace 526 or control characters (ASCII codes 32 or less). Names are case- 527 sensitive, and MUST NOT be longer than 64 characters. 529 Names with the at-sign ('@') in them are allocated by the owner of 530 DNS name after the at-sign (hierarchical allocation in [RFC- 531 2343]), otherwise the same restrictions as above. 533 Each category of names listed above has a separate namespace. 534 However, using the same name in multiple categories SHOULD be 535 avoided to minimize confusion. 537 Message numbers (see Section Message Numbers (Section 6)) in the 538 range of 0..191 should be allocated via IETF consensus; message 539 numbers in the 192..255 range (the "Local extensions" set) are 540 reserved for private use. 542 8. Security Considerations 544 In order to make the entire body of Security Considerations more 545 accessible, Security Considerations for the transport, 546 authentication, and connection documents have been gathered here. 548 The transport protocol [1] provides a confidential channel over an 549 insecure network. It performs server host authentication, key 550 exchange, encryption, and integrity protection. It also derives a 551 unique session id that may be used by higher-level protocols. 553 The authentication protocol [2] provides a suite of mechanisms 554 which can be used to authenticate the client user to the server. 555 Individual mechanisms specified in the in authentication protocol 556 use the session id provided by the transport protocol and/or 557 depend on the security and integrity guarantees of the transport 558 protocol. 560 The connection protocol [3] specifies a mechanism to multiplex 561 multiple streams [channels] of data over the confidential and 562 authenticated transport. It also specifies channels for accessing 563 an interactive shell, for 'proxy-forwarding' various external 564 protocols over the secure transport (including arbitrary TCP/IP 565 protocols), and for accessing secure 'subsystems' on the server 566 host. 568 8.1 Pseudo-Random Number Generation 570 This protocol binds each session key to the session by including 571 random, session specific data in the hash used to produce session 572 keys. Special care should be taken to ensure that all of the 573 random numbers are of good quality. If the random data here 574 (e.g., DH parameters) are pseudo-random then the pseudo-random 575 number generator should be cryptographically secure (i.e., its 576 next output not easily guessed even when knowing all previous 577 outputs) and, furthermore, proper entropy needs to be added to the 578 pseudo-random number generator. RFC 1750 [1750] offers 579 suggestions for sources of random numbers and entropy. 580 Implementors should note the importance of entropy and the well- 581 meant, anecdotal warning about the difficulty in properly 582 implementing pseudo-random number generating functions. 584 The amount of entropy available to a given client or server may 585 sometimes be less than what is required. In this case one must 586 either resort to pseudo-random number generation regardless of 587 insufficient entropy or refuse to run the protocol. The latter is 588 preferable. 590 8.2 Transport 592 8.2.1 Confidentiality 594 It is beyond the scope of this document and the Secure Shell 595 Working Group to analyze or recommend specific ciphers other than 596 the ones which have been established and accepted within the 597 industry. At the time of this writing, ciphers commonly in use 598 include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has 599 been accepted by The published as a US Federal Information 600 Processing Standards [FIPS-197] and the cryptographic community as 601 being acceptable for this purpose as well has accepted AES. As 602 always, implementors and users should check current literature to 603 ensure that no recent vulnerabilities have been found in ciphers 604 used within products. Implementors should also check to see which 605 ciphers are considered to be relatively stronger than others and 606 should recommend their use to users over relatively weaker 607 ciphers. It would be considered good form for an implementation 608 to politely and unobtrusively notify a user that a stronger cipher 609 is available and should be used when a weaker one is actively 610 chosen. 612 The "none" cipher is provided for debugging and SHOULD NOT be used 613 except for that purpose. It's cryptographic properties are 614 sufficiently described in RFC 2410, which will show that its use 615 does not meet the intent of this protocol. 617 The relative merits of these and other ciphers may also be found 618 in current literature. Two references that may provide 619 information on the subject are [SCHNEIER] and 621 [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode 622 of operation of certain ciphers and the weakness of this scheme. 623 Essentially, this mode is theoretically vulnerable to chosen 624 cipher-text attacks because of the high predictability of the 625 start of packet sequence. However, this attack is still deemed 626 difficult and not considered fully practicable especially if 627 relatively longer block sizes are used. 629 Additionally, another CBC mode attack may be mitigated through the 630 insertion of packets containing SSH_MSG_IGNORE. Without this 631 technique, a specific attack may be successful. For this attack 632 (commonly known as the Rogaway attack 633 [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]) to work, the attacker 634 would need to know the IV of the next block that is going to be 635 encrypted. In CBC mode that is the output of the encryption of 636 the previous block. If the attacker does not have any way to see 637 the packet yet (i.e it is in the internal buffers of the ssh 638 implementation or even in the kernel) then this attack will not 639 work. If the last packet has been sent out to the network (i.e 640 the attacker has access to it) then he can use the attack. 642 In the optimal case an implementor would need to add an extra 643 packet only if the packet has been sent out onto the network and 644 there are no other packets waiting for transmission. Implementors 645 may wish to check to see if there are any unsent packets awaiting 646 transmission, but unfortunately it is not normally easy to obtain 647 this information from the kernel or buffers. If there are not, 648 then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new 649 packet is added to the stream every time the attacker knows the IV 650 that is supposed to be used for the next packet, then the attacker 651 will not be able to guess the correct IV, thus the attack will 652 never be successfull. 654 As an example, consider the following case: 656 Client Server 657 ------ ------ 658 TCP(seq=x, len=500) -> 659 contains Record 1 661 [500 ms passes, no ACK] 663 TCP(seq=x, len=1000) -> 664 contains Records 1,2 666 ACK 668 1. The Nagle algorithm + TCP retransmits mean that the two 669 records get coalesced into a single TCP segment 670 2. Record 2 is *not* at the beginning of the TCP segment and 671 never will be, since it gets ACKed. 672 3. Yet, the attack is possible because Record 1 has already been 673 seen. 675 As this example indicates, it's totally unsafe to use the 676 existence of unflushed data in the TCP buffers proper as a guide 677 to whether you need an empty packet, since when you do the second 678 write(), the buffers will contain the un-ACKed Record 1. 680 On the other hand, it's perfectly safe to have the following 681 situation: 683 Client Server 684 ------ ------ 685 TCP(seq=x, len=500) -> 686 contains SSH_MSG_IGNORE 688 TCP(seq=y, len=500) -> 689 contains Data 691 Provided that the IV for second SSH Record is fixed after the data for 692 the Data packet is determined -i.e. you do: 693 read from user 694 encrypt null packet 695 encrypt data packet 697 8.2.2 Data Integrity 699 This protocol does allow the Data Integrity mechanism to be 700 disabled. Implementors SHOULD be wary of exposing this feature 701 for any purpose other than debugging. Users and administrators 702 SHOULD be explicitly warned anytime the "none" MAC is enabled. 704 So long as the "none" MAC is not used, this protocol provides data 705 integrity. 707 Because MACs use a 32 bit sequence number, they might start to 708 leak information after 2**32 packets have been sent. However, 709 following the rekeying recommendations should prevent this attack. 710 The transport protocol [1] recommends rekeying after one gigabyte 711 of data, and the smallest possible packet is 16 bytes. Therefore, 712 rekeying SHOULD happen after 2**28 packets at the very most. 714 8.2.3 Replay 716 The use of a MAC other than 'none' provides integrity and 717 authentication. In addition, the transport protocol provides a 718 unique session identifier (bound in part to pseudo-random data 719 that is part of the algorithm and key exchange process) that can 720 be used by higher level protocols to bind data to a given session 721 and prevent replay of data from prior sessions. For example, the 722 authentication protocol uses this to prevent replay of signatures 723 from previous sessions. Because public key authentication 724 exchanges are cryptographically bound to the session (i.e., to the 725 initial key exchange) they cannot be successfully replayed in 726 other sessions. Note that the session ID can be made public 727 without harming the security of the protocol. 729 If two session happen to have the same session ID [hash of key 730 exchanges] then packets from one can be replayed against the 731 other. It must be stressed that the chances of such an occurrence 732 are, needless to say, minimal when using modern cryptographic 733 methods. This is all the more so true when specifying larger hash 734 function outputs and DH parameters. 736 Replay detection using monotonically increasing sequence numbers 737 as input to the MAC, or HMAC in some cases, is described in RFC 738 2085 [2085], RFC 2246 [2246], RFC 2743 [2743], RFC 1964 [1964], 739 RFC 2025 [2025], and RFC 1510 [1510]. The underlying construct is 740 discussed in RFC 2104 [2104]. Essentially a different sequence 741 number in each packet ensures that at least this one input to the 742 MAC function will be unique and will provide a nonrecurring MAC 743 output that is not predictable to an attacker. If the session 744 stays active long enough, however, this sequence number will wrap. 745 This event may provide an attacker an opportunity to replay a 746 previously recorded packet with an identical sequence number but 747 only if the peers have not rekeyed since the transmission of the 748 first packet with that sequence number. If the peers have 749 rekeyed, then the replay will be detected as the MAC check will 750 fail. For this reason, it must be emphasized that peers MUST 751 rekey before a wrap of the sequence numbers. Naturally, if an 752 attacker does attempt to replay a captured packet before the peers 753 have rekeyed, then the receiver of the duplicate packet will not 754 be able to validate the MAC and it will be discarded. The reason 755 that the MAC will fail is because the receiver will formulate a 756 MAC based upon the packet contents, the shared secret, and the 757 expected sequence number. Since the replayed packet will not be 758 using that expected sequence number (the sequence number of the 759 replayed packet will have already been passed by the receiver) 760 then the calculated MAC will not match the MAC received with the 761 packet. 763 8.2.4 Man-in-the-middle 765 This protocol makes no assumptions nor provisions for an 766 infrastructure or means for distributing the public keys of hosts. 767 It is expected that this protocol will sometimes be used without 768 first verifying the association between the server host key and 769 the server host name. Such usage is vulnerable to man-in-the- 770 middle attacks. This section describes this and encourages 771 administrators and users to understand the importance of verifying 772 this association before any session is initiated. 774 There are three cases of man-in-the-middle attacks to consider. 775 The first is where an attacker places a device between the client 776 and the server before the session is initiated. In this case, the 777 attack device is trying to mimic the legitimate server and will 778 offer its public key to the client when the client initiates a 779 session. If it were to offer the public key of the server, then 780 it would not be able to decrypt or sign the transmissions between 781 the legitimate server and the client unless it also had access to 782 the private-key of the host. The attack device will also, 783 simultaneously to this, initiate a session to the legitimate 784 server masquerading itself as the client. If the public key of 785 the server had been securely distributed to the client prior to 786 that session initiation, the key offered to the client by the 787 attack device will not match the key stored on the client. In 788 that case, the user SHOULD be given a warning that the offered 789 host key does not match the host key cached on the client. As 790 described in Section 3.1 of [ARCH], the user may be free to accept 791 the new key and continue the session. It is RECOMMENDED that the 792 warning provide sufficient information to the user of the client 793 device so they may make an informed decision. If the user chooses 794 to continue the session with the stored public-key of the server 795 (not the public-key offered at the start of the session), then the 796 session specific data between the attacker and server will be 797 different between the client-to-attacker session and the attacker- 798 to-server sessions due to the randomness discussed above. From 799 this, the attacker will not be able to make this attack work since 800 the attacker will not be able to correctly sign packets containing 801 this session specific data from the server since he does not have 802 the private key of that server. 804 The second case that should be considered is similar to the first 805 case in that it also happens at the time of connection but this 806 case points out the need for the secure distribution of server 807 public keys. If the server public keys are not securely 808 distributed then the client cannot know if it is talking to the 809 intended server. An attacker may use social engineering 810 techniques to pass off server keys to unsuspecting users and may 811 then place a man-in-the-middle attack device between the 812 legitimate server and the clients. If this is allowed to happen 813 then the clients will form client-to-attacker sessions and the 814 attacker will form attacker-to-server sessions and will be able to 815 monitor and manipulate all of the traffic between the clients and 816 the legitimate servers. Server administrators are encouraged to 817 make host key fingerprints available for checking by some means 818 whose security does not rely on the integrity of the actual host 819 keys. Possible mechanisms are discussed in Section 3.1 of [SSH- 820 ARCH] and may also include secured Web pages, physical pieces of 821 paper, etc. Implementors SHOULD provide recommendations on how 822 best to do this with their implementation. Because the protocol 823 is extensible, future extensions to the protocol may provide 824 better mechanisms for dealing with the need to know the server's 825 host key before connecting. For example, making the host key 826 fingerprint available through a secure DNS lookup, or using 827 kerberos over gssapi during key exchange to authenticate the 828 server are possibilities. 830 In the third man-in-the-middle case, attackers may attempt to 831 manipulate packets in transit between peers after the session has 832 been established. As described in the Replay part of this 833 section, a successful attack of this nature is very improbable. 834 As in the Replay section, this reasoning does assume that the MAC 835 is secure and that it is infeasible to construct inputs to a MAC 836 algorithm to give a known output. This is discussed in much 837 greater detail in Section 6 of RFC 2104. If the MAC algorithm has 838 a vulnerability or is weak enough, then the attacker may be able 839 to specify certain inputs to yield a known MAC. With that they 840 may be able to alter the contents of a packet in transit. 841 Alternatively the attacker may be able to exploit the algorithm 842 vulnerability or weakness to find the shared secret by reviewing 843 the MACs from captured packets. In either of those cases, an 844 attacker could construct a packet or packets that could be 845 inserted into an SSH stream. To prevent that, implementors are 846 encouraged to utilize commonly accepted MAC algorithms and 847 administrators are encouraged to watch current literature and 848 discussions of cryptography to ensure that they are not using a 849 MAC algorithm that has a recently found vulnerability or weakness. 851 In summary, the use of this protocol without a reliable 852 association of the binding between a host and its host keys is 853 inherently insecure and is NOT RECOMMENDED. It may however be 854 necessary in non-security critical environments, and will still 855 provide protection against passive attacks. Implementors of 856 protocols and applications running on top of this protocol should 857 keep this possibility in mind. 859 8.2.5 Denial-of-service 861 This protocol is designed to be used over a reliable transport. 862 If transmission errors or message manipulation occur, the 863 connection is closed. The connection SHOULD be re-established if 864 this occurs. Denial of service attacks of this type ("wire 865 cutter") are almost impossible to avoid. 867 In addition, this protocol is vulnerable to Denial of Service 868 attacks because an attacker can force the server to go through the 869 CPU and memory intensive tasks of connection setup and key 870 exchange without authenticating. Implementors SHOULD provide 871 features that make this more difficult. For example, only 872 allowing connections from a subset of IPs known to have valid 873 users. 875 8.2.6 Covert Channels 877 The protocol was not designed to eliminate covert channels. For 878 example, the padding, SSH_MSG_IGNORE messages, and several other 879 places in the protocol can be used to pass covert information, and 880 the recipient has no reliable way to verify whether such 881 information is being sent. 883 8.2.7 Forward Secrecy 885 It should be noted that the Diffie-Hellman key exchanges may 886 provide perfect forward secrecy (PFS). PFS is essentially defined 887 as the cryptographic property of a key-establishment protocol in 888 which the compromise of a session key or long-term private key 889 after a given session does not cause the compromise of any earlier 890 session. [ANSI T1.523-2001] SSHv2 sessions resulting from a key 891 exchange using diffie-hellman-group1-sha1 are secure even if 892 private keying/authentication material is later revealed, but not 893 if the session keys are revealed. So, given this definition of 894 PFS, SSHv2 does have PFS. It is hoped that all other key exchange 895 mechanisms proposed and used in the future will also provide PFS. 896 This property is not commuted to any of the applications or 897 protocols using SSH as a transport however. The transport layer 898 of SSH provides confidentiality for password authentication and 899 other methods that rely on secret data. 901 Of course, if the DH private parameters for the client and server 902 are revealed then the session key is revealed, but these items can 903 be thrown away after the key exchange completes. It's worth 904 pointing out that these items should not be allowed to end up on 905 swap space and that they should be erased from memory as soon as 906 the key exchange completes. 908 8.3 Authentication Protocol 910 The purpose of this protocol is to perform client user 911 authentication. It assumes that this run over a secure transport 912 layer protocol, which has already authenticated the server 913 machine, established an encrypted communications channel, and 914 computed a unique session identifier for this session. 916 Several authentication methods with different security 917 characteristics are allowed. It is up to the server's local 918 policy to decide which methods (or combinations of methods) it is 919 willing to accept for each user. Authentication is no stronger 920 than the weakest combination allowed. 922 The server may go into a "sleep" period after repeated 923 unsuccessful authentication attempts to make key search more 924 difficult for attackers. Care should be taken so that this 925 doesn't become a self-denial of service vector. 927 8.3.1 Weak Transport 929 If the transport layer does not provide confidentiality, 930 authentication methods that rely on secret data SHOULD be 931 disabled. If it does not provide strong integrity protection, 932 requests to change authentication data (e.g. a password change) 933 SHOULD be disabled to prevent an attacker from modifying the 934 ciphertext without being noticed, or rendering the new 935 authentication data unusable (denial of service). 937 The assumption as stated above that the Authentication Protocol 938 only run over a secure transport that has previously authenticated 939 the server is very important to note. People deploying SSH are 940 reminded of the consequences of man-in-the-middle attacks if the 941 client does not have a very strong a priori association of the 942 server with the host key of that server. Specifically for the 943 case of the Authentication Protocol the client may form a session 944 to a man-in-the-middle attack device and divulge user credentials 945 such as their username and password. Even in the cases of 946 authentication where no user credentials are divulged, an attacker 947 may still gain information they shouldn't have by capturing key- 948 strokes in much the same way that a honeypot works. 950 8.3.2 Debug messages 952 Special care should be taken when designing debug messages. These 953 messages may reveal surprising amounts of information about the 954 host if not properly designed. Debug messages can be disabled 955 (during user authentication phase) if high security is required. 956 Administrators of host machines should make all attempts to 957 compartmentalize all event notification messages and protect them 958 from unwarranted observation. Developers should be aware of the 959 sensitive nature of some of the normal event messages and debug 960 messages and may want to provide guidance to administrators on 961 ways to keep this information away from unauthorized people. 962 Developers should consider minimizing the amount of sensitive 963 information obtainable by users during the authentication phase in 964 accordance with the local policies. For this reason, it is 965 RECOMMENDED that debug messages be initially disabled at the time 966 of deployment and require an active decision by an administrator 967 to allow them to be enabled. It is also RECOMMENDED that a 968 message expressing this concern be presented to the administrator 969 of a system when the action is taken to enable debugging messages. 971 8.3.3 Local security policy 973 Implementer MUST ensure that the credentials provided validate the 974 professed user and also MUST ensure that the local policy of the 975 server permits the user the access requested. In particular, 976 because of the flexible nature of the SSH connection protocol, it 977 may not be possible to determine the local security policy, if 978 any, that should apply at the time of authentication because the 979 kind of service being requested is not clear at that instant. For 980 example, local policy might allow a user to access files on the 981 server, but not start an interactive shell. However, during the 982 authentication protocol, it is not known whether the user will be 983 accessing files or attempting to use an interactive shell, or even 984 both. In any event, where local security policy for the server 985 host exists, it MUST be applied and enforced correctly. 987 Implementors are encouraged to provide a default local policy and 988 make its parameters known to administrators and users. At the 989 discretion of the implementors, this default policy may be along 990 the lines of 'anything goes' where there are no restrictions 991 placed upon users, or it may be along the lines of 'excessively 992 restrictive' in which case the administrators will have to 993 actively make changes to this policy to meet their needs. 994 Alternatively, it may be some attempt at providing something 995 practical and immediately useful to the administrators of the 996 system so they don't have to put in much effort to get SSH 997 working. Whatever choice is made MUST be applied and enforced as 998 required above. 1000 8.3.4 Public key authentication 1002 The use of public-key authentication assumes that the client host 1003 has not been compromised. 1005 This risk can be mitigated by the use of passphrases on private 1006 keys; however, this is not an enforceable policy. The use of 1007 smartcards, or other technology to make passphrases an enforceable 1008 policy is suggested. 1010 The server could require both password and public-key 1011 authentication, however, this requires the client to expose its 1012 password to the server (see section on password authentication 1013 below.) 1015 8.3.5 Password authentication 1017 The password mechanism as specified in the authentication protocol 1018 assumes that the server has not been compromised. If the server 1019 has been compromised, using password authentication will reveal a 1020 valid username / password combination to the attacker, which may 1021 lead to further compromises. 1023 This vulnerability can be mitigated by using an alternative form 1024 of authentication. For example, public-key authentication makes 1025 no assumptions about security on the server. 1027 8.3.6 Host based authentication 1029 Host based authentication assumes that the client has not been 1030 compromised. There are no mitigating strategies, other than to 1031 use host based authentication in combination with another 1032 authentication method. 1034 8.4 Connection protocol 1036 8.4.1 End point security 1038 End point security is assumed by the connection protocol. If the 1039 server has been compromised, any terminal sessions, port 1040 forwarding, or systems accessed on the host are compromised. 1041 There are no mitigating factors for this. 1043 If the client end point has been compromised, and the server fails 1044 to stop the attacker at the authentication protocol, all services 1045 exposed (either as subsystems or through forwarding) will be 1046 vulnerable to attack. Implementors SHOULD provide mechanisms for 1047 administrators to control which services are exposed to limit the 1048 vulnerability of other services. 1050 These controls might include controlling which machines and ports 1051 can be target in 'port-forwarding' operations, which users are 1052 allowed to use interactive shell facilities, or which users are 1053 allowed to use exposed subsystems. 1055 8.4.2 Proxy forwarding 1057 The SSH connection protocol allows for proxy forwarding of other 1058 protocols such as SNMP, POP3, and HTTP. This may be a concern for 1059 network administrators who wish to control the access of certain 1060 applications by users located outside of their physical location. 1061 Essentially, the forwarding of these protocols may violate site 1062 specific security policies as they may be undetectably tunneled 1063 through a firewall. Implementors SHOULD provide an administrative 1064 mechanism to control the proxy forwarding functionality so that 1065 site specific security policies may be upheld. 1067 In addition, a reverse proxy forwarding functionality is 1068 available, which again can be used to bypass firewall controls. 1070 As indicated above, end-point security is assumed during proxy 1071 forwarding operations. Failure of end-point security will 1072 compromise all data passed over proxy forwarding. 1074 8.4.3 X11 forwarding 1076 Another form of proxy forwarding provided by the ssh connection 1077 protocol is the forwarding of the X11 protocol. If end-point 1078 security has been compromised, X11 forwarding may allow attacks 1079 against the X11 server. Users and administrators should, as a 1080 matter of course, use appropriate X11 security mechanisms to 1081 prevent unauthorized use of the X11 server. Implementors, 1082 administrators and users who wish to further explore the security 1083 mechanisms of X11 are invited to read [SCHEIFLER] and analyze 1084 previously reported problems with the interactions between SSH 1085 forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 1086 [CERT]. 1088 X11 display forwarding with SSH, by itself, is not sufficient to 1089 correct well known problems with X11 security [VENEMA]. However, 1090 X11 display forwarding in SSHv2 (or other, secure protocols), 1091 combined with actual and pseudo-displays which accept connections 1092 only over local IPC mechanisms authorized by permissions or ACLs, 1093 does correct many X11 security problems as long as the "none" MAC 1094 is not used. It is RECOMMENDED that X11 display implementations 1095 default to allowing display opens only over local IPC. It is 1096 RECOMMENDED that SSHv2 server implementations that support X11 1097 forwarding default to allowing display opens only over local IPC. 1098 On single-user systems it might be reasonable to default to 1099 allowing local display opens over TCP/IP. 1101 Implementors of the X11 forwarding protocol SHOULD implement the 1102 magic cookie access checking spoofing mechanism as described in 1103 [ssh-connect] as an additional mechanism to prevent unauthorized 1104 use of the proxy. 1106 9. Intellectual Property 1108 The IETF takes no position regarding the validity or scope of any 1109 intellectual property or other rights that might be claimed to 1110 pertain to the implementation or use of the technology described 1111 in this document or the extent to which any license under such 1112 rights might or might not be available; neither does it represent 1113 that it has made any effort to identify any such rights. 1114 Information on the IETF's procedures with respect to rights in 1115 standards-track and standards-related documentation can be found 1116 in BCP-11. Copies of claims of rights made available for 1117 publication and any assurances of licenses to be made available, 1118 or the result of an attempt made to obtain a general license or 1119 permission for the use of such proprietary rights by implementers 1120 or users of this specification can be obtained from the IETF 1121 Secretariat. 1123 The IETF has been notified of intellectual property rights claimed 1124 in regard to some or all of the specification contained in this 1125 document. For more information consult the online list of claimed 1126 rights. 1128 10. Additional Information 1130 The current document editor is: Darren.Moffat@Sun.COM. Comments 1131 on this internet draft should be sent to the IETF SECSH working 1132 group, details at: http://ietf.org/html.charters/secsh- 1133 charter.html 1135 References 1137 [FIPS-186] Federal Information Processing 1138 Standards Publication, ., "FIPS PUB 1139 186, Digital Signature Standard", May 1140 1994. 1142 [FIPS-197] National Institue of Standards and 1143 Technology, ., "FIPS 197, 1144 Specification for the Advanced 1145 Encryption Standard", November 2001. 1147 [ANSI T1.523-2001] American National Standards Insitute, 1148 Inc., "Telecom Glossary 2000", 1149 February 2001. 1151 [SCHEIFLER] Scheifler, R., "X Window System : The 1152 Complete Reference to Xlib, X 1153 Protocol, Icccm, Xlfd, 3rd edition.", 1154 Digital Press ISBN 1555580882, 1155 Feburary 1992. 1157 [RFC0854] Postel, J. and J. Reynolds, "Telnet 1158 Protocol Specification", STD 8, RFC 1159 854, May 1983. 1161 [RFC0894] Hornig, C., "Standard for the 1162 transmission of IP datagrams over 1163 Ethernet networks", STD 41, RFC 894, 1164 Apr 1984. 1166 [RFC1034] Mockapetris, P., "Domain names - 1167 concepts and facilities", STD 13, RFC 1168 1034, Nov 1987. 1170 [RFC1134] Perkins, D., "Point-to-Point Protocol: 1171 A proposal for multi-protocol 1172 transmission of datagrams over Point- 1173 to-Point links", RFC 1134, Nov 1989. 1175 [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, 1176 December 1991. 1178 [RFC1510] Kohl, J. and C. Neuman, "The Kerberos 1179 Network Authentication Service (V5)", 1180 RFC 1510, September 1993. 1182 [RFC1700] Reynolds, J. and J. Postel, "Assigned 1183 Numbers", STD 2, RFC 1700, October 1184 1994. 1186 [RFC1750] Eastlake, D., Crocker, S. and J. 1187 Schiller, "Randomness Recommendations 1188 for Security", RFC 1750, December 1189 1994. 1191 [RFC1766] Alvestrand, H., "Tags for the 1192 Identification of Languages", RFC 1193 1766, March 1995. 1195 [RFC1964] Linn, J., "The Kerberos Version 5 GSS- 1196 API Mechanism", RFC 1964, June 1996. 1198 [RFC2025] Adams, C., "The Simple Public-Key GSS- 1199 API Mechanism (SPKM)", RFC 2025, 1200 October 1996. 1202 [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP 1203 Authentication with Replay 1204 Prevention", RFC 2085, February 1997. 1206 [RFC2104] Krawczyk, H., Bellare, M. and R. 1208 Canetti, "HMAC: Keyed-Hashing for 1209 Message Authentication", RFC 2104, 1210 February 1997. 1212 [RFC2119] Bradner, S., "Key words for use in 1213 RFCs to Indicate Requirement Levels", 1214 BCP 14, RFC 2119, March 1997. 1216 [RFC2246] Dierks, T. and C. Allen, "The TLS 1217 Protocol Version 1.0", RFC 2246, 1218 January 1999. 1220 [RFC2279] Yergeau, F., "UTF-8, a transformation 1221 format of ISO 10646", RFC 2279, 1222 January 1998. 1224 [RFC2410] Glenn, R. and S. Kent, "The NULL 1225 Encryption Algorithm and Its Use With 1226 IPsec", RFC 2410, November 1998. 1228 [RFC2434] Narten, T. and H. Alvestrand, 1229 "Guidelines for Writing an IANA 1230 Considerations Section in RFCs", BCP 1231 26, RFC 2434, October 1998. 1233 [RFC2743] Linn, J., "Generic Security Service 1234 Application Program Interface Version 1235 2, Update 1", RFC 2743, January 2000. 1237 [SSH-ARCH] Ylonen, T., "SSH Protocol 1238 Architecture", I-D draft-ietf- 1239 architecture-14.txt, July 2003. 1241 [SSH-TRANS] Ylonen, T., "SSH Transport Layer 1242 Protocol", I-D draft-ietf-transport- 1243 16.txt, July 2003. 1245 [SSH-USERAUTH] Ylonen, T., "SSH Authentication 1246 Protocol", I-D draft-ietf-userauth- 1247 17.txt, July 2003. 1249 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", 1250 I-D draft-ietf-connect-17.txt, July 1251 2003. 1253 [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH 1254 Protocol Assigned Numbers", I-D draft- 1255 ietf-secsh-assignednumbers-03.txt, 1256 July 2003. 1258 [SCHNEIER] Schneier, B., "Applied Cryptography 1259 Second Edition: protocols algorithms 1260 and source in code in C", 1996. 1262 [KAUFMAN,PERLMAN,SPECINER] Kaufman, C., Perlman, R. and M. 1263 Speciner, "Network Security: PRIVATE 1264 Communication in a PUBLIC World", 1265 1995. 1267 [CERT] CERT Coordination Center, The., 1268 "http://www.cert.org/nav/index_red.html" 1269 . 1271 [VENEMA] Venema, W., "Murphy's Law and Computer 1272 Security", Proceedings of 6th USENIX 1273 Security Symposium, San Jose CA 1274 http://www.usenix.org/publications/library/proceedings/sec96/venema.html 1275 , July 1996. 1277 [ROGAWAY] Rogaway, P., "Problems with Proposed 1278 IP Cryptography", Unpublished paper 1279 http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt 1280 , 1996. 1282 [DAI] Dai, W., "An attack against SSH2 1283 protocol", Email to the SECSH Working 1284 Group ietf-ssh@netbsd.org 1285 ftp://ftp.ietf.org/ietf-mail- 1286 archive/secsh/2002-02.mail, Feb 2002. 1288 [BELLARE,KOHNO,NAMPREMPRE] Bellaire, M., Kohno, T. and C. 1289 Namprempre, "Authenticated Encryption 1290 in SSH: Fixing the SSH Binary Packet 1291 Protocol", , Sept 2002. 1293 Authors' Addresses 1295 Tatu Ylonen 1296 SSH Communications Security Corp 1297 Fredrikinkatu 42 1298 HELSINKI FIN-00100 1299 Finland 1301 EMail: ylo@ssh.com 1302 Tero Kivinen 1303 SSH Communications Security Corp 1304 Fredrikinkatu 42 1305 HELSINKI FIN-00100 1306 Finland 1308 EMail: kivinen@ssh.com 1310 Markku-Juhani O. Saarinen 1311 University of Jyvaskyla 1313 Timo J. Rinne 1314 SSH Communications Security Corp 1315 Fredrikinkatu 42 1316 HELSINKI FIN-00100 1317 Finland 1319 EMail: tri@ssh.com 1321 Sami Lehtinen 1322 SSH Communications Security Corp 1323 Fredrikinkatu 42 1324 HELSINKI FIN-00100 1325 Finland 1327 EMail: sjl@ssh.com 1329 Full Copyright Statement 1331 Copyright (C) The Internet Society (2003). All Rights Reserved. 1333 This document and translations of it may be copied and furnished 1334 to others, and derivative works that comment on or otherwise 1335 explain it or assist in its implementation may be prepared, 1336 copied, published and distributed, in whole or in part, without 1337 restriction of any kind, provided that the above copyright notice 1338 and this paragraph are included on all such copies and derivative 1339 works. However, this document itself may not be modified in any 1340 way, such as by removing the copyright notice or references to the 1341 Internet Society or other Internet organizations, except as needed 1342 for the purpose of developing Internet standards in which case the 1343 procedures for copyrights defined in the Internet Standards 1344 process must be followed, or as required to translate it into 1345 languages other than English. 1347 The limited permissions granted above are perpetual and will not 1348 be revoked by the Internet Society or its successors or assigns. 1350 This document and the information contained herein is provided on 1351 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1352 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1353 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1354 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1357 Acknowledgement 1359 Funding for the RFC Editor function is currently provided by the 1360 Internet Society.