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, 0 insertions, 1736 deletions
diff --git a/doc/draft-ietf-secsh-architecture-14.txt b/doc/draft-ietf-secsh-architecture-14.txt deleted file mode 100644 index 9a7c4082..00000000 --- a/doc/draft-ietf-secsh-architecture-14.txt +++ /dev/null @@ -1,1736 +0,0 @@ - - -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] - |