diff options
Diffstat (limited to 'lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt')
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt | 1624 |
1 files changed, 0 insertions, 1624 deletions
diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt b/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt deleted file mode 100644 index 18070e8485..0000000000 --- a/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt +++ /dev/null @@ -1,1624 +0,0 @@ - - - -Network Working Group T. Ylonen -Internet-Draft SSH Communications Security Corp -Expires: March 31, 2004 D. Moffat, Ed. - Sun Microsystems, Inc - Oct 2003 - - - SSH Protocol Architecture - draft-ietf-secsh-architecture-15.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 March 31, 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 - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 1] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - documents. - -Table of Contents - - 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Specification of Requirements . . . . . . . . . . . . . . . 3 - 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.4 Security Properties . . . . . . . . . . . . . . . . . . . . 6 - 4.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 6 - 4.6 Localization and Character Set Support . . . . . . . . . . . 7 - 5. Data Type Representations Used in the SSH Protocols . . . . 8 - 6. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 10 - 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 11 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 - 9. Security Considerations . . . . . . . . . . . . . . . . . . 12 - 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 12 - 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 13 - 9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 17 - 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 19 - 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 19 - 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 20 - 9.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 20 - 9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 21 - 9.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 21 - 9.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 21 - 9.3.4 Public key authentication . . . . . . . . . . . . . . . . . 22 - 9.3.5 Password authentication . . . . . . . . . . . . . . . . . . 22 - 9.3.6 Host based authentication . . . . . . . . . . . . . . . . . 23 - 9.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 23 - 9.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 23 - 9.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 23 - 9.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 24 - Normative References . . . . . . . . . . . . . . . . . . . . 24 - Informative References . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 - Intellectual Property and Copyright Statements . . . . . . . 28 - - - - - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 2] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - -1. Contributors - - The major original contributors of this document were: Tatu Ylonen, - Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications - Security Corp), and Markku-Juhani O. Saarinen (University of - Jyvaskyla) - - The document editor is: [email protected]. Comments on this - internet draft should be sent to the IETF SECSH working group, - details at: http://ietf.org/html.charters/secsh-charter.html - -2. 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. - -3. 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 [RFC2119]. - -4. Architecture - - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 3] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - -4.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 (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 - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 4] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 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. - -4.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 - 6) for more information. - -4.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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 5] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 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. - -4.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. - -4.5 Packet Size and Overhead - - Some readers will worry about the increase in packet size due to new - - - -Ylonen & Moffat Expires March 31, 2004 [Page 6] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - headers, padding, and MAC. The minimum packet size is in the order - of 28 bytes (depending on negotiated algorithms). The 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. - -4.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-3066]. - - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 7] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - primarily a client 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. - -5. 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 & Moffat Expires March 31, 2004 [Page 8] - -Internet-Draft SSH Protocol Architecture Oct 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 zero or more - - - -Ylonen & Moffat Expires March 31, 2004 [Page 9] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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-3066] - 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 - - - - -6. 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. "[email protected]". 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 manages its - local namespace. - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 10] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - -7. 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 - - - -8. IANA Considerations - - The initial state of the IANA registry is detailed in [SSH-NUMBERS]. - - Allocation of the following types of names in the SSH protocols is - assigned by IETF consensus: - o SSH encryption algorithm names, - o SSH MAC algorithm names, - o SSH public key algorithm names (public key algorithm also implies - encoding and signature/encryption capability), - o SSH key exchange method names, and - o SSH protocol (service) names. - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 11] - -Internet-Draft SSH Protocol Architecture Oct 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 7)) in the - range of 0..191 are allocated via IETF consensus; message numbers in - the 192..255 range (the "Local extensions" set) are reserved for - private use. - -9. 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. - -9.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 - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 12] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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. - -9.2 Transport - -9.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 [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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 13] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 - - - 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. - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 14] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 & Moffat Expires March 31, 2004 [Page 15] - -Internet-Draft SSH Protocol Architecture Oct 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 - - -9.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. - -9.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 other sessions. - - - -Ylonen & Moffat Expires March 31, 2004 [Page 16] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 [RFC2085] /> - [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC1510]. The - underlying construct is discussed in [RFC2104]. 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. - -9.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. - - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 17] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 18] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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. - -9.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 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. - -9.2.6 Covert Channels - - The protocol was not designed to eliminate covert channels. For - - - -Ylonen & Moffat Expires March 31, 2004 [Page 19] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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. - -9.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. - -9.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 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. - - - -Ylonen & Moffat Expires March 31, 2004 [Page 20] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - -9.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. - -9.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 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. - -9.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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 21] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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. - -9.3.4 Public key authentication - - The use of public-key authentication assumes that the client host has - not been compromised. It also assumes that the private-key of the - server 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.) - -9.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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 22] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - authentication. For example, public-key authentication makes no - assumptions about security on the server. - -9.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. - -9.4 Connection protocol - -9.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. - -9.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 - 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 - - - -Ylonen & Moffat Expires March 31, 2004 [Page 23] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - all data passed over proxy forwarding. - -9.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. - -Normative References - - [SSH-ARCH] - Ylonen, T., "SSH Protocol Architecture", I-D - draft-ietf-architecture-15.txt, Oct 2003. - - [SSH-TRANS] - Ylonen, T., "SSH Transport Layer Protocol", I-D - draft-ietf-transport-17.txt, Oct 2003. - - [SSH-USERAUTH] - Ylonen, T., "SSH Authentication Protocol", I-D - draft-ietf-userauth-18.txt, Oct 2003. - - [SSH-CONNECT] - - - -Ylonen & Moffat Expires March 31, 2004 [Page 24] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - Ylonen, T., "SSH Connection Protocol", I-D - draft-ietf-connect-18.txt, Oct 2003. - - [SSH-NUMBERS] - Lehtinen, S. and D. Moffat, "SSH Protocol Assigned - Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct - 2003. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -Informative 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 854, May 1983. - - [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams - over Ethernet networks", STD 41, RFC 894, April 1984. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for - multi-protocol transmission of datagrams over - Point-to-Point links", RFC 1134, November 1989. - - [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. - - [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network - Authentication Service (V5)", RFC 1510, September 1993. - - - -Ylonen & Moffat Expires March 31, 2004 [Page 25] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, - October 1994. - - [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [RFC3066] Alvestrand, H., "Tags for the Identification of - Languages", BCP 47, RFC 3066, January 2001. - - [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. Canetti, "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. - and P. Kocher, "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. - - [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/ - - - -Ylonen & Moffat Expires March 31, 2004 [Page 26] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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 [email protected] 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: [email protected] - - - Darren J. Moffat (editor) - Sun Microsystems, Inc - 17 Network Circle - Menlo Park CA 94025 - USA - - EMail: [email protected] - - - - - - - - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 27] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - -Intellectual Property Statement - - 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 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - 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. - - -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 assignees. - - - -Ylonen & Moffat Expires March 31, 2004 [Page 28] - -Internet-Draft SSH Protocol Architecture Oct 2003 - - - 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. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ylonen & Moffat Expires March 31, 2004 [Page 29]
\ No newline at end of file |