diff options
Diffstat (limited to 'doc/draft-ietf-secsh-architecture-14.txt')
-rw-r--r-- | doc/draft-ietf-secsh-architecture-14.txt | 1736 |
1 files changed, 1736 insertions, 0 deletions
diff --git a/doc/draft-ietf-secsh-architecture-14.txt b/doc/draft-ietf-secsh-architecture-14.txt new file mode 100644 index 00000000..9a7c4082 --- /dev/null +++ b/doc/draft-ietf-secsh-architecture-14.txt @@ -0,0 +1,1736 @@ + + +Network Working Group T. Ylonen +Internet-Draft T. Kivinen +Expires: January 12, 2004 SSH Communications Security Corp + M. Saarinen + University of Jyvaskyla + T. Rinne + S. Lehtinen + SSH Communications Security Corp + July 14, 2003 + + + SSH Protocol Architecture + draft-ietf-secsh-architecture-14.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 12, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. This document describes the + architecture of the SSH protocol, as well as the notation and + terminology used in SSH protocol documents. It also discusses the + SSH algorithm naming system that allows local extensions. The SSH + + + +Ylonen, et. al. Expires January 12, 2004 [Page 1] + +Internet-Draft SSH Protocol Architecture July 2003 + + + protocol consists of three major components: The Transport Layer + Protocol provides server authentication, confidentiality, and + integrity with perfect forward secrecy. The User Authentication + Protocol authenticates the client to the server. The Connection + Protocol multiplexes the encrypted tunnel into several logical + channels. Details of these protocols are described in separate + documents. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Specification of Requirements . . . . . . . . . . . . . . . 4 + 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.4 Security Properties . . . . . . . . . . . . . . . . . . . . 7 + 3.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 7 + 3.6 Localization and Character Set Support . . . . . . . . . . . 8 + 4. Data Type Representations Used in the SSH Protocols . . . . 9 + 5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 12 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 13 + 8.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 13 + 8.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 14 + 8.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 18 + 8.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 20 + 8.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 21 + 8.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 21 + 8.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 23 + 8.3.4 Public key authentication . . . . . . . . . . . . . . . . . 23 + 8.3.5 Password authentication . . . . . . . . . . . . . . . . . . 24 + 8.3.6 Host based authentication . . . . . . . . . . . . . . . . . 24 + 8.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 24 + 8.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 24 + 8.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 24 + 8.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 25 + 9. Intellectual Property . . . . . . . . . . . . . . . . . . . 25 + 10. Additional Information . . . . . . . . . . . . . . . . . . . 26 + References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 + + + +Ylonen, et. al. Expires January 12, 2004 [Page 2] + +Internet-Draft SSH Protocol Architecture July 2003 + + + Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 3] + +Internet-Draft SSH Protocol Architecture July 2003 + + + 1. Introduction + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. It consists of three major + components: + o The Transport Layer Protocol [SSH-TRANS] provides server + authentication, confidentiality, and integrity. It may + optionally also provide compression. The transport layer will + typically be run over a TCP/IP connection, but might also be + used on top of any other reliable data stream. + o The User Authentication Protocol [SSH-USERAUTH] authenticates + the client-side user to the server. It runs over the transport + layer protocol. + o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted + tunnel into several logical channels. It runs over the user + authentication protocol. + + The client sends a service request once a secure transport layer + connection has been established. A second service request is sent + after user authentication is complete. This allows new protocols + to be defined and coexist with the protocols listed above. + + The connection protocol provides channels that can be used for a + wide range of purposes. Standard methods are provided for setting + up secure interactive shell sessions and for forwarding + ("tunneling") arbitrary TCP/IP ports and X11 connections. + + 2. Specification of Requirements + + All documents related to the SSH protocols shall use the keywords + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe + requirements. They are to be interpreted as described in [RFC- + 2119]. + + 3. Architecture + + 3.1 Host Keys + + Each server host SHOULD have a host key. Hosts MAY have multiple + host keys using multiple different algorithms. Multiple hosts MAY + share the same host key. If a host has keys at all, it MUST have + at least one key using each REQUIRED public key algorithm + (currently DSS [FIPS-186]). + + The server host key is used during key exchange to verify that the + client is really talking to the correct server. For this to be + possible, the client must have a priori knowledge of the server's + + + +Ylonen, et. al. Expires January 12, 2004 [Page 4] + +Internet-Draft SSH Protocol Architecture July 2003 + + + public host key. + + Two different trust models can be used: + o The client has a local database that associates each host name + (as typed by the user) with the corresponding public host key. + This method requires no centrally administered infrastructure, + and no third-party coordination. The downside is that the + database of name-to-key associations may become burdensome to + maintain. + o The host name-to-key association is certified by some trusted + certification authority. The client only knows the CA root + key, and can verify the validity of all host keys certified by + accepted CAs. + + The second alternative eases the maintenance problem, since + ideally only a single CA key needs to be securely stored on the + client. On the other hand, each host key must be appropriately + certified by a central authority before authorization is + possible. Also, a lot of trust is placed on the central + infrastructure. + + The protocol provides the option that the server name - host key + association is not checked when connecting to the host for the + first time. This allows communication without prior communication + of host keys or certification. The connection still provides + protection against passive listening; however, it becomes + vulnerable to active man-in-the-middle attacks. Implementations + SHOULD NOT normally allow such connections by default, as they + pose a potential security problem. However, as there is no widely + deployed key infrastructure available on the Internet yet, this + option makes the protocol much more usable during the transition + time until such an infrastructure emerges, while still providing a + much higher level of security than that offered by older solutions + (e.g. telnet [RFC-854] and rlogin [RFC-1282]). + + Implementations SHOULD try to make the best effort to check host + keys. An example of a possible strategy is to only accept a host + key without checking the first time a host is connected, save the + key in a local database, and compare against that key on all + future connections to that host. + + Implementations MAY provide additional methods for verifying the + correctness of host keys, e.g. a hexadecimal fingerprint derived + from the SHA-1 hash of the public key. Such fingerprints can + easily be verified by using telephone or other external + communication channels. + + All implementations SHOULD provide an option to not accept host + + + +Ylonen, et. al. Expires January 12, 2004 [Page 5] + +Internet-Draft SSH Protocol Architecture July 2003 + + + keys that cannot be verified. + + We believe that ease of use is critical to end-user acceptance of + security solutions, and no improvement in security is gained if + the new solutions are not used. Thus, providing the option not to + check the server host key is believed to improve the overall + security of the Internet, even though it reduces the security of + the protocol in configurations where it is allowed. + + 3.2 Extensibility + + We believe that the protocol will evolve over time, and some + organizations will want to use their own encryption, + authentication and/or key exchange methods. Central registration + of all extensions is cumbersome, especially for experimental or + classified features. On the other hand, having no central + registration leads to conflicts in method identifiers, making + interoperability difficult. + + We have chosen to identify algorithms, methods, formats, and + extension protocols with textual names that are of a specific + format. DNS names are used to create local namespaces where + experimental or classified extensions can be defined without fear + of conflicts with other implementations. + + One design goal has been to keep the base protocol as simple as + possible, and to require as few algorithms as possible. However, + all implementations MUST support a minimal set of algorithms to + ensure interoperability (this does not imply that the local policy + on all hosts would necessary allow these algorithms). The + mandatory algorithms are specified in the relevant protocol + documents. + + Additional algorithms, methods, formats, and extension protocols + can be defined in separate drafts. See Section Algorithm Naming + (Section 5) for more information. + + 3.3 Policy Issues + + The protocol allows full negotiation of encryption, integrity, key + exchange, compression, and public key algorithms and formats. + Encryption, integrity, public key, and compression algorithms can + be different for each direction. + + The following policy issues SHOULD be addressed in the + configuration mechanisms of each implementation: + o Encryption, integrity, and compression algorithms, separately + for each direction. The policy MUST specify which is the + + + +Ylonen, et. al. Expires January 12, 2004 [Page 6] + +Internet-Draft SSH Protocol Architecture July 2003 + + + preferred algorithm (e.g. the first algorithm listed in each + category). + o Public key algorithms and key exchange method to be used for + host authentication. The existence of trusted host keys for + different public key algorithms also affects this choice. + o The authentication methods that are to be required by the + server for each user. The server's policy MAY require multiple + authentication for some or all users. The required algorithms + MAY depend on the location where the user is trying to log in + from. + o The operations that the user is allowed to perform using the + connection protocol. Some issues are related to security; for + example, the policy SHOULD NOT allow the server to start + sessions or run commands on the client machine, and MUST NOT + allow connections to the authentication agent unless forwarding + such connections has been requested. Other issues, such as + which TCP/IP ports can be forwarded and by whom, are clearly + issues of local policy. Many of these issues may involve + traversing or bypassing firewalls, and are interrelated with + the local security policy. + + 3.4 Security Properties + + The primary goal of the SSH protocol is improved security on the + Internet. It attempts to do this in a way that is easy to deploy, + even at the cost of absolute security. + o All encryption, integrity, and public key algorithms used are + well-known, well-established algorithms. + o All algorithms are used with cryptographically sound key sizes + that are believed to provide protection against even the + strongest cryptanalytic attacks for decades. + o All algorithms are negotiated, and in case some algorithm is + broken, it is easy to switch to some other algorithm without + modifying the base protocol. + + Specific concessions were made to make wide-spread fast deployment + easier. The particular case where this comes up is verifying that + the server host key really belongs to the desired host; the + protocol allows the verification to be left out (but this is NOT + RECOMMENDED). This is believed to significantly improve usability + in the short term, until widespread Internet public key + infrastructures emerge. + + 3.5 Packet Size and Overhead + + Some readers will worry about the increase in packet size due to + new headers, padding, and MAC. The minimum packet size is in the + order of 28 bytes (depending on negotiated algorithms). The + + + +Ylonen, et. al. Expires January 12, 2004 [Page 7] + +Internet-Draft SSH Protocol Architecture July 2003 + + + increase is negligible for large packets, but very significant for + one-byte packets (telnet-type sessions). There are, however, + several factors that make this a non-issue in almost all cases: + o The minimum size of a TCP/IP header is 32 bytes. Thus, the + increase is actually from 33 to 51 bytes (roughly). + o The minimum size of the data field of an Ethernet packet is 46 + bytes [RFC-894]. Thus, the increase is no more than 5 bytes. + When Ethernet headers are considered, the increase is less than + 10 percent. + o The total fraction of telnet-type data in the Internet is + negligible, even with increased packet sizes. + + The only environment where the packet size increase is likely to + have a significant effect is PPP [RFC-1134] over slow modem lines + (PPP compresses the TCP/IP headers, emphasizing the increase in + packet size). However, with modern modems, the time needed to + transfer is in the order of 2 milliseconds, which is a lot faster + than people can type. + + There are also issues related to the maximum packet size. To + minimize delays in screen updates, one does not want excessively + large packets for interactive sessions. The maximum packet size + is negotiated separately for each channel. + + 3.6 Localization and Character Set Support + + For the most part, the SSH protocols do not directly pass text + that would be displayed to the user. However, there are some + places where such data might be passed. When applicable, the + character set for the data MUST be explicitly specified. In most + places, ISO 10646 with UTF-8 encoding is used [RFC-2279]. When + applicable, a field is also provided for a language tag [RFC- + 1766]. + + One big issue is the character set of the interactive session. + There is no clear solution, as different applications may display + data in different formats. Different types of terminal emulation + may also be employed in the client, and the character set to be + used is effectively determined by the terminal emulation. Thus, + no place is provided for directly specifying the character set or + encoding for terminal session data. However, the terminal + emulation type (e.g. "vt100") is transmitted to the remote site, + and it implicitly specifies the character set and encoding. + Applications typically use the terminal type to determine what + character set they use, or the character set is determined using + some external means. The terminal emulation may also allow + configuring the default character set. In any case, the character + set for the terminal session is considered primarily a client + + + +Ylonen, et. al. Expires January 12, 2004 [Page 8] + +Internet-Draft SSH Protocol Architecture July 2003 + + + local issue. + + Internal names used to identify algorithms or protocols are + normally never displayed to users, and must be in US-ASCII. + + The client and server user names are inherently constrained by + what the server is prepared to accept. They might, however, + occasionally be displayed in logs, reports, etc. They MUST be + encoded using ISO 10646 UTF-8, but other encodings may be required + in some cases. It is up to the server to decide how to map user + names to accepted user names. Straight bit-wise binary comparison + is RECOMMENDED. + + For localization purposes, the protocol attempts to minimize the + number of textual messages transmitted. When present, such + messages typically relate to errors, debugging information, or + some externally configured data. For data that is normally + displayed, it SHOULD be possible to fetch a localized message + instead of the transmitted message by using a numerical code. The + remaining messages SHOULD be configurable. + + 4. Data Type Representations Used in the SSH Protocols + byte + + A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. + Fixed length data is sometimes represented as an array of + bytes, written byte[n], where n is the number of bytes in the + array. + + 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. + + uint32 + + Represents a 32-bit unsigned integer. Stored as four bytes in + the order of decreasing significance (network byte order). For + example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 + aa. + + uint64 + + Represents a 64-bit unsigned integer. Stored as eight bytes in + the order of decreasing significance (network byte order). + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 9] + +Internet-Draft SSH Protocol Architecture July 2003 + + + string + + Arbitrary length binary string. Strings are allowed to contain + arbitrary binary data, including null characters and 8-bit + characters. They are stored as a uint32 containing its length + (number of bytes that follow) and zero (= empty string) or more + bytes that are the value of the string. Terminating null + characters are not used. + + Strings are also used to store text. In that case, US-ASCII is + used for internal names, and ISO-10646 UTF-8 for text that + might be displayed to the user. The terminating null character + SHOULD NOT normally be stored in the string. + + For example, the US-ASCII string "testing" is represented as 00 + 00 00 07 t e s t i n g. The UTF8 mapping does not alter the + encoding of US-ASCII characters. + + mpint + + Represents multiple precision integers in two's complement + format, stored as a string, 8 bits per byte, MSB first. + Negative numbers have the value 1 as the most significant bit + of the first byte of the data partition. If the most + significant bit would be set for a positive number, the number + MUST be preceded by a zero byte. Unnecessary leading bytes + with the value 0 or 255 MUST NOT be included. The value zero + MUST be stored as a string with zero bytes of data. + + By convention, a number that is used in modular computations in + Z_n SHOULD be represented in the range 0 <= x < n. + + Examples: + value (hex) representation (hex) + --------------------------------------------------------------- + 0 00 00 00 00 + 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 + 80 00 00 00 02 00 80 + -1234 00 00 00 02 ed cc + -deadbeef 00 00 00 05 ff 21 52 41 11 + + + + name-list + + A string containing a comma separated list of names. A name + list is represented as a uint32 containing its length (number + of bytes that follow) followed by a comma-separated list of + + + +Ylonen, et. al. Expires January 12, 2004 [Page 10] + +Internet-Draft SSH Protocol Architecture July 2003 + + + zero or more names. A name MUST be non-zero length, and it + MUST NOT contain a comma (','). Context may impose additional + restrictions on the names; for example, the names in a list may + have to be valid algorithm identifier (see Algorithm Naming + below), or [RFC-1766] language tags. The order of the names in + a list may or may not be significant, also depending on the + context where the list is is used. Terminating NUL characters + are not used, neither for the individual names, nor for the + list as a whole. + + Examples: + value representation (hex) + --------------------------------------- + (), the empty list 00 00 00 00 + ("zlib") 00 00 00 04 7a 6c 69 62 + ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 + + + + + 5. Algorithm Naming + + The SSH protocols refer to particular hash, encryption, integrity, + compression, and key exchange algorithms or protocols by names. + There are some standard algorithms that all implementations MUST + support. There are also algorithms that are defined in the + protocol specification but are OPTIONAL. Furthermore, it is + expected that some organizations will want to use their own + algorithms. + + In this protocol, all algorithm identifiers MUST be printable US- + ASCII non-empty strings no longer than 64 characters. Names MUST + be case-sensitive. + + There are two formats for algorithm names: + o Names that do not contain an at-sign (@) are reserved to be + assigned by IETF consensus (RFCs). Examples include `3des- + cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part + of the name). Names of this format MUST NOT be used without + first registering them. Registered names MUST NOT contain an + at-sign (@) or a comma (,). + o Anyone can define additional algorithms by using names in the + format name@domainname, e.g. "ourcipher-cbc@ssh.com". The + format of the part preceding the at sign is not specified; it + MUST consist of US-ASCII characters except at-sign and comma. + The part following the at-sign MUST be a valid fully qualified + internet domain name [RFC-1034] controlled by the person or + organization defining the name. It is up to each domain how it + + + +Ylonen, et. al. Expires January 12, 2004 [Page 11] + +Internet-Draft SSH Protocol Architecture July 2003 + + + manages its local namespace. + + 6. Message Numbers + + SSH packets have message numbers in the range 1 to 255. These + numbers have been allocated as follows: + + + Transport layer protocol: + + 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, + etc.) + 20 to 29 Algorithm negotiation + 30 to 49 Key exchange method specific (numbers can be reused for + different authentication methods) + + User authentication protocol: + + 50 to 59 User authentication generic + 60 to 79 User authentication method specific (numbers can be + reused for different authentication methods) + + Connection protocol: + + 80 to 89 Connection protocol generic + 90 to 127 Channel related messages + + Reserved for client protocols: + + 128 to 191 Reserved + + Local extensions: + + 192 to 255 Local extensions + + + + 7. IANA Considerations + + Allocation of the following types of names in the SSH protocols is + assigned by IETF consensus: + o encryption algorithm names, + o MAC algorithm names, + o public key algorithm names (public key algorithm also implies + encoding and signature/encryption capability), + o key exchange method names, and + o protocol (service) names. + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 12] + +Internet-Draft SSH Protocol Architecture July 2003 + + + These 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. + + Names with the at-sign ('@') in them are allocated by the owner of + DNS name after the at-sign (hierarchical allocation in [RFC- + 2343]), otherwise the same restrictions as above. + + Each category of names listed above has a separate namespace. + However, using the same name in multiple categories SHOULD be + avoided to minimize confusion. + + Message numbers (see Section Message Numbers (Section 6)) in the + range of 0..191 should be allocated via IETF consensus; message + numbers in the 192..255 range (the "Local extensions" set) are + reserved for private use. + + 8. Security Considerations + + In order to make the entire body of Security Considerations more + accessible, Security Considerations for the transport, + authentication, and connection documents have been gathered here. + + The transport protocol [1] provides a confidential channel over an + insecure network. It performs server host authentication, key + exchange, encryption, and integrity protection. It also derives a + unique session id that may be used by higher-level protocols. + + The authentication protocol [2] provides a suite of mechanisms + which can be used to authenticate the client user to the server. + Individual mechanisms specified in the in authentication protocol + use the session id provided by the transport protocol and/or + depend on the security and integrity guarantees of the transport + protocol. + + The connection protocol [3] specifies a mechanism to multiplex + multiple streams [channels] of data over the confidential and + authenticated transport. It also specifies channels for accessing + an interactive shell, for 'proxy-forwarding' various external + protocols over the secure transport (including arbitrary TCP/IP + protocols), and for accessing secure 'subsystems' on the server + host. + + 8.1 Pseudo-Random Number Generation + + This protocol binds each session key to the session by including + random, session specific data in the hash used to produce session + + + +Ylonen, et. al. Expires January 12, 2004 [Page 13] + +Internet-Draft SSH Protocol Architecture July 2003 + + + keys. Special care should be taken to ensure that all of the + random numbers are of good quality. If the random data here + (e.g., DH parameters) are pseudo-random then the pseudo-random + number generator should be cryptographically secure (i.e., its + next output not easily guessed even when knowing all previous + outputs) and, furthermore, proper entropy needs to be added to the + pseudo-random number generator. RFC 1750 [1750] offers + suggestions for sources of random numbers and entropy. + Implementors should note the importance of entropy and the well- + meant, anecdotal warning about the difficulty in properly + implementing pseudo-random number generating functions. + + The amount of entropy available to a given client or server may + sometimes be less than what is required. In this case one must + either resort to pseudo-random number generation regardless of + insufficient entropy or refuse to run the protocol. The latter is + preferable. + + 8.2 Transport + + 8.2.1 Confidentiality + + It is beyond the scope of this document and the Secure Shell + Working Group to analyze or recommend specific ciphers other than + the ones which have been established and accepted within the + industry. At the time of this writing, ciphers commonly in use + include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has + been accepted by The published as a US Federal Information + Processing Standards [FIPS-197] and the cryptographic community as + being acceptable for this purpose as well has accepted AES. As + always, implementors and users should check current literature to + ensure that no recent vulnerabilities have been found in ciphers + used within products. Implementors should also check to see which + ciphers are considered to be relatively stronger than others and + should recommend their use to users over relatively weaker + ciphers. It would be considered good form for an implementation + to politely and unobtrusively notify a user that a stronger cipher + is available and should be used when a weaker one is actively + chosen. + + The "none" cipher is provided for debugging and SHOULD NOT be used + except for that purpose. It's cryptographic properties are + sufficiently described in RFC 2410, which will show that its use + does not meet the intent of this protocol. + + The relative merits of these and other ciphers may also be found + in current literature. Two references that may provide + information on the subject are [SCHNEIER] and + + + +Ylonen, et. al. Expires January 12, 2004 [Page 14] + +Internet-Draft SSH Protocol Architecture July 2003 + + + [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode + of operation of certain ciphers and the weakness of this scheme. + Essentially, this mode is theoretically vulnerable to chosen + cipher-text attacks because of the high predictability of the + start of packet sequence. However, this attack is still deemed + difficult and not considered fully practicable especially if + relatively longer block sizes are used. + + Additionally, another CBC mode attack may be mitigated through the + insertion of packets containing SSH_MSG_IGNORE. Without this + technique, a specific attack may be successful. For this attack + (commonly known as the Rogaway attack + [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]) to work, the attacker + would need to know the IV of the next block that is going to be + encrypted. In CBC mode that is the output of the encryption of + the previous block. If the attacker does not have any way to see + the packet yet (i.e it is in the internal buffers of the ssh + implementation or even in the kernel) then this attack will not + work. If the last packet has been sent out to the network (i.e + the attacker has access to it) then he can use the attack. + + In the optimal case an implementor would need to add an extra + packet only if the packet has been sent out onto the network and + there are no other packets waiting for transmission. Implementors + may wish to check to see if there are any unsent packets awaiting + transmission, but unfortunately it is not normally easy to obtain + this information from the kernel or buffers. If there are not, + then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new + packet is added to the stream every time the attacker knows the IV + that is supposed to be used for the next packet, then the attacker + will not be able to guess the correct IV, thus the attack will + never be successfull. + + As an example, consider the following case: + + + Client Server + ------ ------ + TCP(seq=x, len=500) -> + contains Record 1 + + [500 ms passes, no ACK] + + TCP(seq=x, len=1000) -> + contains Records 1,2 + + ACK + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 15] + +Internet-Draft SSH Protocol Architecture July 2003 + + + 1. The Nagle algorithm + TCP retransmits mean that the two + records get coalesced into a single TCP segment + 2. Record 2 is *not* at the beginning of the TCP segment and + never will be, since it gets ACKed. + 3. Yet, the attack is possible because Record 1 has already been + seen. + + As this example indicates, it's totally unsafe to use the + existence of unflushed data in the TCP buffers proper as a guide + to whether you need an empty packet, since when you do the second + write(), the buffers will contain the un-ACKed Record 1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 16] + +Internet-Draft SSH Protocol Architecture July 2003 + + + On the other hand, it's perfectly safe to have the following + situation: + + + Client Server + ------ ------ + TCP(seq=x, len=500) -> + contains SSH_MSG_IGNORE + + TCP(seq=y, len=500) -> + contains Data + + Provided that the IV for second SSH Record is fixed after the data for + the Data packet is determined -i.e. you do: + read from user + encrypt null packet + encrypt data packet + + + 8.2.2 Data Integrity + + This protocol does allow the Data Integrity mechanism to be + disabled. Implementors SHOULD be wary of exposing this feature + for any purpose other than debugging. Users and administrators + SHOULD be explicitly warned anytime the "none" MAC is enabled. + + So long as the "none" MAC is not used, this protocol provides data + integrity. + + Because MACs use a 32 bit sequence number, they might start to + leak information after 2**32 packets have been sent. However, + following the rekeying recommendations should prevent this attack. + The transport protocol [1] recommends rekeying after one gigabyte + of data, and the smallest possible packet is 16 bytes. Therefore, + rekeying SHOULD happen after 2**28 packets at the very most. + + 8.2.3 Replay + + The use of a MAC other than 'none' provides integrity and + authentication. In addition, the transport protocol provides a + unique session identifier (bound in part to pseudo-random data + that is part of the algorithm and key exchange process) that can + be used by higher level protocols to bind data to a given session + and prevent replay of data from prior sessions. For example, the + authentication protocol uses this to prevent replay of signatures + from previous sessions. Because public key authentication + exchanges are cryptographically bound to the session (i.e., to the + initial key exchange) they cannot be successfully replayed in + + + +Ylonen, et. al. Expires January 12, 2004 [Page 17] + +Internet-Draft SSH Protocol Architecture July 2003 + + + other sessions. Note that the session ID can be made public + without harming the security of the protocol. + + If two session happen to have the same session ID [hash of key + exchanges] then packets from one can be replayed against the + other. It must be stressed that the chances of such an occurrence + are, needless to say, minimal when using modern cryptographic + methods. This is all the more so true when specifying larger hash + function outputs and DH parameters. + + Replay detection using monotonically increasing sequence numbers + as input to the MAC, or HMAC in some cases, is described in RFC + 2085 [2085], RFC 2246 [2246], RFC 2743 [2743], RFC 1964 [1964], + RFC 2025 [2025], and RFC 1510 [1510]. The underlying construct is + discussed in RFC 2104 [2104]. Essentially a different sequence + number in each packet ensures that at least this one input to the + MAC function will be unique and will provide a nonrecurring MAC + output that is not predictable to an attacker. If the session + stays active long enough, however, this sequence number will wrap. + This event may provide an attacker an opportunity to replay a + previously recorded packet with an identical sequence number but + only if the peers have not rekeyed since the transmission of the + first packet with that sequence number. If the peers have + rekeyed, then the replay will be detected as the MAC check will + fail. For this reason, it must be emphasized that peers MUST + rekey before a wrap of the sequence numbers. Naturally, if an + attacker does attempt to replay a captured packet before the peers + have rekeyed, then the receiver of the duplicate packet will not + be able to validate the MAC and it will be discarded. The reason + that the MAC will fail is because the receiver will formulate a + MAC based upon the packet contents, the shared secret, and the + expected sequence number. Since the replayed packet will not be + using that expected sequence number (the sequence number of the + replayed packet will have already been passed by the receiver) + then the calculated MAC will not match the MAC received with the + packet. + + 8.2.4 Man-in-the-middle + + This protocol makes no assumptions nor provisions for an + infrastructure or means for distributing the public keys of hosts. + It is expected that this protocol will sometimes be used without + first verifying the association between the server host key and + the server host name. Such usage is vulnerable to man-in-the- + middle attacks. This section describes this and encourages + administrators and users to understand the importance of verifying + this association before any session is initiated. + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 18] + +Internet-Draft SSH Protocol Architecture July 2003 + + + There are three cases of man-in-the-middle attacks to consider. + The first is where an attacker places a device between the client + and the server before the session is initiated. In this case, the + attack device is trying to mimic the legitimate server and will + offer its public key to the client when the client initiates a + session. If it were to offer the public key of the server, then + it would not be able to decrypt or sign the transmissions between + the legitimate server and the client unless it also had access to + the private-key of the host. The attack device will also, + simultaneously to this, initiate a session to the legitimate + server masquerading itself as the client. If the public key of + the server had been securely distributed to the client prior to + that session initiation, the key offered to the client by the + attack device will not match the key stored on the client. In + that case, the user SHOULD be given a warning that the offered + host key does not match the host key cached on the client. As + described in Section 3.1 of [ARCH], the user may be free to accept + the new key and continue the session. It is RECOMMENDED that the + warning provide sufficient information to the user of the client + device so they may make an informed decision. If the user chooses + to continue the session with the stored public-key of the server + (not the public-key offered at the start of the session), then the + session specific data between the attacker and server will be + different between the client-to-attacker session and the attacker- + to-server sessions due to the randomness discussed above. From + this, the attacker will not be able to make this attack work since + the attacker will not be able to correctly sign packets containing + this session specific data from the server since he does not have + the private key of that server. + + The second case that should be considered is similar to the first + case in that it also happens at the time of connection but this + case points out the need for the secure distribution of server + public keys. If the server public keys are not securely + distributed then the client cannot know if it is talking to the + intended server. An attacker may use social engineering + techniques to pass off server keys to unsuspecting users and may + then place a man-in-the-middle attack device between the + legitimate server and the clients. If this is allowed to happen + then the clients will form client-to-attacker sessions and the + attacker will form attacker-to-server sessions and will be able to + monitor and manipulate all of the traffic between the clients and + the legitimate servers. Server administrators are encouraged to + make host key fingerprints available for checking by some means + whose security does not rely on the integrity of the actual host + keys. Possible mechanisms are discussed in Section 3.1 of [SSH- + ARCH] and may also include secured Web pages, physical pieces of + paper, etc. Implementors SHOULD provide recommendations on how + + + +Ylonen, et. al. Expires January 12, 2004 [Page 19] + +Internet-Draft SSH Protocol Architecture July 2003 + + + best to do this with their implementation. Because the protocol + is extensible, future extensions to the protocol may provide + better mechanisms for dealing with the need to know the server's + host key before connecting. For example, making the host key + fingerprint available through a secure DNS lookup, or using + kerberos over gssapi during key exchange to authenticate the + server are possibilities. + + In the third man-in-the-middle case, attackers may attempt to + manipulate packets in transit between peers after the session has + been established. As described in the Replay part of this + section, a successful attack of this nature is very improbable. + As in the Replay section, this reasoning does assume that the MAC + is secure and that it is infeasible to construct inputs to a MAC + algorithm to give a known output. This is discussed in much + greater detail in Section 6 of RFC 2104. If the MAC algorithm has + a vulnerability or is weak enough, then the attacker may be able + to specify certain inputs to yield a known MAC. With that they + may be able to alter the contents of a packet in transit. + Alternatively the attacker may be able to exploit the algorithm + vulnerability or weakness to find the shared secret by reviewing + the MACs from captured packets. In either of those cases, an + attacker could construct a packet or packets that could be + inserted into an SSH stream. To prevent that, implementors are + encouraged to utilize commonly accepted MAC algorithms and + administrators are encouraged to watch current literature and + discussions of cryptography to ensure that they are not using a + MAC algorithm that has a recently found vulnerability or weakness. + + In summary, the use of this protocol without a reliable + association of the binding between a host and its host keys is + inherently insecure and is NOT RECOMMENDED. It may however be + necessary in non-security critical environments, and will still + provide protection against passive attacks. Implementors of + protocols and applications running on top of this protocol should + keep this possibility in mind. + + 8.2.5 Denial-of-service + + This protocol is designed to be used over a reliable transport. + If transmission errors or message manipulation occur, the + connection is closed. The connection SHOULD be re-established if + this occurs. Denial of service attacks of this type ("wire + cutter") are almost impossible to avoid. + + In addition, this protocol is vulnerable to Denial of Service + attacks because an attacker can force the server to go through the + CPU and memory intensive tasks of connection setup and key + + + +Ylonen, et. al. Expires January 12, 2004 [Page 20] + +Internet-Draft SSH Protocol Architecture July 2003 + + + exchange without authenticating. Implementors SHOULD provide + features that make this more difficult. For example, only + allowing connections from a subset of IPs known to have valid + users. + + 8.2.6 Covert Channels + + The protocol was not designed to eliminate covert channels. For + example, the padding, SSH_MSG_IGNORE messages, and several other + places in the protocol can be used to pass covert information, and + the recipient has no reliable way to verify whether such + information is being sent. + + 8.2.7 Forward Secrecy + + It should be noted that the Diffie-Hellman key exchanges may + provide perfect forward secrecy (PFS). PFS is essentially defined + as the cryptographic property of a key-establishment protocol in + which the compromise of a session key or long-term private key + after a given session does not cause the compromise of any earlier + session. [ANSI T1.523-2001] SSHv2 sessions resulting from a key + exchange using diffie-hellman-group1-sha1 are secure even if + private keying/authentication material is later revealed, but not + if the session keys are revealed. So, given this definition of + PFS, SSHv2 does have PFS. It is hoped that all other key exchange + mechanisms proposed and used in the future will also provide PFS. + This property is not commuted to any of the applications or + protocols using SSH as a transport however. The transport layer + of SSH provides confidentiality for password authentication and + other methods that rely on secret data. + + Of course, if the DH private parameters for the client and server + are revealed then the session key is revealed, but these items can + be thrown away after the key exchange completes. It's worth + pointing out that these items should not be allowed to end up on + swap space and that they should be erased from memory as soon as + the key exchange completes. + + 8.3 Authentication Protocol + + The purpose of this protocol is to perform client user + authentication. It assumes that this run over a secure transport + layer protocol, which has already authenticated the server + machine, established an encrypted communications channel, and + computed a unique session identifier for this session. + + Several authentication methods with different security + characteristics are allowed. It is up to the server's local + + + +Ylonen, et. al. Expires January 12, 2004 [Page 21] + +Internet-Draft SSH Protocol Architecture July 2003 + + + policy to decide which methods (or combinations of methods) it is + willing to accept for each user. Authentication is no stronger + than the weakest combination allowed. + + The server may go into a "sleep" period after repeated + unsuccessful authentication attempts to make key search more + difficult for attackers. Care should be taken so that this + doesn't become a self-denial of service vector. + + 8.3.1 Weak Transport + + If the transport layer does not provide confidentiality, + authentication methods that rely on secret data SHOULD be + disabled. If it does not provide strong integrity protection, + requests to change authentication data (e.g. a password change) + SHOULD be disabled to prevent an attacker from modifying the + ciphertext without being noticed, or rendering the new + authentication data unusable (denial of service). + + The assumption as stated above that the Authentication Protocol + only run over a secure transport that has previously authenticated + the server is very important to note. People deploying SSH are + reminded of the consequences of man-in-the-middle attacks if the + client does not have a very strong a priori association of the + server with the host key of that server. Specifically for the + case of the Authentication Protocol the client may form a session + to a man-in-the-middle attack device and divulge user credentials + such as their username and password. Even in the cases of + authentication where no user credentials are divulged, an attacker + may still gain information they shouldn't have by capturing key- + strokes in much the same way that a honeypot works. + + 8.3.2 Debug messages + + Special care should be taken when designing debug messages. These + messages may reveal surprising amounts of information about the + host if not properly designed. Debug messages can be disabled + (during user authentication phase) if high security is required. + Administrators of host machines should make all attempts to + compartmentalize all event notification messages and protect them + from unwarranted observation. Developers should be aware of the + sensitive nature of some of the normal event messages and debug + messages and may want to provide guidance to administrators on + ways to keep this information away from unauthorized people. + Developers should consider minimizing the amount of sensitive + information obtainable by users during the authentication phase in + accordance with the local policies. For this reason, it is + RECOMMENDED that debug messages be initially disabled at the time + + + +Ylonen, et. al. Expires January 12, 2004 [Page 22] + +Internet-Draft SSH Protocol Architecture July 2003 + + + of deployment and require an active decision by an administrator + to allow them to be enabled. It is also RECOMMENDED that a + message expressing this concern be presented to the administrator + of a system when the action is taken to enable debugging messages. + + 8.3.3 Local security policy + + Implementer MUST ensure that the credentials provided validate the + professed user and also MUST ensure that the local policy of the + server permits the user the access requested. In particular, + because of the flexible nature of the SSH connection protocol, it + may not be possible to determine the local security policy, if + any, that should apply at the time of authentication because the + kind of service being requested is not clear at that instant. For + example, local policy might allow a user to access files on the + server, but not start an interactive shell. However, during the + authentication protocol, it is not known whether the user will be + accessing files or attempting to use an interactive shell, or even + both. In any event, where local security policy for the server + host exists, it MUST be applied and enforced correctly. + + Implementors are encouraged to provide a default local policy and + make its parameters known to administrators and users. At the + discretion of the implementors, this default policy may be along + the lines of 'anything goes' where there are no restrictions + placed upon users, or it may be along the lines of 'excessively + restrictive' in which case the administrators will have to + actively make changes to this policy to meet their needs. + Alternatively, it may be some attempt at providing something + practical and immediately useful to the administrators of the + system so they don't have to put in much effort to get SSH + working. Whatever choice is made MUST be applied and enforced as + required above. + + 8.3.4 Public key authentication + + The use of public-key authentication assumes that the client host + has not been compromised. + + This risk can be mitigated by the use of passphrases on private + keys; however, this is not an enforceable policy. The use of + smartcards, or other technology to make passphrases an enforceable + policy is suggested. + + The server could require both password and public-key + authentication, however, this requires the client to expose its + password to the server (see section on password authentication + below.) + + + +Ylonen, et. al. Expires January 12, 2004 [Page 23] + +Internet-Draft SSH Protocol Architecture July 2003 + + + 8.3.5 Password authentication + + The password mechanism as specified in the authentication protocol + assumes that the server has not been compromised. If the server + has been compromised, using password authentication will reveal a + valid username / password combination to the attacker, which may + lead to further compromises. + + This vulnerability can be mitigated by using an alternative form + of authentication. For example, public-key authentication makes + no assumptions about security on the server. + + 8.3.6 Host based authentication + + Host based authentication assumes that the client has not been + compromised. There are no mitigating strategies, other than to + use host based authentication in combination with another + authentication method. + + 8.4 Connection protocol + + 8.4.1 End point security + + End point security is assumed by the connection protocol. If the + server has been compromised, any terminal sessions, port + forwarding, or systems accessed on the host are compromised. + There are no mitigating factors for this. + + If the client end point has been compromised, and the server fails + to stop the attacker at the authentication protocol, all services + exposed (either as subsystems or through forwarding) will be + vulnerable to attack. Implementors SHOULD provide mechanisms for + administrators to control which services are exposed to limit the + vulnerability of other services. + + These controls might include controlling which machines and ports + can be target in 'port-forwarding' operations, which users are + allowed to use interactive shell facilities, or which users are + allowed to use exposed subsystems. + + 8.4.2 Proxy forwarding + + The SSH connection protocol allows for proxy forwarding of other + protocols such as SNMP, POP3, and HTTP. This may be a concern for + network administrators who wish to control the access of certain + applications by users located outside of their physical location. + Essentially, the forwarding of these protocols may violate site + specific security policies as they may be undetectably tunneled + + + +Ylonen, et. al. Expires January 12, 2004 [Page 24] + +Internet-Draft SSH Protocol Architecture July 2003 + + + through a firewall. Implementors SHOULD provide an administrative + mechanism to control the proxy forwarding functionality so that + site specific security policies may be upheld. + + In addition, a reverse proxy forwarding functionality is + available, which again can be used to bypass firewall controls. + + As indicated above, end-point security is assumed during proxy + forwarding operations. Failure of end-point security will + compromise all data passed over proxy forwarding. + + 8.4.3 X11 forwarding + + Another form of proxy forwarding provided by the ssh connection + protocol is the forwarding of the X11 protocol. If end-point + security has been compromised, X11 forwarding may allow attacks + against the X11 server. Users and administrators should, as a + matter of course, use appropriate X11 security mechanisms to + prevent unauthorized use of the X11 server. Implementors, + administrators and users who wish to further explore the security + mechanisms of X11 are invited to read [SCHEIFLER] and analyze + previously reported problems with the interactions between SSH + forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 + [CERT]. + + X11 display forwarding with SSH, by itself, is not sufficient to + correct well known problems with X11 security [VENEMA]. However, + X11 display forwarding in SSHv2 (or other, secure protocols), + combined with actual and pseudo-displays which accept connections + only over local IPC mechanisms authorized by permissions or ACLs, + does correct many X11 security problems as long as the "none" MAC + is not used. It is RECOMMENDED that X11 display implementations + default to allowing display opens only over local IPC. It is + RECOMMENDED that SSHv2 server implementations that support X11 + forwarding default to allowing display opens only over local IPC. + On single-user systems it might be reasonable to default to + allowing local display opens over TCP/IP. + + Implementors of the X11 forwarding protocol SHOULD implement the + magic cookie access checking spoofing mechanism as described in + [ssh-connect] as an additional mechanism to prevent unauthorized + use of the proxy. + + 9. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described + + + +Ylonen, et. al. Expires January 12, 2004 [Page 25] + +Internet-Draft SSH Protocol Architecture July 2003 + + + in this document or the extent to which any license under such + rights might or might not be available; neither does it represent + that it has made any effort to identify any such rights. + Information on the IETF's procedures with respect to rights in + standards-track and standards-related documentation can be found + in BCP-11. Copies of claims of rights made available for + publication and any assurances of licenses to be made available, + or the result of an attempt made to obtain a general license or + permission for the use of such proprietary rights by implementers + or users of this specification can be obtained from the IETF + Secretariat. + + The IETF has been notified of intellectual property rights claimed + in regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + 10. Additional Information + + The current document editor is: Darren.Moffat@Sun.COM. Comments + on this internet draft should be sent to the IETF SECSH working + group, details at: http://ietf.org/html.charters/secsh- + charter.html + +References + + [FIPS-186] Federal Information Processing + Standards Publication, ., "FIPS PUB + 186, Digital Signature Standard", May + 1994. + + [FIPS-197] National Institue of Standards and + Technology, ., "FIPS 197, + Specification for the Advanced + Encryption Standard", November 2001. + + [ANSI T1.523-2001] American National Standards Insitute, + Inc., "Telecom Glossary 2000", + February 2001. + + [SCHEIFLER] Scheifler, R., "X Window System : The + Complete Reference to Xlib, X + Protocol, Icccm, Xlfd, 3rd edition.", + Digital Press ISBN 1555580882, + Feburary 1992. + + [RFC0854] Postel, J. and J. Reynolds, "Telnet + Protocol Specification", STD 8, RFC + + + +Ylonen, et. al. Expires January 12, 2004 [Page 26] + +Internet-Draft SSH Protocol Architecture July 2003 + + + 854, May 1983. + + [RFC0894] Hornig, C., "Standard for the + transmission of IP datagrams over + Ethernet networks", STD 41, RFC 894, + Apr 1984. + + [RFC1034] Mockapetris, P., "Domain names - + concepts and facilities", STD 13, RFC + 1034, Nov 1987. + + [RFC1134] Perkins, D., "Point-to-Point Protocol: + A proposal for multi-protocol + transmission of datagrams over Point- + to-Point links", RFC 1134, Nov 1989. + + [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, + December 1991. + + [RFC1510] Kohl, J. and C. Neuman, "The Kerberos + Network Authentication Service (V5)", + RFC 1510, September 1993. + + [RFC1700] Reynolds, J. and J. Postel, "Assigned + Numbers", STD 2, RFC 1700, October + 1994. + + [RFC1750] Eastlake, D., Crocker, S. and J. + Schiller, "Randomness Recommendations + for Security", RFC 1750, December + 1994. + + [RFC1766] Alvestrand, H., "Tags for the + Identification of Languages", RFC + 1766, March 1995. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS- + API Mechanism", RFC 1964, June 1996. + + [RFC2025] Adams, C., "The Simple Public-Key GSS- + API Mechanism (SPKM)", RFC 2025, + October 1996. + + [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP + Authentication with Replay + Prevention", RFC 2085, February 1997. + + [RFC2104] Krawczyk, H., Bellare, M. and R. + + + +Ylonen, et. al. Expires January 12, 2004 [Page 27] + +Internet-Draft SSH Protocol Architecture July 2003 + + + Canetti, "HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in + RFCs to Indicate Requirement Levels", + BCP 14, RFC 2119, March 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS + Protocol Version 1.0", RFC 2246, + January 1999. + + [RFC2279] Yergeau, F., "UTF-8, a transformation + format of ISO 10646", RFC 2279, + January 1998. + + [RFC2410] Glenn, R. and S. Kent, "The NULL + Encryption Algorithm and Its Use With + IPsec", RFC 2410, November 1998. + + [RFC2434] Narten, T. and H. Alvestrand, + "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP + 26, RFC 2434, October 1998. + + [RFC2743] Linn, J., "Generic Security Service + Application Program Interface Version + 2, Update 1", RFC 2743, January 2000. + + [SSH-ARCH] Ylonen, T., "SSH Protocol + Architecture", I-D draft-ietf- + architecture-14.txt, July 2003. + + [SSH-TRANS] Ylonen, T., "SSH Transport Layer + Protocol", I-D draft-ietf-transport- + 16.txt, July 2003. + + [SSH-USERAUTH] Ylonen, T., "SSH Authentication + Protocol", I-D draft-ietf-userauth- + 17.txt, July 2003. + + [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", + I-D draft-ietf-connect-17.txt, July + 2003. + + [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH + Protocol Assigned Numbers", I-D draft- + ietf-secsh-assignednumbers-03.txt, + + + +Ylonen, et. al. Expires January 12, 2004 [Page 28] + +Internet-Draft SSH Protocol Architecture July 2003 + + + July 2003. + + [SCHNEIER] Schneier, B., "Applied Cryptography + Second Edition: protocols algorithms + and source in code in C", 1996. + + [KAUFMAN,PERLMAN,SPECINER] Kaufman, C., Perlman, R. and M. + Speciner, "Network Security: PRIVATE + Communication in a PUBLIC World", + 1995. + + [CERT] CERT Coordination Center, The., + "http://www.cert.org/nav/index_red.html" + . + + [VENEMA] Venema, W., "Murphy's Law and Computer + Security", Proceedings of 6th USENIX + Security Symposium, San Jose CA + http://www.usenix.org/publications/library/proceedings/sec96/venema.html + , July 1996. + + [ROGAWAY] Rogaway, P., "Problems with Proposed + IP Cryptography", Unpublished paper + http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt + , 1996. + + [DAI] Dai, W., "An attack against SSH2 + protocol", Email to the SECSH Working + Group ietf-ssh@netbsd.org + ftp://ftp.ietf.org/ietf-mail- + archive/secsh/2002-02.mail, Feb 2002. + + [BELLARE,KOHNO,NAMPREMPRE] Bellaire, M., Kohno, T. and C. + Namprempre, "Authenticated Encryption + in SSH: Fixing the SSH Binary Packet + Protocol", , Sept 2002. + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: ylo@ssh.com + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 29] + +Internet-Draft SSH Protocol Architecture July 2003 + + + Tero Kivinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: kivinen@ssh.com + + + Markku-Juhani O. Saarinen + University of Jyvaskyla + + + Timo J. Rinne + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: tri@ssh.com + + + Sami Lehtinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: sjl@ssh.com + + + + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 30] + +Internet-Draft SSH Protocol Architecture July 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished + to others, and derivative works that comment on or otherwise + explain it or assist in its implementation may be prepared, + copied, published and distributed, in whole or in part, without + restriction of any kind, provided that the above copyright notice + and this paragraph are included on all such copies and derivative + works. However, this document itself may not be modified in any + way, such as by removing the copyright notice or references to the + Internet Society or other Internet organizations, except as needed + for the purpose of developing Internet standards in which case the + procedures for copyrights defined in the Internet Standards + process must be followed, or as required to translate it into + languages other than English. + + The limited permissions granted above are perpetual and will not + be revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on + an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires January 12, 2004 [Page 31] + |