diff options
Diffstat (limited to 'doc/draft-ietf-secsh-transport-16.txt')
| -rw-r--r-- | doc/draft-ietf-secsh-transport-16.txt | 1624 |
1 files changed, 0 insertions, 1624 deletions
diff --git a/doc/draft-ietf-secsh-transport-16.txt b/doc/draft-ietf-secsh-transport-16.txt deleted file mode 100644 index b4564f17..00000000 --- a/doc/draft-ietf-secsh-transport-16.txt +++ /dev/null @@ -1,1624 +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 Transport Layer Protocol - draft-ietf-secsh-transport-16.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 SSH transport layer protocol which - typically runs on top of TCP/IP. The protocol can be used as a - - - -Ylonen, et. al. Expires January 12, 2004 [Page 1] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - basis for a number of secure network services. It provides strong - encryption, server authentication, and integrity protection. It - may also provide compression. - - Key exchange method, public key algorithm, symmetric encryption - algorithm, message authentication algorithm, and hash algorithm - are all negotiated. - - This document also describes the Diffie-Hellman key exchange - method and the minimal set of algorithms that are needed to - implement the SSH transport layer protocol. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 - 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 4 - 3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 5 - 3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 5 - 3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 6 - 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 6 - 4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 7 - 4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 11 - 4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 11 - 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 14 - 5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 17 - 5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 18 - 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 19 - 6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 20 - 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 - 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 22 - 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 22 - 9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 23 - 9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 23 - 9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 24 - 9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 24 - 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 24 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 25 - 13. Additional Information . . . . . . . . . . . . . . . . . . . . 25 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - - - -Ylonen, et. al. Expires January 12, 2004 [Page 2] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 29 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 3] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - 1. Introduction - - The SSH transport layer is a secure low level transport protocol. - It provides strong encryption, cryptographic host authentication, - and integrity protection. - - Authentication in this protocol level is host-based; this protocol - does not perform user authentication. A higher level protocol for - user authentication can be designed on top of this protocol. - - The protocol has been designed to be simple, flexible, to allow - parameter negotiation, and to minimize the number of round-trips. - Key exchange method, public key algorithm, symmetric encryption - algorithm, message authentication algorithm, and hash algorithm - are all negotiated. It is expected that in most environments, - only 2 round-trips will be needed for full key exchange, server - authentication, service request, and acceptance notification of - service request. The worst case is 3 round-trips. - - 2. Conventions Used in This Document - - The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD - NOT", and "MAY" that appear in this document are to be interpreted - as described in [RFC2119] - - The used data types and terminology are specified in the - architecture document [SSH-ARCH] - - The architecture document also discusses the algorithm naming - conventions that MUST be used with the SSH protocols. - - 3. Connection Setup - - SSH works over any 8-bit clean, binary-transparent transport. The - underlying transport SHOULD protect against transmission errors as - such errors cause the SSH connection to terminate. - - The client initiates the connection. - - 3.1 Use over TCP/IP - - When used over TCP/IP, the server normally listens for connections - on port 22. This port number has been registered with the IANA, - and has been officially assigned for SSH. - - 3.2 Protocol Version Exchange - - When the connection has been established, both sides MUST send an - - - -Ylonen, et. al. Expires January 12, 2004 [Page 4] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - identification string of the form "SSH-protoversion- - softwareversion comments", followed by carriage return and newline - characters (ASCII 13 and 10, respectively). Both sides MUST be - able to process identification strings without carriage return - character. No null character is sent. The maximum length of the - string is 255 characters, including the carriage return and - newline. - - The part of the identification string preceding carriage return - and newline is used in the Diffie-Hellman key exchange (see - Section Section 6). - - The server MAY send other lines of data before sending the version - string. Each line SHOULD be terminated by a carriage return and - newline. Such lines MUST NOT begin with "SSH-", and SHOULD be - encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). - Clients MUST be able to process such lines; they MAY be silently - ignored, or MAY be displayed to the client user; if they are - displayed, control character filtering discussed in [SSH-ARCH] - SHOULD be used. The primary use of this feature is to allow TCP- - wrappers to display an error message before disconnecting. - - Version strings MUST consist of printable US-ASCII characters, not - including whitespaces or a minus sign (-). The version string is - primarily used to trigger compatibility extensions and to indicate - the capabilities of an implementation. The comment string should - contain additional information that might be useful in solving - user problems. - - The protocol version described in this document is 2.0. - - Key exchange will begin immediately after sending this identifier. - All packets following the identification string SHALL use the - binary packet protocol, to be described below. - - 3.3 Compatibility With Old SSH Versions - - During the transition period, it is important to be able to work - in a way that is compatible with the installed SSH clients and - servers that use an older version of the protocol. Information in - this section is only relevant for implementations supporting - compatibility with SSH versions 1.x. - - 3.4 Old Client, New Server - - Server implementations MAY support a configurable "compatibility" - flag that enables compatibility with old versions. When this flag - is on, the server SHOULD identify its protocol version as "1.99". - - - -Ylonen, et. al. Expires January 12, 2004 [Page 5] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - Clients using protocol 2.0 MUST be able to identify this as - identical to "2.0". In this mode the server SHOULD NOT send the - carriage return character (ASCII 13) after the version - identification string. - - In the compatibility mode the server SHOULD NOT send any further - data after its initialization string until it has received an - identification string from the client. The server can then - determine whether the client is using an old protocol, and can - revert to the old protocol if required. In the compatibility - mode, the server MUST NOT send additional data before the version - string. - - When compatibility with old clients is not needed, the server MAY - send its initial key exchange data immediately after the - identification string. - - 3.5 New Client, Old Server - - Since the new client MAY immediately send additional data after - its identification string (before receiving server's - identification), the old protocol may already have been corrupted - when the client learns that the server is old. When this happens, - the client SHOULD close the connection to the server, and - reconnect using the old protocol. - - 4. Binary Packet Protocol - - Each packet is in the following format: - - uint32 packet_length - byte padding_length - byte[n1] payload; n1 = packet_length - padding_length - 1 - byte[n2] random padding; n2 = padding_length - byte[m] mac (message authentication code); m = mac_length - - packet_length - The length of the packet (bytes), not including MAC or the - packet_length field itself. - - padding_length - Length of padding (bytes). - - payload - The useful contents of the packet. If compression has been - negotiated, this field is compressed. Initially, - compression MUST be "none". - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 6] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - random padding - Arbitrary-length padding, such that the total length of - (packet_length || padding_length || payload || padding) is a - multiple of the cipher block size or 8, whichever is larger. - There MUST be at least four bytes of padding. The padding - SHOULD consist of random bytes. The maximum amount of - padding is 255 bytes. - - mac - Message authentication code. If message authentication has - been negotiated, this field contains the MAC bytes. - Initially, the MAC algorithm MUST be "none". - - - Note that length of the concatenation of packet length, padding - length, payload, and padding MUST be a multiple of the cipher - block size or 8, whichever is larger. This constraint MUST be - enforced even when using stream ciphers. Note that the packet - length field is also encrypted, and processing it requires special - care when sending or receiving packets. - - The minimum size of a packet is 16 (or the cipher block size, - whichever is larger) bytes (plus MAC); implementations SHOULD - decrypt the length after receiving the first 8 (or cipher block - size, whichever is larger) bytes of a packet. - - 4.1 Maximum Packet Length - - All implementations MUST be able to process packets with - uncompressed payload length of 32768 bytes or less and total - packet size of 35000 bytes or less (including length, padding - length, payload, padding, and MAC.). The maximum of 35000 bytes - is an arbitrary chosen value larger than uncompressed size. - Implementations SHOULD support longer packets, where they might be - needed, e.g. if an implementation wants to send a very large - number of certificates. Such packets MAY be sent if the version - string indicates that the other party is able to process them. - However, implementations SHOULD check that the packet length is - reasonable for the implementation to avoid denial-of-service - and/or buffer overflow attacks. - - 4.2 Compression - - If compression has been negotiated, the payload field (and only - it) will be compressed using the negotiated algorithm. The length - field and MAC will be computed from the compressed payload. - Encryption will be done after compression. - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 7] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - Compression MAY be stateful, depending on the method. Compression - MUST be independent for each direction, and implementations MUST - allow independently choosing the algorithm for each direction. - - The following compression methods are currently defined: - - none REQUIRED no compression - zlib OPTIONAL ZLIB (LZ77) compression - - The "zlib" compression is described in [RFC1950] and in [RFC1951]. - The compression context is initialized after each key exchange, - and is passed from one packet to the next with only a partial - flush being performed at the end of each packet. A partial flush - means that the current compressed block is ended and all data will - be output. If the current block is not a stored block, one or - more empty blocks are added after the current block to ensure that - there are at least 8 bits counting from the start of the end-of- - block code of the current block to the end of the packet payload. - - Additional methods may be defined as specified in [SSH-ARCH]. - - 4.3 Encryption - - An encryption algorithm and a key will be negotiated during the - key exchange. When encryption is in effect, the packet length, - padding length, payload and padding fields of each packet MUST be - encrypted with the given algorithm. - - The encrypted data in all packets sent in one direction SHOULD be - considered a single data stream. For example, initialization - vectors SHOULD be passed from the end of one packet to the - beginning of the next packet. All ciphers SHOULD use keys with an - effective key length of 128 bits or more. - - The ciphers in each direction MUST run independently of each - other, and implementations MUST allow independently choosing the - algorithm for each direction (if multiple algorithms are allowed - by local policy). - - The following ciphers are currently defined: - - 3des-cbc REQUIRED three-key 3DES in CBC mode - blowfish-cbc RECOMMENDED Blowfish in CBC mode - twofish256-cbc OPTIONAL Twofish in CBC mode, - with 256-bit key - twofish-cbc OPTIONAL alias for "twofish256-cbc" (this - is being retained for - historical reasons) - - - -Ylonen, et. al. Expires January 12, 2004 [Page 8] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - twofish192-cbc OPTIONAL Twofish with 192-bit key - twofish128-cbc RECOMMENDED Twofish with 128-bit key - aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, - with 256-bit key - aes192-cbc OPTIONAL AES with 192-bit key - aes128-cbc RECOMMENDED AES with 128-bit key - serpent256-cbc OPTIONAL Serpent in CBC mode, with - 256-bit key - serpent192-cbc OPTIONAL Serpent with 192-bit key - serpent128-cbc OPTIONAL Serpent with 128-bit key - arcfour OPTIONAL the ARCFOUR stream cipher - idea-cbc OPTIONAL IDEA in CBC mode - cast128-cbc OPTIONAL CAST-128 in CBC mode - none OPTIONAL no encryption; NOT RECOMMENDED - - The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt- - encrypt), where the first 8 bytes of the key are used for the - first encryption, the next 8 bytes for the decryption, and the - following 8 bytes for the final encryption. This requires 24 - bytes of key data (of which 168 bits are actually used). To - implement CBC mode, outer chaining MUST be used (i.e., there is - only one initialization vector). This is a block cipher with 8 - byte blocks. This algorithm is defined in [SCHNEIER] - - The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit - keys [SCHNEIER]. This is a block cipher with 8 byte blocks. - - The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC - mode, with 256 bit keys as described [TWOFISH]. This is a block - cipher with 16 byte blocks. - - The "twofish192-cbc" cipher. Same as above but with 192-bit key. - - The "twofish128-cbc" cipher. Same as above but with 128-bit key. - - The "aes256-cbc" cipher is AES (Advanced Encryption Standard), - formerly Rijndael, in CBC mode. This version uses 256-bit key. - - The "aes192-cbc" cipher. Same as above but with 192-bit key. - - The "aes128-cbc" cipher. Same as above but with 128-bit key. - - The "serpent256-cbc" cipher in CBC mode, with 256-bit key as - described in the Serpent AES submission. - - The "serpent192-cbc" cipher. Same as above but with 192-bit key. - - The "serpent128-cbc" cipher. Same as above but with 128-bit key. - - - -Ylonen, et. al. Expires January 12, 2004 [Page 9] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - The "arcfour" is the Arcfour stream cipher with 128 bit keys. The - Arcfour cipher is believed to be compatible with the RC4 cipher - [SCHNEIER]. RC4 is a registered trademark of RSA Data Security - Inc. Arcfour (and RC4) has problems with weak keys, and should be - used with caution. - - The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. - IDEA is patented by Ascom AG. - - The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode - [RFC2144]. - - The "none" algorithm specifies that no encryption is to be done. - Note that this method provides no confidentiality protection, and - it is not recommended. Some functionality (e.g. password - authentication) may be disabled for security reasons if this - cipher is chosen. - - Additional methods may be defined as specified in [SSH-ARCH]. - - 4.4 Data Integrity - - Data integrity is protected by including with each packet a - message authentication code (MAC) that is computed from a shared - secret, packet sequence number, and the contents of the packet. - - The message authentication algorithm and key are negotiated during - key exchange. Initially, no MAC will be in effect, and its length - MUST be zero. After key exchange, the selected MAC will be - computed before encryption from the concatenation of packet data: - - mac = MAC(key, sequence_number || unencrypted_packet) - - where unencrypted_packet is the entire packet without MAC (the - length fields, payload and padding), and sequence_number is an - implicit packet sequence number represented as uint32. The - sequence number is initialized to zero for the first packet, and - is incremented after every packet (regardless of whether - encryption or MAC is in use). It is never reset, even if - keys/algorithms are renegotiated later. It wraps around to zero - after every 2^32 packets. The packet sequence number itself is - not included in the packet sent over the wire. - - The MAC algorithms for each direction MUST run independently, and - implementations MUST allow choosing the algorithm independently - for both directions. - - The MAC bytes resulting from the MAC algorithm MUST be transmitted - - - -Ylonen, et. al. Expires January 12, 2004 [Page 10] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - without encryption as the last part of the packet. The number of - MAC bytes depends on the algorithm chosen. - - The following MAC algorithms are currently defined: - - hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key - length = 20) - hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest - length = 12, key length = 20) - hmac-md5 OPTIONAL HMAC-MD5 (digest length = key - length = 16) - hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest - length = 12, key length = 16) - none OPTIONAL no MAC; NOT RECOMMENDED - - The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs - use only the first n bits of the resulting value. - - The hash algorithms are described in [SCHNEIER]. - - Additional methods may be defined as specified in [SSH-ARCH]. - - 4.5 Key Exchange Methods - - The key exchange method specifies how one-time session keys are - generated for encryption and for authentication, and how the - server authentication is done. - - Only one REQUIRED key exchange method has been defined: - - diffie-hellman-group1-sha1 REQUIRED - - This method is described later in this document. - - Additional methods may be defined as specified in [SSH-ARCH]. - - 4.6 Public Key Algorithms - - This protocol has been designed to be able to operate with almost - any public key format, encoding, and algorithm (signature and/or - encryption). - - There are several aspects that define a public key type: - o Key format: how is the key encoded and how are certificates - represented. The key blobs in this protocol MAY contain - certificates in addition to keys. - o Signature and/or encryption algorithms. Some key types may not - support both signing and encryption. Key usage may also be - - - -Ylonen, et. al. Expires January 12, 2004 [Page 11] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - restricted by policy statements in e.g. certificates. In this - case, different key types SHOULD be defined for the different - policy alternatives. - o Encoding of signatures and/or encrypted data. This includes - but is not limited to padding, byte order, and data formats. - - The following public key and/or certificate formats are currently defined: - - ssh-dss REQUIRED sign Simple DSS - ssh-rsa RECOMMENDED sign Simple RSA - x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) - x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) - spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) - spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) - pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) - pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) - - Additional key types may be defined as specified in [SSH-ARCH]. - - The key type MUST always be explicitly known (from algorithm - negotiation or some other source). It is not normally included in - the key blob. - - Certificates and public keys are encoded as follows: - - string certificate or public key format identifier - byte[n] key/certificate data - - The certificate part may have be a zero length string, but a - public key is required. This is the public key that will be used - for authentication; the certificate sequence contained in the - certificate blob can be used to provide authorization. - - Public key / certifcate formats that do not explicitly specify a - signature format identifier MUST use the public key / certificate - format identifier as the signature identifier. - - Signatures are encoded as follows: - string signature format identifier (as specified by the - public key / cert format) - byte[n] signature blob in format specific encoding. - - - The "ssh-dss" key format has the following specific encoding: - - string "ssh-dss" - mpint p - mpint q - - - -Ylonen, et. al. Expires January 12, 2004 [Page 12] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - mpint g - mpint y - - Here the p, q, g, and y parameters form the signature key blob. - - Signing and verifying using this key format is done according to - the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A - description can also be found in [SCHNEIER]. - - The resulting signature is encoded as follows: - - string "ssh-dss" - string dss_signature_blob - - dss_signature_blob is encoded as a string containing r followed by - s (which are 160 bits long integers, without lengths or padding, - unsigned and in network byte order). - - The "ssh-rsa" key format has the following specific encoding: - - string "ssh-rsa" - mpint e - mpint n - - Here the e and n parameters form the signature key blob. - - Signing and verifying using this key format is done according to - [SCHNEIER] and [PKCS1] using the SHA-1 hash. - - The resulting signature is encoded as follows: - - string "ssh-rsa" - string rsa_signature_blob - - rsa_signature_blob is encoded as a string containing s (which is - an integer, without lengths or padding, unsigned and in network - byte order). - - The "spki-sign-rsa" method indicates that the certificate blob - contains a sequence of SPKI certificates. The format of SPKI - certificates is described in [RFC2693]. This method indicates - that the key (or one of the keys in the certificate) is an RSA- - key. - - The "spki-sign-dss". As above, but indicates that the key (or one - of the keys in the certificate) is a DSS-key. - - The "pgp-sign-rsa" method indicates the certificates, the public - - - -Ylonen, et. al. Expires January 12, 2004 [Page 13] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - key, and the signature are in OpenPGP compatible binary format - ([RFC2440]). This method indicates that the key is an RSA-key. - - The "pgp-sign-dss". As above, but indicates that the key is a - DSS-key. - - 5. Key Exchange - - Key exchange begins by each side sending lists of supported - algorithms. Each side has a preferred algorithm in each category, - and it is assumed that most implementations at any given time will - use the same preferred algorithm. Each side MAY guess which - algorithm the other side is using, and MAY send an initial key - exchange packet according to the algorithm if appropriate for the - preferred method. - - Guess is considered wrong, if: - o the kex algorithm and/or the host key algorithm is guessed - wrong (server and client have different preferred algorithm), - or - o if any of the other algorithms cannot be agreed upon (the - procedure is defined below in Section Section 5.1). - - Otherwise, the guess is considered to be right and the - optimistically sent packet MUST be handled as the first key - exchange packet. - - However, if the guess was wrong, and a packet was optimistically - sent by one or both parties, such packets MUST be ignored (even if - the error in the guess would not affect the contents of the - initial packet(s)), and the appropriate side MUST send the correct - initial packet. - - Server authentication in the key exchange MAY be implicit. After - a key exchange with implicit server authentication, the client - MUST wait for response to its service request message before - sending any further data. - - 5.1 Algorithm Negotiation - - Key exchange begins by each side sending the following packet: - - byte SSH_MSG_KEXINIT - byte[16] cookie (random bytes) - string kex_algorithms - string server_host_key_algorithms - string encryption_algorithms_client_to_server - string encryption_algorithms_server_to_client - - - -Ylonen, et. al. Expires January 12, 2004 [Page 14] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - string mac_algorithms_client_to_server - string mac_algorithms_server_to_client - string compression_algorithms_client_to_server - string compression_algorithms_server_to_client - string languages_client_to_server - string languages_server_to_client - boolean first_kex_packet_follows - uint32 0 (reserved for future extension) - - Each of the algorithm strings MUST be a comma-separated list of - algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each - supported (allowed) algorithm MUST be listed in order of - preference. - - The first algorithm in each list MUST be the preferred (guessed) - algorithm. Each string MUST contain at least one algorithm name. - - - cookie - The cookie MUST be a random value generated by the sender. - Its purpose is to make it impossible for either side to - fully determine the keys and the session identifier. - - kex_algorithms - Key exchange algorithms were defined above. The first - algorithm MUST be the preferred (and guessed) algorithm. If - both sides make the same guess, that algorithm MUST be used. - Otherwise, the following algorithm MUST be used to choose a - key exchange method: iterate over client's kex algorithms, - one at a time. Choose the first algorithm that satisfies - the following conditions: - + the server also supports the algorithm, - + if the algorithm requires an encryption-capable host key, - there is an encryption-capable algorithm on the server's - server_host_key_algorithms that is also supported by the - client, and - + if the algorithm requires a signature-capable host key, - there is a signature-capable algorithm on the server's - server_host_key_algorithms that is also supported by the - client. - + If no algorithm satisfying all these conditions can be - found, the connection fails, and both sides MUST - disconnect. - - server_host_key_algorithms - List of the algorithms supported for the server host key. - The server lists the algorithms for which it has host keys; - the client lists the algorithms that it is willing to - - - -Ylonen, et. al. Expires January 12, 2004 [Page 15] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - accept. (There MAY be multiple host keys for a host, - possibly with different algorithms.) - - Some host keys may not support both signatures and - encryption (this can be determined from the algorithm), and - thus not all host keys are valid for all key exchange - methods. - - Algorithm selection depends on whether the chosen key - exchange algorithm requires a signature or encryption - capable host key. It MUST be possible to determine this - from the public key algorithm name. The first algorithm on - the client's list that satisfies the requirements and is - also supported by the server MUST be chosen. If there is no - such algorithm, both sides MUST disconnect. - - encryption_algorithms - Lists the acceptable symmetric encryption algorithms in - order of preference. The chosen encryption algorithm to - each direction MUST be the first algorithm on the client's - list that is also on the server's list. If there is no such - algorithm, both sides MUST disconnect. - - Note that "none" must be explicitly listed if it is to be - acceptable. The defined algorithm names are listed in - Section Section 4.3. - - mac_algorithms - Lists the acceptable MAC algorithms in order of preference. - The chosen MAC algorithm MUST be the first algorithm on the - client's list that is also on the server's list. If there - is no such algorithm, both sides MUST disconnect. - - Note that "none" must be explicitly listed if it is to be - acceptable. The MAC algorithm names are listed in Section - Figure 1. - - compression_algorithms - Lists the acceptable compression algorithms in order of - preference. The chosen compression algorithm MUST be the - first algorithm on the client's list that is also on the - server's list. If there is no such algorithm, both sides - MUST disconnect. - - Note that "none" must be explicitly listed if it is to be - acceptable. The compression algorithm names are listed in - Section Section 4.2. - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 16] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - languages - This is a comma-separated list of language tags in order of - preference [RFC1766]. Both parties MAY ignore this list. - If there are no language preferences, this list SHOULD be - empty. - - first_kex_packet_follows - Indicates whether a guessed key exchange packet follows. If - a guessed packet will be sent, this MUST be TRUE. If no - guessed packet will be sent, this MUST be FALSE. - - After receiving the SSH_MSG_KEXINIT packet from the other - side, each party will know whether their guess was right. - If the other party's guess was wrong, and this field was - TRUE, the next packet MUST be silently ignored, and both - sides MUST then act as determined by the negotiated key - exchange method. If the guess was right, key exchange MUST - continue using the guessed packet. - - After the KEXINIT packet exchange, the key exchange algorithm is - run. It may involve several packet exchanges, as specified by the - key exchange method. - - 5.2 Output from Key Exchange - - The key exchange produces two values: a shared secret K, and an - exchange hash H. Encryption and authentication keys are derived - from these. The exchange hash H from the first key exchange is - additionally used as the session identifier, which is a unique - identifier for this connection. It is used by authentication - methods as a part of the data that is signed as a proof of - possession of a private key. Once computed, the session - identifier is not changed, even if keys are later re-exchanged. - - - Each key exchange method specifies a hash function that is used in - the key exchange. The same hash algorithm MUST be used in key - derivation. Here, we'll call it HASH. - - - Encryption keys MUST be computed as HASH of a known value and K as - follows: - o Initial IV client to server: HASH(K || H || "A" || session_id) - (Here K is encoded as mpint and "A" as byte and session_id as - raw data."A" means the single character A, ASCII 65). - o Initial IV server to client: HASH(K || H || "B" || session_id) - o Encryption key client to server: HASH(K || H || "C" || - session_id) - - - -Ylonen, et. al. Expires January 12, 2004 [Page 17] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - o Encryption key server to client: HASH(K || H || "D" || - session_id) - o Integrity key client to server: HASH(K || H || "E" || - session_id) - o Integrity key server to client: HASH(K || H || "F" || - session_id) - - Key data MUST be taken from the beginning of the hash output. 128 - bits (16 bytes) SHOULD be used for algorithms with variable-length - keys. For other algorithms, as many bytes as are needed are taken - from the beginning of the hash value. If the key length in longer - than the output of the HASH, the key is extended by computing HASH - of the concatenation of K and H and the entire key so far, and - appending the resulting bytes (as many as HASH generates) to the - key. This process is repeated until enough key material is - available; the key is taken from the beginning of this value. In - other words: - - K1 = HASH(K || H || X || session_id) (X is e.g. "A") - K2 = HASH(K || H || K1) - K3 = HASH(K || H || K1 || K2) - ... - key = K1 || K2 || K3 || ... - - This process will lose entropy if the amount of entropy in K is - larger than the internal state size of HASH. - - 5.3 Taking Keys Into Use - - Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. - This message is sent with the old keys and algorithms. All - messages sent after this message MUST use the new keys and - algorithms. - - - When this message is received, the new keys and algorithms MUST be - taken into use for receiving. - - - This message is the only valid message after key exchange, in - addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE - messages. The purpose of this message is to ensure that a party - is able to respond with a disconnect message that the other party - can understand if something goes wrong with the key exchange. - Implementations MUST NOT accept any other messages after key - exchange before receiving SSH_MSG_NEWKEYS. - - byte SSH_MSG_NEWKEYS - - - -Ylonen, et. al. Expires January 12, 2004 [Page 18] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - 6. Diffie-Hellman Key Exchange - - The Diffie-Hellman key exchange provides a shared secret that can - not be determined by either party alone. The key exchange is - combined with a signature with the host key to provide host - authentication. - - - In the following description (C is the client, S is the server; p - is a large safe prime, g is a generator for a subgroup of GF(p), - and q is the order of the subgroup; V_S is S's version string; V_C - is C's version string; K_S is S's public host key; I_C is C's - KEXINIT message and I_S S's KEXINIT message which have been - exchanged before this part begins): - - - 1. C generates a random number x (1 < x < q) and computes e = g^x - mod p. C sends "e" to S. - - 2. S generates a random number y (0 < y < q) and computes f = g^y - mod p. S receives "e". It computes K = e^y mod p, H = - hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these - elements are encoded according to their types; see below), and - signature s on H with its private host key. S sends "K_S || f - || s" to C. The signing operation may involve a second - hashing operation. - - 3. C verifies that K_S really is the host key for S (e.g. using - certificates or a local database). C is also allowed to - accept the key without verification; however, doing so will - render the protocol insecure against active attacks (but may - be desirable for practical reasons in the short term in many - environments). C then computes K = f^x mod p, H = hash(V_C || - V_S || I_C || I_S || K_S || e || f || K), and verifies the - signature s on H. - - Either side MUST NOT send or accept e or f values that are not in - the range [1, p-1]. If this condition is violated, the key - exchange fails. - - - This is implemented with the following messages. The hash - algorithm for computing the exchange hash is defined by the method - name, and is called HASH. The public key algorithm for signing is - negotiated with the KEXINIT messages. - - First, the client sends the following: - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 19] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - byte SSH_MSG_KEXDH_INIT - mpint e - - - The server responds with the following: - - byte SSH_MSG_KEXDH_REPLY - string server public host key and certificates (K_S) - mpint f - string signature of H - - The hash H is computed as the HASH hash of the concatenation of - the following: - - string V_C, the client's version string (CR and NL excluded) - string V_S, the server's version string (CR and NL excluded) - string I_C, the payload of the client's SSH_MSG_KEXINIT - string I_S, the payload of the server's SSH_MSG_KEXINIT - string K_S, the host key - mpint e, exchange value sent by the client - mpint f, exchange value sent by the server - mpint K, the shared secret - - This value is called the exchange hash, and it is used to - authenticate the key exchange. The exchange hash SHOULD be kept - secret. - - - The signature algorithm MUST be applied over H, not the original - data. Most signature algorithms include hashing and additional - padding. For example, "ssh-dss" specifies SHA-1 hashing; in that - case, the data is first hashed with HASH to compute H, and H is - then hashed with SHA-1 as part of the signing operation. - - 6.1 diffie-hellman-group1-sha1 - - The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman - key exchange with SHA-1 as HASH, and the following group: - - The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 - Pi + 129093 ). Its hexadecimal value is: - - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF. - - - -Ylonen, et. al. Expires January 12, 2004 [Page 20] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - In decimal, this value is: - - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - 467627007. - - The generator used with this prime is g = 2. The group order q is - (p - 1) / 2. - - This group was taken from the ISAKMP/Oakley specification, and was - originally generated by Richard Schroeppel at the University of - Arizona. Properties of this prime are described in [Orm96]. - - 7. Key Re-Exchange - - Key re-exchange is started by sending an SSH_MSG_KEXINIT packet - when not already doing a key exchange (as described in Section - Section 5.1). When this message is received, a party MUST respond - with its own SSH_MSG_KEXINIT message except when the received - SSH_MSG_KEXINIT already was a reply. Either party MAY initiate - the re-exchange, but roles MUST NOT be changed (i.e., the server - remains the server, and the client remains the client). - - - Key re-exchange is performed using whatever encryption was in - effect when the exchange was started. Encryption, compression, - and MAC methods are not changed before a new SSH_MSG_NEWKEYS is - sent after the key exchange (as in the initial key exchange). Re- - exchange is processed identically to the initial key exchange, - except for the session identifier that will remain unchanged. It - is permissible to change some or all of the algorithms during the - re-exchange. Host keys can also change. All keys and - initialization vectors are recomputed after the exchange. - Compression and encryption contexts are reset. - - - It is recommended that the keys are changed after each gigabyte of - transmitted data or after each hour of connection time, whichever - comes sooner. However, since the re-exchange is a public key - operation, it requires a fair amount of processing power and - should not be performed too often. - - - More application data may be sent after the SSH_MSG_NEWKEYS packet - has been sent; key exchange does not affect the protocols that lie - - - -Ylonen, et. al. Expires January 12, 2004 [Page 21] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - above the SSH transport layer. - - 8. Service Request - - After the key exchange, the client requests a service. The - service is identified by a name. The format of names and - procedures for defining new names are defined in [SSH-ARCH]. - - - Currently, the following names have been reserved: - - ssh-userauth - ssh-connection - - Similar local naming policy is applied to the service names, as is - applied to the algorithm names; a local service should use the - "servicename@domain" syntax. - - byte SSH_MSG_SERVICE_REQUEST - string service name - - If the server rejects the service request, it SHOULD send an - appropriate SSH_MSG_DISCONNECT message and MUST disconnect. - - - When the service starts, it may have access to the session - identifier generated during the key exchange. - - - If the server supports the service (and permits the client to use - it), it MUST respond with the following: - - byte SSH_MSG_SERVICE_ACCEPT - string service name - - Message numbers used by services should be in the area reserved - for them (see Section 6 in [SSH-ARCH]). The transport level will - continue to process its own messages. - - - Note that after a key exchange with implicit server - authentication, the client MUST wait for response to its service - request message before sending any further data. - - 9. Additional Messages - - Either party may send any of the following messages at any time. - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 22] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - 9.1 Disconnection Message - - byte SSH_MSG_DISCONNECT - uint32 reason code - string description [RFC2279] - string language tag [RFC1766] - - This message causes immediate termination of the connection. All - implementations MUST be able to process this message; they SHOULD - be able to send this message. - - The sender MUST NOT send or receive any data after this message, - and the recipient MUST NOT accept any data after receiving this - message. The description field gives a more specific explanation - in a human-readable form. The error code gives the reason in a - more machine-readable format (suitable for localization), and can - have the following values: - - #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 - #define SSH_DISCONNECT_PROTOCOL_ERROR 2 - #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 - #define SSH_DISCONNECT_RESERVED 4 - #define SSH_DISCONNECT_MAC_ERROR 5 - #define SSH_DISCONNECT_COMPRESSION_ERROR 6 - #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 - #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 - #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 - #define SSH_DISCONNECT_CONNECTION_LOST 10 - #define SSH_DISCONNECT_BY_APPLICATION 11 - #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 - #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 - #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 - #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 - - If the description string is displayed, control character - filtering discussed in [SSH-ARCH] should be used to avoid attacks - by sending terminal control characters. - - 9.2 Ignored Data Message - - byte SSH_MSG_IGNORE - string data - - All implementations MUST understand (and ignore) this message at - any time (after receiving the protocol version). No - implementation is required to send them. This message can be used - as an additional protection measure against advanced traffic - analysis techniques. - - - -Ylonen, et. al. Expires January 12, 2004 [Page 23] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - 9.3 Debug Message - - byte SSH_MSG_DEBUG - boolean always_display - string message [RFC2279] - string language tag [RFC1766] - - All implementations MUST understand this message, but they are - allowed to ignore it. This message is used to pass the other side - information that may help debugging. If always_display is TRUE, - the message SHOULD be displayed. Otherwise, it SHOULD NOT be - displayed unless debugging information has been explicitly - requested by the user. - - - The message doesn't need to contain a newline. It is, however, - allowed to consist of multiple lines separated by CRLF (Carriage - Return - Line Feed) pairs. - - - If the message string is displayed, terminal control character - filtering discussed in [SSH-ARCH] should be used to avoid attacks - by sending terminal control characters. - - 9.4 Reserved Messages - - An implementation MUST respond to all unrecognized messages with - an SSH_MSG_UNIMPLEMENTED message in the order in which the - messages were received. Such messages MUST be otherwise ignored. - Later protocol versions may define other meanings for these - message types. - - byte SSH_MSG_UNIMPLEMENTED - uint32 packet sequence number of rejected message - - - 10. Summary of Message Numbers - - The following message numbers have been defined in this protocol: - - #define SSH_MSG_DISCONNECT 1 - #define SSH_MSG_IGNORE 2 - #define SSH_MSG_UNIMPLEMENTED 3 - #define SSH_MSG_DEBUG 4 - #define SSH_MSG_SERVICE_REQUEST 5 - #define SSH_MSG_SERVICE_ACCEPT 6 - - #define SSH_MSG_KEXINIT 20 - - - -Ylonen, et. al. Expires January 12, 2004 [Page 24] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - #define SSH_MSG_NEWKEYS 21 - - /* Numbers 30-49 used for kex packets. - Different kex methods may reuse message numbers in - this range. */ - - #define SSH_MSG_KEXDH_INIT 30 - #define SSH_MSG_KEXDH_REPLY 31 - - - 11. Security Considerations - - This protocol provides a secure encrypted 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. - - Full security considerations for this protocol are provided in - Section 8 of [SSH-ARCH] - - 12. 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 - 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. - - 13. 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 - - - -Ylonen, et. al. Expires January 12, 2004 [Page 25] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - -References - - [FIPS-186] Federal Information Processing Standards - Publication, ., "FIPS PUB 186, Digital Signature - Standard", May 1994. - - [Orm96] Orman, H., "The Okaley Key Determination Protcol - version1, TR97-92", 1996. - - [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, - "Internet X.509 Public Key Infrastructure - Certificate and CRL Profile", RFC 2459, January - 1999. - - [RFC1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, Nov 1987. - - [RFC1766] Alvestrand, H., "Tags for the Identification of - Languages", RFC 1766, March 1995. - - [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data - Format Specification version 3.3", RFC 1950, May - 1996. - - [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format - Specification version 1.3", RFC 1951, May 1996. - - [RFC2279] Yergeau, F., "UTF-8, a transformation format of - ISO 10646", RFC 2279, January 1998. - - [RFC2104] Krawczyk, H., Bellare, M. and R. 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. - - [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", - RFC 2144, May 1997. - - [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. - Thayer, "OpenPGP Message Format", RFC 2440, - November 1998. - - [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., - Thomas, B. and T. Ylonen, "SPKI Certificate - Theory", RFC 2693, September 1999. - - - -Ylonen, et. al. Expires January 12, 2004 [Page 26] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - [SCHNEIER] Schneier, B., "Applied Cryptography Second - Edition: protocols algorithms and source in code - in C", 1996. - - [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: - A 128-Bit Block Cipher, 1st Edition", March 1999. - - [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, July 2003. - - -Authors' Addresses - - Tatu Ylonen - SSH Communications Security Corp - Fredrikinkatu 42 - HELSINKI FIN-00100 - Finland - - EMail: ylo@ssh.com - - - Tero Kivinen - SSH Communications Security Corp - Fredrikinkatu 42 - HELSINKI FIN-00100 - Finland - - EMail: kivinen@ssh.com - - - Markku-Juhani O. Saarinen - University of Jyvaskyla - - - - - -Ylonen, et. al. Expires January 12, 2004 [Page 27] - -Internet-Draft SSH Transport Layer Protocol July 2003 - - - 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 28] - -Internet-Draft SSH Transport Layer Protocol 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 29] - |