idnits 2.17.1 draft-ietf-secsh-architecture-11.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2001) is 8165 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: 'RFC-2119' is mentioned on line 112, but not defined == Missing Reference: 'RFC-854' is mentioned on line 156, but not defined == Missing Reference: 'RFC-1282' is mentioned on line 157, but not defined == Missing Reference: 'RFC-894' is mentioned on line 269, but not defined == Missing Reference: 'RFC-1134' is mentioned on line 277, but not defined ** Obsolete undefined reference: RFC 1134 (Obsoleted by RFC 1171) == Missing Reference: 'RFC-2279' is mentioned on line 294, but not defined ** Obsolete undefined reference: RFC 2279 (Obsoleted by RFC 3629) == Missing Reference: 'RFC-1766' is mentioned on line 405, but not defined ** Obsolete undefined reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) == Missing Reference: 'RFC-1700' is mentioned on line 333, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Missing Reference: 'RFC-1034' is mentioned on line 443, but not defined == Missing Reference: 'RFC-2343' is mentioned on line 496, but not defined == Missing Reference: 'RFC-1750' is mentioned on line 512, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'RFC0854' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC0894' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC1134' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC1282' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'SSH-ARCH' is defined on line 578, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' ** Obsolete normative reference: RFC 1134 (Obsoleted by RFC 1171) ** Downref: Normative reference to an Informational RFC: RFC 1282 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- No information found for draft-ietf-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-ARCH' -- No information found for draft-ietf-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' -- No information found for draft-ietf-userauth - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-USERAUTH' -- No information found for draft-ietf-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' Summary: 15 errors (**), 0 flaws (~~), 26 warnings (==), 11 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: May 20, 2002 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 November 19, 2001 12 SSH Protocol Architecture 13 draft-ietf-secsh-architecture-11.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 months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 20, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). All Rights Reserved. 42 Abstract 44 SSH is a protocol for secure remote login and other secure network 45 services over an insecure network. This document describes the 46 architecture of the SSH protocol, as well as the notation and 47 terminology used in SSH protocol documents. It also discusses the 48 SSH algorithm naming system that allows local extensions. The SSH 49 protocol consists of three major components: The Transport Layer 50 Protocol provides server authentication, confidentiality, and 51 integrity with perfect forward secrecy. The User Authentication 52 Protocol authenticates the client to the server. The Connection 53 Protocol multiplexes the encrypted tunnel into several logical 54 channels. Details of these protocols are described in separate 55 documents. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4 Security Properties . . . . . . . . . . . . . . . . . . . . . 6 66 3.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . . 6 67 3.6 Localization and Character Set Support . . . . . . . . . . . . 7 68 4. Data Type Representations Used in the SSH Protocols . . . . . 8 69 5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 10 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 12 74 10. Additional Information . . . . . . . . . . . . . . . . . . . . 12 75 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 77 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 SSH is a protocol for secure remote login and other secure network 82 services over an insecure network. It consists of three major 83 components: 84 o The Transport Layer Protocol [SSH-TRANS] provides server 85 authentication, confidentiality, and integrity. It may optionally 86 also provide compression. The transport layer will typically be 87 run over a TCP/IP connection, but might also be used on top of any 88 other reliable data stream. 89 o The User Authentication Protocol [SSH-USERAUTH] authenticates the 90 client-side user to the server. It runs over the transport layer 91 protocol. 92 o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted 93 tunnel into several logical channels. It runs over the user 94 authentication protocol. 96 The client sends a service request once a secure transport layer 97 connection has been established. A second service request is sent 98 after user authentication is complete. This allows new protocols to 99 be defined and coexist with the protocols listed above. 101 The connection protocol provides channels that can be used for a wide 102 range of purposes. Standard methods are provided for setting up 103 secure interactive shell sessions and for forwarding ("tunneling") 104 arbitrary TCP/IP ports and X11 connections. 106 2. Specification of Requirements 108 All documents related to the SSH protocols shall use the keywords 109 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 110 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 111 requirements. They are to be interpreted as described in [RFC-2119]. 113 3. Architecture 115 3.1 Host Keys 117 Each server host SHOULD have a host key. Hosts MAY have multiple 118 host keys using multiple different algorithms. Multiple hosts MAY 119 share the same host key. If a host has keys at all, it MUST have at 120 least one key using each REQUIRED public key algorithm (currently DSS 121 [FIPS-186]). 123 The server host key is used during key exchange to verify that the 124 client is really talking to the correct server. For this to be 125 possible, the client must have a priori knowledge of the server's 126 public host key. 128 Two different trust models can be used: 129 o The client has a local database that associates each host name (as 130 typed by the user) with the corresponding public host key. This 131 method requires no centrally administered infrastructure, and no 132 third-party coordination. The downside is that the database of 133 name-to-key associations may become burdensome to maintain. 134 o The host name-to-key association is certified by some trusted 135 certification authority. The client only knows the CA root key, 136 and can verify the validity of all host keys certified by accepted 137 CAs. 139 The second alternative eases the maintenance problem, since 140 ideally only a single CA key needs to be securely stored on the 141 client. On the other hand, each host key must be appropriately 142 certified by a central authority before authorization is possible. 143 Also, a lot of trust is placed on the central infrastructure. 145 The protocol provides the option that the server name - host key 146 association is not checked when connecting to the host for the first 147 time. This allows communication without prior communication of host 148 keys or certification. The connection still provides protection 149 against passive listening; however, it becomes vulnerable to active 150 man-in-the-middle attacks. Implementations SHOULD NOT normally allow 151 such connections by default, as they pose a potential security 152 problem. However, as there is no widely deployed key infrastructure 153 available on the Internet yet, this option makes the protocol much 154 more usable during the transition time until such an infrastructure 155 emerges, while still providing a much higher level of security than 156 that offered by older solutions (e.g. telnet [RFC-854] and rlogin 157 [RFC-1282]). 159 Implementations SHOULD try to make the best effort to check host 160 keys. An example of a possible strategy is to only accept a host key 161 without checking the first time a host is connected, save the key in 162 a local database, and compare against that key on all future 163 connections to that host. 165 Implementations MAY provide additional methods for verifying the 166 correctness of host keys, e.g. a hexadecimal fingerprint derived 167 from the SHA-1 hash of the public key. Such fingerprints can easily 168 be verified by using telephone or other external communication 169 channels. 171 All implementations SHOULD provide an option to not accept host keys 172 that cannot be verified. 174 We believe that ease of use is critical to end-user acceptance of 175 security solutions, and no improvement in security is gained if the 176 new solutions are not used. Thus, providing the option not to check 177 the server host key is believed to improve the overall security of 178 the Internet, even though it reduces the security of the protocol in 179 configurations where it is allowed. 181 3.2 Extensibility 183 We believe that the protocol will evolve over time, and some 184 organizations will want to use their own encryption, authentication 185 and/or key exchange methods. Central registration of all extensions 186 is cumbersome, especially for experimental or classified features. 187 On the other hand, having no central registration leads to conflicts 188 in method identifiers, making interoperability difficult. 190 We have chosen to identify algorithms, methods, formats, and 191 extension protocols with textual names that are of a specific format. 192 DNS names are used to create local namespaces where experimental or 193 classified extensions can be defined without fear of conflicts with 194 other implementations. 196 One design goal has been to keep the base protocol as simple as 197 possible, and to require as few algorithms as possible. However, all 198 implementations MUST support a minimal set of algorithms to ensure 199 interoperability (this does not imply that the local policy on all 200 hosts would necessary allow these algorithms). The mandatory 201 algorithms are specified in the relevant protocol documents. 203 Additional algorithms, methods, formats, and extension protocols can 204 be defined in separate drafts. See Section Algorithm Naming (Section 205 5) for more information. 207 3.3 Policy Issues 209 The protocol allows full negotiation of encryption, integrity, key 210 exchange, compression, and public key algorithms and formats. 211 Encryption, integrity, public key, and compression algorithms can be 212 different for each direction. 214 The following policy issues SHOULD be addressed in the configuration 215 mechanisms of each implementation: 216 o Encryption, integrity, and compression algorithms, separately for 217 each direction. The policy MUST specify which is the preferred 218 algorithm (e.g. the first algorithm listed in each category). 219 o Public key algorithms and key exchange method to be used for host 220 authentication. The existence of trusted host keys for different 221 public key algorithms also affects this choice. 222 o The authentication methods that are to be required by the server 223 for each user. The server's policy MAY require multiple 224 authentication for some or all users. The required algorithms MAY 225 depend on the location where the user is trying to log in from. 226 o The operations that the user is allowed to perform using the 227 connection protocol. Some issues are related to security; for 228 example, the policy SHOULD NOT allow the server to start sessions 229 or run commands on the client machine, and MUST NOT allow 230 connections to the authentication agent unless forwarding such 231 connections has been requested. Other issues, such as which 232 TCP/IP ports can be forwarded and by whom, are clearly issues of 233 local policy. Many of these issues may involve traversing or 234 bypassing firewalls, and are interrelated with the local security 235 policy. 237 3.4 Security Properties 239 The primary goal of the SSH protocol is improved security on the 240 Internet. It attempts to do this in a way that is easy to deploy, 241 even at the cost of absolute security. 242 o All encryption, integrity, and public key algorithms used are 243 well-known, well-established algorithms. 244 o All algorithms are used with cryptographically sound key sizes 245 that are believed to provide protection against even the strongest 246 cryptanalytic attacks for decades. 247 o All algorithms are negotiated, and in case some algorithm is 248 broken, it is easy to switch to some other algorithm without 249 modifying the base protocol. 251 Specific concessions were made to make wide-spread fast deployment 252 easier. The particular case where this comes up is verifying that 253 the server host key really belongs to the desired host; the protocol 254 allows the verification to be left out (but this is NOT RECOMMENDED). 255 This is believed to significantly improve usability in the short 256 term, until widespread Internet public key infrastructures emerge. 258 3.5 Packet Size and Overhead 260 Some readers will worry about the increase in packet size due to new 261 headers, padding, and MAC. The minimum packet size is in the order 262 of 28 bytes (depending on negotiated algorithms). The increase is 263 negligible for large packets, but very significant for one-byte 264 packets (telnet-type sessions). There are, however, several factors 265 that make this a non-issue in almost all cases: 266 o The minimum size of a TCP/IP header is 32 bytes. Thus, the 267 increase is actually from 33 to 51 bytes (roughly). 268 o The minimum size of the data field of an Ethernet packet is 46 269 bytes [RFC-894]. Thus, the increase is no more than 5 bytes. 270 When Ethernet headers are considered, the increase is less than 10 271 percent. 273 o The total fraction of telnet-type data in the Internet is 274 negligible, even with increased packet sizes. 276 The only environment where the packet size increase is likely to have 277 a significant effect is PPP [RFC-1134] over slow modem lines (PPP 278 compresses the TCP/IP headers, emphasizing the increase in packet 279 size). However, with modern modems, the time needed to transfer is 280 in the order of 2 milliseconds, which is a lot faster than people can 281 type. 283 There are also issues related to the maximum packet size. To 284 minimize delays in screen updates, one does not want excessively 285 large packets for interactive sessions. The maximum packet size is 286 negotiated separately for each channel. 288 3.6 Localization and Character Set Support 290 For the most part, the SSH protocols do not directly pass text that 291 would be displayed to the user. However, there are some places where 292 such data might be passed. When applicable, the character set for 293 the data MUST be explicitly specified. In most places, ISO 10646 294 with UTF-8 encoding is used [RFC-2279]. When applicable, a field is 295 also provided for a language tag [RFC-1766]. 297 One big issue is the character set of the interactive session. There 298 is no clear solution, as different applications may display data in 299 different formats. Different types of terminal emulation may also be 300 employed in the client, and the character set to be used is 301 effectively determined by the terminal emulation. Thus, no place is 302 provided for directly specifying the character set or encoding for 303 terminal session data. However, the terminal emulation type (e.g. 304 "vt100") is transmitted to the remote site, and it implicitly 305 specifies the character set and encoding. Applications typically use 306 the terminal type to determine what character set they use, or the 307 character set is determined using some external means. The terminal 308 emulation may also allow configuring the default character set. In 309 any case, the character set for the terminal session is considered 310 primarily a client local issue. 312 Internal names used to identify algorithms or protocols are normally 313 never displayed to users, and must be in US-ASCII. 315 The client and server user names are inherently constrained by what 316 the server is prepared to accept. They might, however, occasionally 317 be displayed in logs, reports, etc. They MUST be encoded using ISO 318 10646 UTF-8, but other encodings may be required in some cases. It 319 is up to the server to decide how to map user names to accepted user 320 names. Straight bit-wise binary comparison is RECOMMENDED. 322 For localization purposes, the protocol attempts to minimize the 323 number of textual messages transmitted. When present, such messages 324 typically relate to errors, debugging information, or some externally 325 configured data. For data that is normally displayed, it SHOULD be 326 possible to fetch a localized message instead of the transmitted 327 message by using a numerical code. The remaining messages SHOULD be 328 configurable. 330 4. Data Type Representations Used in the SSH Protocols 331 byte 333 A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. 334 Fixed length data is sometimes represented as an array of bytes, 335 written byte[n], where n is the number of bytes in the array. 337 boolean 339 A boolean value is stored as a single byte. The value 0 340 represents FALSE, and the value 1 represents TRUE. All non-zero 341 values MUST be interpreted as TRUE; however, applications MUST NOT 342 store values other than 0 and 1. 344 uint32 346 Represents a 32-bit unsigned integer. Stored as four bytes in the 347 order of decreasing significance (network byte order). For 348 example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 349 aa. 351 uint64 353 Represents a 64-bit unsigned integer. Stored as eight bytes in 354 the order of decreasing significance (network byte order). 356 string 358 Arbitrary length binary string. Strings are allowed to contain 359 arbitrary binary data, including null characters and 8-bit 360 characters. They are stored as a uint32 containing its length 361 (number of bytes that follow) and zero (= empty string) or more 362 bytes that are the value of the string. Terminating null 363 characters are not used. 365 Strings are also used to store text. In that case, US-ASCII is 366 used for internal names, and ISO-10646 UTF-8 for text that might 367 be displayed to the user. The terminating null character SHOULD 368 NOT normally be stored in the string. 370 For example, the US-ASCII string "testing" is represented as 00 00 371 00 07 t e s t i n g. The UTF8 mapping does not alter the encoding 372 of US-ASCII characters. 374 mpint 376 Represents multiple precision integers in two's complement format, 377 stored as a string, 8 bits per byte, MSB first. Negative numbers 378 have the value 1 as the most significant bit of the first byte of 379 the data partition. If the most significant bit would be set for 380 a positive number, the number MUST be preceded by a zero byte. 381 Unnecessary leading bytes with the value 0 or 255 MUST NOT be 382 included. The value zero MUST be stored as a string with zero 383 bytes of data. 385 By convention, a number that is used in modular computations in 386 Z_n SHOULD be represented in the range 0 <= x < n. 388 Examples: 389 value (hex) representation (hex) 390 --------------------------------------------------------------- 391 0 00 00 00 00 392 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 393 80 00 00 00 02 00 80 394 -1234 00 00 00 02 ed cc 395 -deadbeef 00 00 00 05 ff 21 52 41 11 397 name-list 399 A string containing a comma separated list of names. A name list 400 is represented as a uint32 containing its length (number of bytes 401 that follow) followed by a comma-separated list of zero or more 402 names. A name MUST be non-zero length, and it MUST NOT contain a 403 comma (','). Context may impose additional restrictions on the 404 names; for example, the names in a list may have to be valid 405 algorithm identifier (see Algorithm Naming below), or [RFC-1766] 406 language tags. The order of the names in a list may or may not be 407 significant, also depending on the context where the list is is 408 used. Terminating NUL characters are not used, neither for the 409 individual names, nor for the list as a whole. 411 Examples: 412 value representation (hex) 413 --------------------------------------- 414 (), the empty list 00 00 00 00 415 ("zlib") 00 00 00 04 7a 6c 69 62 416 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 418 5. Algorithm Naming 420 The SSH protocols refer to particular hash, encryption, integrity, 421 compression, and key exchange algorithms or protocols by names. 422 There are some standard algorithms that all implementations MUST 423 support. There are also algorithms that are defined in the protocol 424 specification but are OPTIONAL. Furthermore, it is expected that 425 some organizations will want to use their own algorithms. 427 In this protocol, all algorithm identifiers MUST be printable US- 428 ASCII non-empty strings no longer than 64 characters. Names MUST be 429 case-sensitive. 431 There are two formats for algorithm names: 432 o Names that do not contain an at-sign (@) are reserved to be 433 assigned by IETF consensus (RFCs). Examples include `3des-cbc', 434 `sha-1', `hmac-sha1', and `zlib' (the quotes are not part of the 435 name). Names of this format MUST NOT be used without first 436 registering them. Registered names MUST NOT contain an at-sign 437 (@) or a comma (,). 438 o Anyone can define additional algorithms by using names in the 439 format name@domainname, e.g. "ourcipher-cbc@ssh.com". The format 440 of the part preceding the at sign is not specified; it MUST 441 consist of US-ASCII characters except at-sign and comma. The part 442 following the at-sign MUST be a valid fully qualified internet 443 domain name [RFC-1034] controlled by the person or organization 444 defining the name. It is up to each domain how it manages its 445 local namespace. 447 6. Message Numbers 449 SSH packets have message numbers in the range 1 to 255. These 450 numbers have been allocated as follows: 452 Transport layer protocol: 454 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, 455 etc.) 456 20 to 29 Algorithm negotiation 457 30 to 49 Key exchange method specific (numbers can be reused for 458 different authentication methods) 460 User authentication protocol: 462 50 to 59 User authentication generic 463 60 to 79 User authentication method specific (numbers can be 464 reused for different authentication methods) 466 Connection protocol: 468 80 to 89 Connection protocol generic 469 90 to 127 Channel related messages 471 Reserved for client protocols: 473 128 to 191 Reserved 475 Local extensions: 477 192 to 255 Local extensions 479 7. IANA Considerations 481 Allocation of the following types of names in the SSH protocols is 482 assigned by IETF consensus: 483 o encryption algorithm names, 484 o MAC algorithm names, 485 o public key algorithm names (public key algorithm also implies 486 encoding and signature/encryption capability), 487 o key exchange method names, and 488 o protocol (service) names. 490 These names MUST be printable US-ASCII strings, and MUST NOT contain 491 the characters at-sign ('@'), comma (','), or whitespace or control 492 characters (ASCII codes 32 or less). Names are case-sensitive, and 493 MUST NOT be longer than 64 characters. 495 Names with the at-sign ('@') in them are allocated by the owner of 496 DNS name after the at-sign (hierarchical allocation in [RFC-2343]), 497 otherwise the same restrictions as above. 499 Each category of names listed above has a separate namespace. 500 However, using the same name in multiple categories SHOULD be avoided 501 to minimize confusion. 503 Message numbers (see Section Message Numbers (Section 6)) in the 504 range of 0..191 should be allocated via IETF consensus; message 505 numbers in the 192..255 range (the "Local extensions" set) are 506 reserved for private use. 508 8. Security Considerations 510 Special care should be taken to ensure that all of the random numbers 511 are of good quality. The random numbers SHOULD be produced with safe 512 mechanisms discussed in [RFC-1750]. 514 When displaying text, such as error or debug messages to the user, 515 the client software SHOULD replace any control characters (except 516 tab, carriage return and newline) with safe sequences to avoid 517 attacks by sending terminal control characters. 519 Not using MAC or encryption SHOULD be avoided. The user 520 authentication protocol is subject to man-in-the-middle attacks if 521 the encryption is disabled. The SSH protocol does not protect 522 against message alteration if no MAC is used. 524 9. Trademark Issues 526 As of this writing, SSH Communications Security Oy claims ssh as its 527 trademark. As with all IPR claims the IETF takes no position 528 regarding the validity or scope of this trademark claim. 530 10. Additional Information 532 The current document editor is: Darren.Moffat@Sun.COM. Comments on 533 this internet draft should be sent to the IETF SECSH working group, 534 details at: http://ietf.org/html.charters/secsh-charter.html 536 References 538 [FIPS-186] Federal Information Processing Standards Publication, 539 ., "FIPS PUB 186, Digital Signature Standard", May 540 1994. 542 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 543 Specification", STD 8, RFC 854, May 1983. 545 [RFC0894] Hornig, C., "Standard for the transmission of IP 546 datagrams over Ethernet networks", STD 41, RFC 894, 547 Apr 1984. 549 [RFC1034] Mockapetris, P., "Domain names - concepts and 550 facilities", STD 13, RFC 1034, Nov 1987. 552 [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for 553 multi-protocol transmission of datagrams over Point- 554 to-Point links", RFC 1134, Nov 1989. 556 [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. 558 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 559 2, RFC 1700, October 1994. 561 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, 562 "Randomness Recommendations for Security", RFC 1750, 563 December 1994. 565 [RFC1766] Alvestrand, H., "Tags for the Identification of 566 Languages", RFC 1766, March 1995. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 572 10646", RFC 2279, January 1998. 574 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 575 an IANA Considerations Section in RFCs", BCP 26, RFC 576 2434, October 1998. 578 [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- 579 ietf-architecture-11.txt, July 2001. 581 [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D 582 draft-ietf-transport-11.txt, July 2001. 584 [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- 585 ietf-userauth-13.txt, July 2001. 587 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- 588 ietf-connect-13.txt, July 2001. 590 Authors' Addresses 592 Tatu Ylonen 593 SSH Communications Security Corp 594 Fredrikinkatu 42 595 HELSINKI FIN-00100 596 Finland 598 EMail: ylo@ssh.com 599 Tero Kivinen 600 SSH Communications Security Corp 601 Fredrikinkatu 42 602 HELSINKI FIN-00100 603 Finland 605 EMail: kivinen@ssh.com 607 Markku-Juhani O. Saarinen 608 University of Jyvaskyla 610 Timo J. Rinne 611 SSH Communications Security Corp 612 Fredrikinkatu 42 613 HELSINKI FIN-00100 614 Finland 616 EMail: tri@ssh.com 618 Sami Lehtinen 619 SSH Communications Security Corp 620 Fredrikinkatu 42 621 HELSINKI FIN-00100 622 Finland 624 EMail: sjl@ssh.com 626 Full Copyright Statement 628 Copyright (C) The Internet Society (2001). All Rights Reserved. 630 This document and translations of it may be copied and furnished to 631 others, and derivative works that comment on or otherwise explain it 632 or assist in its implementation may be prepared, copied, published 633 and distributed, in whole or in part, without restriction of any 634 kind, provided that the above copyright notice and this paragraph are 635 included on all such copies and derivative works. However, this 636 document itself may not be modified in any way, such as by removing 637 the copyright notice or references to the Internet Society or other 638 Internet organizations, except as needed for the purpose of 639 developing Internet standards in which case the procedures for 640 copyrights defined in the Internet Standards process must be 641 followed, or as required to translate it into languages other than 642 English. 644 The limited permissions granted above are perpetual and will not be 645 revoked by the Internet Society or its successors or assigns. 647 This document and the information contained herein is provided on an 648 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 649 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 650 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 651 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 652 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Acknowledgement 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society.