idnits 2.17.1 draft-ietf-secsh-architecture-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: boolean A boolean value is stored as a single byte. The value 0 represents false, and the value 1 represents true. All non-zero values MUST be interpreted as true; however, applications MUST not store values other than 0 and 1. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The IANA-allocated names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ascii codes 32 or less). Names are case-sensitive, and MUST not be longer than 64 characters. -- 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 (22 June 1999) is 9046 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: 'SSH-CONN' is mentioned on line 82, but not defined == Missing Reference: 'RFC1700' is mentioned on line 324, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Missing Reference: 'RFC-1884' is mentioned on line 386, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Missing Reference: 'RFC1750' is mentioned on line 480, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'RFC-1700' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC-1750' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 549, 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 2044 (Obsoleted by RFC 2279) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-06 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-06 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-06 Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ylonen 2 INTERNET-DRAFT T. Kivinen 3 draft-ietf-secsh-architecture-04.txt M. Saarinen 4 Expires in six months T. Rinne 5 S. Lehtinen 6 SSH 7 22 June 1999 9 SSH Protocol Architecture 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 SSH is a protocol for secure remote login and other secure network ser- 36 vices over an insecure network. This document describes the architecture 37 of the SSH protocol, and the notation and terminology used in SSH proto- 38 col documents. It also discusses the SSH algorithm naming system that 39 allows local extensions. The SSH protocol consists of three major com- 40 ponents: Transport layer protocol provides server authentication, confi- 41 dentiality, and integrity with perfect forward secrecy. User authentica- 42 tion protocol authenticates the client to the server. Connection proto- 43 col multiplexes the encrypted tunnel into several logical channels. 44 Details of these protocols are described in separate documents. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 50 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.3. Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.4. Security Properties . . . . . . . . . . . . . . . . . . . . 5 55 3.5. Packet Size and Overhead . . . . . . . . . . . . . . . . . . 5 56 3.6. Localization and Character Set Support . . . . . . . . . . . 6 57 4. Data Type Representations Used in the SSH Protocols . . . . . . 7 58 4.1. Encoding of Network Addresses . . . . . . . . . . . . . . . 8 59 5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 63 9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 SSH is a protocol for secure remote login and other secure network 70 services over an insecure network. It consists of three major 71 components: 73 o Transport layer protocol [SSH-TRANS] provides server authentication, 74 confidentiality, and integrity. It may optionally also provide 75 compression. The transport layer will typically be run over a TCP/IP 76 connection, but might also be used on top of any other reliable data 77 stream. 79 o User authentication protocol [SSH-USERAUTH] authenticates the client- 80 side user to the server. It runs over the transport layer protocol. 82 o Connection protocol [SSH-CONN] multiplexes the encrypted tunnel into 83 several logical channels. It runs over the user authentication 84 protocol. 86 The client sends a service request once a secure transport layer 87 connection has been established. A second service request is sent after 88 user authentication is complete. This allows new protocols to be defined 89 and coexist with the protocols listed above. 91 The connection protocol provides channels that can be used for a wide 92 range of purposes. Standard methods are provided for setting up secure 93 interactive shell sessions and for forwarding ("tunneling") arbitrary 94 TCP/IP ports and X11 connections. 96 2. Specification of Requirements 98 All of the documents related to the SSH protocols shall use the keywords 99 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 100 NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. 101 They are to be interpreted as described in [RFC-2119]. 103 3. Architecture 105 3.1. Host Keys 107 Each server host MUST have a host key. Hosts MAY have multiple host 108 keys using multiple different algorithms. Multiple hosts MAY share the 109 same host key. Every host MUST have at least one key using each REQUIRED 110 public key algorithm (currently DSS [FIPS-186]). 112 The server host key is used during key exchange to verify that the 113 client is really talking to the correct server. For this to be possible, 114 the client must have a priori knowledge of the server's public host key. 116 Two different trust models can be used: 118 o The client has a local database that associates each host name (as 119 typed by the user) with the corresponding public host key. This 120 method requires no centrally administered infrastructure, and no 121 third-party coordination. The downside is that the database of name- 122 key associations may become burdensome to maintain. 124 o The host name - key association is certified by some trusted 125 certification authority. The client only knows the CA root key, and 126 can verify the validity of all host keys certified by accepted CAs. 128 The second alternative eases the maintenance problem, since ideally 129 only a single CA key needs to be securely stored on the client. On 130 the other hand, each host key must be appropriately certified by a 131 central authority before authorization is possible. Also, a lot of 132 trust is placed on the central infrastructure. 134 The protocol provides the option that the server name - host key 135 association is not checked when connecting the host for the first time. 136 This allows communication without prior communication of host keys or 137 certification. The connection still provides protection against passive 138 listening; however, it becomes vulnerable to active man-in-the-middle 139 attacks. Implementations SHOULD NOT normally allow such connections by 140 default, as they pose a potential security problem. However, as there is 141 no widely deployed key infrastructure available on the Internet yet, 142 this option makes the protocol much more usable during the transition 143 time until such an infrastructure emerges, while still providing a much 144 higher level of security than that offered by older solutions (e.g. 145 telnet [RFC-854] and rlogin [RFC-1282]). 146 Implementations SHOULD try to make best effort to check host keys. An 147 example of a possible strategy is to only accept a host key without 148 checking the first time a host is connected, save the key in a local 149 database, and compare against that key on all future connections to that 150 host. 152 Implementations MAY provide additional methods for verifying the 153 correctness of host keys, e.g. a hexadecimal fingerprint derived from 154 the SHA-1 hash of the public key. Such fingerprints can easily be 155 verified by using telephone or other external communication channels. 157 All implementations SHOULD provide an option to not accept host keys 158 that cannot be verified. 160 We believe that ease of use is critical to end-user acceptance of 161 security solutions, and no improvement in security is gained if the new 162 solutions are not used. Thus, providing the option not to check the 163 the server host key is believed to improve overall security of the 164 Internet, even though it reduces the security of the protocol in 165 configurations where it is allowed. 167 3.2. Extensibility 169 We believe that the protocol will evolve over time, and some 170 organizations will want to use their own encryption, authentication 171 and/or key exchange methods. Central registration of all extensions is 172 cumbersome, especially for experimental or classified features. On the 173 other hand, having no central registration leads to conflicts in method 174 identifiers, making interoperability difficult. 176 We have chosen to identify algorithms, methods, formats, and extension 177 protocols with textual names that are of a specific format. DNS names 178 are used to create local namespaces where experimental or classified 179 extensions can be defined without fear of conflicts with other 180 implementations. 182 One design goal has been to keep the base protocol as simple as 183 possible, and to require as few algorithms as possible. However, all 184 implementations MUST support a minimal set of algorithms to ensure 185 interoperability (this does not imply that the local policy on all hosts 186 would necessary allow these algorithms). The mandatory algorithms are 187 specified in the relevant protocol documents. 189 Additional algorithms, methods, formats, and extension protocols can be 190 defined in separate drafts. See Section ``Algorithm Naming'' for more 191 information. 193 3.3. Policy Issues 195 The protocol allows full negotiation of encryption, integrity, key 196 exchange, compression, and public key algorithms and formats. 197 Encryption, integrity, public key, and compression algorithms can be 198 different for each direction. 200 The following policy issues SHOULD be addressed in the configuration 201 mechanisms of each implementation: 203 o Encryption, integrity, and compression algorithms, separately for 204 each direction. The policy MUST specify which is the preferred 205 algorithm (e.g. the first algorithm listed in each category). 207 o Public key algorithms and key exchange method to be used for host 208 authentication. The existence of trusted host keys for different 209 public key algorithms also affects this choice. 211 o The authentication methods that are to be required by the server for 212 each user. The server's policy MAY require multiple authentication 213 for some or all users. The required algorithms MAY depend on the 214 location from where the user is trying to log in from. 216 o The operations that the user is allowed to perform using the 217 connection protocol. Some issues are related to security; for 218 example, the policy SHOULD NOT allow the server to start sessions or 219 run commands on the client machine, and MUST NOT allow connections to 220 the authentication agent unless forwarding it has been requested. 221 Other issues, such as which TCP/IP ports can be forwarded and by 222 whom, are clear local policy issues. Many of these issues may 223 involve traversing or bypassing firewalls, and are interrelated with 224 the local security policy. 226 3.4. Security Properties 228 The primary goal of the SSH protocols is improved security on the 229 Internet. It attempts to do this in a way that is easy to deploy, even 230 at the cost of absolute security. 232 o All encryption, integrity, and public key algorithms used are well- 233 known, well-established algorithms. 235 o All algorithms are used with cryptographically sound key sizes that 236 are believed to provide protection against even the strongest 237 cryptanalytic attacks for decades. 239 o All algorithms are negotiated, and in case some algorithm is broken, 240 it is easy to switch to some other algorithm without modifying the 241 base protocol. 243 Specific concessions were made to make wide-spread fast deployment 244 easier. The particular case where this comes up is verifying that the 245 server host key really belongs to the desired host; the protocol allows 246 the verification to be left out (but this is NOT RECOMMENDED). This is 247 believed to significantly improve usability in the short term, until 248 widespread Internet public key infrastructures emerge. 250 3.5. Packet Size and Overhead 252 Some readers will worry about the increase in packet size due to new 253 headers, padding, and MAC. The minimum packet size in the order of 28 254 bytes (depending on negotiated algorithms). The increase is negligible 255 for large packets, but very significant for one-byte packets (telnet- 256 type sessions). There are, however, several factors that make this a 257 non-issue in almost all cases: 259 o The minimum size of a TCP/IP header is 32 bytes. Thus, the increase 260 is actually from 33 to 51 bytes (roughly). 262 o The minimum size of the data field of an ethernet packet is 46 bytes 263 [RFC-894]. Thus, the increase is by no more than 5 bytes. When 264 ethernet headers are considered, the increase is by less than 10 265 percent. 267 o The total fraction of telnet-type data in the Internet is negligible, 268 even with increased packet sizes. 270 The only environment where the packet size increase is likely to have 271 significant effect is PPP [RFC-1134] over slow modem lines (PPP 272 compresses the TCP/IP headers, emphasizing the increase in packet size). 273 However, with modern modems, the time needed to transfer is on the order 274 of 2ms, which is a lot faster than people can type. 276 There are also issues related to the maximum packet size. To minimize 277 delays in screen updates, one does not want excessively large packets 278 for interactive sessions. The maximum packet size is negotiated 279 separately for each channel. 281 3.6. Localization and Character Set Support 283 For the most part, the SSH protocols do not directly pass text that 284 would be displayed to the user. However, there are some places where 285 such data might be passed. When applicable, the character set for the 286 data MUST be explicitly specified. In most places, ISO 10646 with UTF-8 287 encoding is used [RFC-2044]. When applicable, a field is also be 288 provided for a language tag [RFC-1766]. 290 One big issue is the character set of the interactive session. There is 291 no clear solution, as different applications may display data in 292 different formats. Different types of terminal emulation may also be 293 employed in the client, and the character set to be used is effectively 294 determined by the terminal emulation. Thus, no place is provided for 295 specifying the character set or encoding for terminal session data 296 directly. However, the terminal emulation type (e.g. "vt100") is 297 transmitted to the remote site, and it implicitly specifies the 298 character set and encoding. Applications typically use the terminal 299 type to determine what character set they use, or the character set is 300 determined using some external means. The terminal emulation may also 301 allow configuring the default character set. In any case, character set 302 for the terminal session is considered primarily a client local issue. 304 Internal names used to identify algorithms or protocols are normally 305 never displayed to users, and must be in US-ASCII. 307 The client and server user names are inherently constrained by what the 308 server is prepared to accept. They might, however, occasionally be 309 displayed in logs, reports, etc. They MUST be encoded using ISO 10646 310 UTF-8, but other encodings may be required in some cases. It is up to 311 the server to decide how to map user names to accepted user names. 312 Straight bit-wise binary comparison is RECOMMENDED. 314 For localization purposes, the protocol attempts to minimize the number 315 of textual messages transmitted. When present, such messages typically 316 relate to errors, debugging information, or some externally configured 317 data. For data that is normally displayed, it SHOULD be possible to 318 fetch a localized message instead of the transmitted by using a numeric 319 code. The remaining messages SHOULD be configurable. 321 4. Data Type Representations Used in the SSH Protocols 323 byte 324 A byte represents an arbitrary 8-bit value (octet) [RFC1700]. 325 Fixed length data is sometimes represented as an array of bytes, 326 written byte[n], where n is the number of bytes in the array. 328 boolean 329 A boolean value is stored as a single byte. The value 0 330 represents false, and the value 1 represents true. All non-zero 331 values MUST be interpreted as true; however, applications MUST not 332 store values other than 0 and 1. 334 uint32 335 Represents a 32-bit unsigned integer. Stored as four bytes in the 336 order of decreasing significance (network byte order). 338 For example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 339 f4 aa. 341 string 342 Arbitrary length binary string. Strings are allowed to contain 343 arbitrary binary data, including null characters and 8-bit 344 characters. They are stored as a uint32 containing its length 345 (number of bytes that follow) and zero (= empty string) or more 346 bytes that are the value of the string. Terminating null 347 characters are not used. 349 Strings are also used to store text. In that case, US-ASCII is 350 used for internal names, and ISO-10646 UTF-8 for text that might 351 be displayed to the user. Terminating null character SHOULD 352 normally not be stored in the string. 354 For example, the US-ASCII string "testing" is represented as 00 00 355 00 07 t e s t i n g. The UTF8 mapping does not alter the encoding 356 of US-ASCII characters. 358 mpint 359 Represents multiple precision integers in two's complement format, 360 stored as a string, 8 bits per byte, MSB first. Negative numbers 361 have one in the most significant bit of the first byte of the data 362 partition of. If the most significant bit would be set for a 363 positive number, the number MUST be preceded by a zero byte. 364 Unnecessary leading zero or 255 bytes MUST NOT be included. The 365 value zero MUST be stored as a string with zero bytes of data. 367 By convention, a number that is used in modular computations in 368 Z_n SHOULD be represented in the range 0 <= x < n. 370 Examples: 372 value (hex) representation (hex) 373 --------------------------------------------------------------- 374 0 00 00 00 00 375 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 376 80 00 00 00 02 00 80 377 -1234 00 00 00 02 ed cc 378 -deadbeef 00 00 00 05 ff 21 52 41 11 380 4.1. Encoding of Network Addresses 382 Network addresses are encoded as strings. DNS names MUST NOT be used, as 383 DNS is an insecure protocol. 385 If an address contains a colon (':', ascii 58), it is interpreted as an 386 IPv6 address. The encoding of IPv6 addresses is described in [RFC-1884]. 387 IPv4 addresses are expressed in the standard dot-separated decimal 388 format (e.g. 127.0.0.1). 390 5. Algorithm Naming 392 The SSH protocols refer to particular hash, encryption, integrity, 393 compression, and key exchange algorithms or protocols by names. There 394 are some standard algorithms that all implementations MUST support. 395 There are also algorithms that are defined in the protocol specification 396 but are OPTIONAL. Furthermore, it is expected that some organizations 397 will want to use their own algorithms. 399 In this protocol, all algorithm identifiers MUST be printable US-ASCII 400 strings no longer than 64 characters. Names MUST be case-sensitive. 402 There are two formats for algorithm names: 404 o Names that do not contain an at-sign (@) are reserved to be assigned 405 by IANA (Internet Assigned Numbers Authority). Examples include 406 `3des-cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part 407 of the name). Additional names of this format may be registered with 408 IANA; see Section ``IANA Considerations''. Names of this format MUST 409 NOT be used without first registering with IANA. Registered names 410 MUST NOT contain an at-sign (@) or a comma (,). 412 o Anyone can define additional algorithms by using names in the format 413 name@domainname, e.g. "ourcipher-cbc@ssh.fi". The format of the part 414 preceding the at sign is not specified; it MUST consist of US-ASCII 415 characters except at-sign and comma. The part following the at-sign 416 MUST be a valid fully qualified internet domain name [RFC-1034] 417 controlled by the person or organization defining the name. It is up 418 to each domain how it manages its local namespace. 420 6. Message Numbers 422 SSH packets have message numbers in the range 1-255. These numbers have 423 been allocated as follows: 425 Transport layer protocol: 427 1-19 Transport layer generic (e.g. disconnect, ignore, debug, 428 etc) 429 20-29 Algorithm negotiation 430 30-49 Key exchange method specific (numbers can be reused for 431 different authentication methods) 433 User authentication protocol: 435 50-59 User authentication generic 436 60-79 User authentication method specific (numbers can be reused 437 for different authentication methods) 439 Connection protocol: 441 80-89 Connection protocol generic 442 90-127 Channel related messages 444 Reserved for client protocols: 446 128-191 Reserved 448 Local extensions: 450 192-255 Local extensions 452 7. IANA Considerations 454 Allocation of the following types of names in the SSH protocols is 455 assigned to IANA: 457 o encryption algorithm names, 459 o MAC algorithm names, 461 o public key algorithm names (public key algorithm also implies 462 encoding and signature/encryption capability), 464 o key exchange method names, and 466 o protocol (service) names. 468 The IANA-allocated names MUST be printable US-ASCII strings, and MUST 469 NOT contain the characters at-sign ('@'), comma (','), or whitespace or 470 control characters (ascii codes 32 or less). Names are case-sensitive, 471 and MUST not be longer than 64 characters. 473 Each category of names listed above has a separate namespace. However, 474 using the same name in multiple categories SHOULD be avoided to minimize 475 confusion. 476 8. Security Considerations 478 Special care should be taken to ensure that all of the random numbers 479 are of good quality. The random numbers SHOULD be produced with safe 480 mechanisms discussed in [RFC1750]. 482 When displaying text, such as error or debug messages to the user, the 483 client software SHOULD replace any control characters (except tab, 484 carriage return and newline) with safe sequences to avoid attacks by 485 sending terminal control characters. 487 Not using MAC or encryption SHOULD be avoided. The user authentication 488 protocol is subject to man-in-the-middle attacks if the encryption is 489 disabled. The SSH protocol does not protect against message alteration 490 if no MAC is used. 492 9. Trademark Issues 494 SSH is a registered trademark and Secure Shell is a trademark of SSH 495 Communications Security Ltd. SSH Communications Security Ltd permits 496 the use of these trademarks as the name of this standard and protocol, 497 and permits their use to describe that a product conforms to this 498 standard, provided that the following acknowledgement is included 499 where the trademarks are used: ``SSH is a registered trademark and 500 Secure Shell is a trademark of SSH Communications Security Ltd 501 (www.ssh.fi)''. These trademarks may not be used as part of a product 502 name or in otherwise confusing manner without prior written permission 503 of SSH Communications Security Ltd. 505 10. References 507 [FIPS-186] Federal Information Processing Standards Publication (FIPS 508 PUB) 186, Digital Signature Standard, 18 May 1994. 510 [RFC-854] Postel, J. and Reynolds, J., "Telnet Protocol Specification", 511 May 1983. 513 [RFC-894] Hornig, C., "A Standard for the Transmission of IP Datagrams 514 over Ethernet Networks", April 1984. 516 [RFC-1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 517 November 1987. 519 [RFC-1134] Perkins, D., "The Point-to-Point Protocol: A Proposal for 520 Multi-Protocol Transmission o Datagrams Over Point-to-Point Links", 521 November 1989. 523 [RFC-1282] Kantor, B., "BSD Rlogin", December 1991. 525 [RFC-1700] Reynolds, J. and Postel, J., "Assigned Numbers", October 1994 526 (also STD 2). 528 [RFC-1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 529 Recommendations for Security", December 1994. 531 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 532 March 1995. 534 [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and 535 ISO 10646", October 1996. 537 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 538 Requirement Levels", March 1997 540 [Schneier] Schneier, B., "Applied Cryptography Second Edition", John 541 Wiley & Sons, New York, NY, 1995. 543 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet 544 Draft, draft-ietf-secsh-transport-06.txt 546 [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", 547 Internet Draft, draft-ietf-secsh-userauth-06.txt 549 [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet 550 Draft, draft-ietf-secsh-connect-06.txt 552 11. Authors' Addresses 554 Tatu Ylonen 555 SSH Communications Security Ltd. 556 Tekniikantie 12 557 FIN-02150 ESPOO 558 Finland 559 E-mail: ylo@ssh.fi 561 Tero Kivinen 562 SSH Communications Security Ltd. 563 Tekniikantie 12 564 FIN-02150 ESPOO 565 Finland 566 E-mail: kivinen@ssh.fi 568 Markku-Juhani O. Saarinen 569 SSH Communications Security Ltd. 570 Tekniikantie 12 571 FIN-02150 ESPOO 572 Finland 573 E-mail: mjos@ssh.fi 574 Timo J. Rinne 575 SSH Communications Security Ltd. 576 Tekniikantie 12 577 FIN-02150 ESPOO 578 Finland 579 E-mail: tri@ssh.fi 581 Sami Lehtinen 582 SSH Communications Security Ltd. 583 Tekniikantie 12 584 FIN-02150 ESPOO 585 Finland 586 E-mail: sjl@ssh.fi