diff options
Diffstat (limited to 'lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt')
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt | 1624 |
1 files changed, 1624 insertions, 0 deletions
diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt new file mode 100644 index 0000000000..9073ea52b2 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt @@ -0,0 +1,1624 @@ + + + +Network Working Group T. Ylonen +Internet-Draft SSH Communications Security Corp +Expires: March 31, 2004 D. Moffat, Editor, Ed. + Sun Microsystems, Inc + Oct 2003 + + + SSH Transport Layer Protocol + draft-ietf-secsh-transport-17.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 SSH transport layer protocol which + typically runs on top of TCP/IP. The protocol can be used as a 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 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Conventions Used in This Document . . . . . . . . . . . . . 3 + 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 3 + 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . 4 + 4.3 Compatibility With Old SSH Versions . . . . . . . . . . . . 4 + 4.3.1 Old Client, New Server . . . . . . . . . . . . . . . . . . . 5 + 4.3.2 New Client, Old Server . . . . . . . . . . . . . . . . . . . 5 + 5. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 5 + 5.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . 6 + 5.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 10 + 5.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . 11 + 6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 13 + 6.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . 16 + 6.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 17 + 7. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 18 + 7.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 19 + 8. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 20 + 9. Service Request . . . . . . . . . . . . . . . . . . . . . . 21 + 10. Additional Messages . . . . . . . . . . . . . . . . . . . . 21 + 10.1 Disconnection Message . . . . . . . . . . . . . . . . . . . 22 + 10.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . 22 + 10.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . 23 + 11. Summary of Message Numbers . . . . . . . . . . . . . . . . . 23 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 + 13. Security Considerations . . . . . . . . . . . . . . . . . . 24 + 14. Intellectual Property . . . . . . . . . . . . . . . . . . . 24 + 15. Additional Information . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 + Normative . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Informative . . . . . . . . . . . . . . . . . . . . . . . . 25 + A. Contibutors . . . . . . . . . . . . . . . . . . . . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . 28 + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] + +Internet-Draft SSH Transport Layer Protocol 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 + + 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. + +3. 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. + +4. 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. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The client initiates the connection. + +4.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. + +4.2 Protocol Version Exchange + + When the connection has been established, both sides MUST send an + 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 7). + + 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. + +4.3 Compatibility With Old SSH Versions + + During the transition period, it is important to be able to work in a + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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. There is no standards track or informational + draft available that defines the SSH 1.x protocol. The only known + documentation of the 1.x protocol is contained in README files that + are shipped along with the source code. + +4.3.1 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". + 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. + +4.3.2 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. + +5. 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 + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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". + + 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. + +5.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 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + length is reasonable for the implementation to avoid + denial-of-service and/or buffer overflow attacks. + +5.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. + + 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]. + +5.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). + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The following ciphers are currently defined: + + 3des-cbc REQUIRED three-key 3DES in CBC mode + blowfish-cbc OPTIONALi 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) + twofish192-cbc OPTIONAL Twofish with 192-bit key + twofish128-cbc OPTIONAL 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 [FIPS-46-3] + + 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) + [FIPS-197], formerly Rijndael, in CBC mode. This version uses 256-bit + key. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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. + + 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]. + + 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]. + +5.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 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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 + 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 + + Figure 1 + + 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]. + +5.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]. + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +5.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 + 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 Raw DSS Key + ssh-rsa RECOMMENDED sign Raw RSA Key + 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. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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 + 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). + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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 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. + +6. 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 6.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. + +6.1 Algorithm Negotiation + + Key exchange begins by each side sending the following packet: + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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 + 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. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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 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 5.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. + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + Note that "none" must be explicitly listed if it is to be + acceptable. The compression algorithm names are listed in + Section Section 5.2. + + languages + This is a comma-separated list of language tags in order of + preference [RFC3066]. Both parties MAY ignore this list. If + there are no language preferences, this list SHOULD be empty. + Language tags SHOULD NOT be present unless they are known to be + needed by the sending party. + + 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. + +6.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: + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + 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) + 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) MUST be used for algorithms with variable-length + keys. The only variable key length algorithm defined in this document + is arcfour). For other algorithms, as many bytes as are needed are + taken from the beginning of the hash value. If the key length needed + is 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. + +6.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. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + byte SSH_MSG_NEWKEYS + + +7. 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 & Moffat, Editor Expires March 31, 2004 [Page 18] + +Internet-Draft SSH Transport Layer Protocol Oct 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. + +7.1 diffie-hellman-group1-sha1 + + The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key + exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit + MODP Group). It is included below in hexadecimal and decimal. + + 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 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + FFFFFFFF FFFFFFFF. + + 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. + +8. 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 + 6.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 + above the SSH transport layer. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +9. 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. + +10. Additional Messages + + Either party may send any of the following messages at any time. + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +10.1 Disconnection Message + + byte SSH_MSG_DISCONNECT + uint32 reason code + string description [RFC2279] + string language tag [RFC3066] + + 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. + +10.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 & Moffat, Editor Expires March 31, 2004 [Page 22] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +10.3 Debug Message + + byte SSH_MSG_DEBUG + boolean always_display + string message [RFC2279] + string language tag [RFC3066] + + 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. + +10.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 + + +11. 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 + #define SSH_MSG_NEWKEYS 21 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 23] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + /* 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 + + +12. IANA Considerations + + This document is part of a set, the IANA considerations for the SSH + protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], + [SSH-CONNECT] are detailed in [SSH-NUMBERS]. + +13. 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] + +14. 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. + +15. Additional Information + + The current document editor is: [email protected]. Comments on + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 24] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + this internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +Normative + + [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, 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 + + [FIPS-186] + Federal Information Processing Standards Publication, + "FIPS PUB 186, Digital Signature Standard", May 1994. + + [FIPS-197] + NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", + November 2001. + + [FIPS-46-3] + U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption + Standard (DES)", October 1999. + + [RFC2459] Housley, R., Ford, W., Polk, T. 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", + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 25] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + STD 13, RFC 1034, November 1987. + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC1950] Deutsch, L. 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. + + [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. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 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. + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 26] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +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 95025 + USA + + EMail: [email protected] + +Appendix A. Contibutors + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 27] + +Internet-Draft SSH Transport Layer Protocol 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, Editor Expires March 31, 2004 [Page 28] + +Internet-Draft SSH Transport Layer Protocol 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, Editor Expires March 31, 2004 [Page 29]
\ No newline at end of file |