idnits 2.17.1 draft-ietf-secsh-transport-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 504 has weird spacing: '... string cert...' == Line 517 has weird spacing: '... string sig...' == Line 538 has weird spacing: '... string dss...' == Line 558 has weird spacing: '... string rsa...' == Line 615 has weird spacing: '... string kex...' == (21 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2002) is 8086 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PKCS1' is mentioned on line 553, but not defined -- Looks like a reference, but probably isn't: '16' on line 614 == Unused Reference: 'RFC2459' is defined on line 1124, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'SSH-TRANS' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'SSH-USERAUTH' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 1177, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' -- Possible downref: Non-RFC (?) normative reference: ref. 'Orm96' ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Downref: Normative reference to an Experimental RFC: RFC 2693 -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH' -- No information found for draft-ietf-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-ARCH' -- No information found for draft-ietf-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' -- No information found for draft-ietf-userauth - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-USERAUTH' -- No information found for draft-ietf-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ylonen 3 Internet-Draft T. Kivinen 4 Expires: August 29, 2002 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 February 28, 2002 12 SSH Transport Layer Protocol 13 draft-ietf-secsh-transport-13.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 29, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 SSH is a protocol for secure remote login and other secure network 45 services over an insecure network. 47 This document describes the SSH transport layer protocol which 48 typically runs on top of TCP/IP. The protocol can be used as a basis 49 for a number of secure network services. It provides strong 50 encryption, server authentication, and integrity protection. It may 51 also provide compression. 53 Key exchange method, public key algorithm, symmetric encryption 54 algorithm, message authentication algorithm, and hash algorithm are 55 all negotiated. 57 This document also describes the Diffie-Hellman key exchange method 58 and the minimal set of algorithms that are needed to implement the 59 SSH transport layer protocol. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 3 68 3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 4 69 3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 4 70 3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 5 71 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 5 72 4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 6 73 4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 10 77 4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 10 78 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 13 80 5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 16 81 5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 17 82 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 17 83 6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 19 84 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 19 85 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 20 86 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 21 87 9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 21 88 9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 22 89 9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 22 90 9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 23 91 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 23 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 93 12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 24 94 13. Additional Information . . . . . . . . . . . . . . . . . . . . 24 95 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 97 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 27 99 1. Introduction 101 The SSH transport layer is a secure low level transport protocol. It 102 provides strong encryption, cryptographic host authentication, and 103 integrity protection. 105 Authentication in this protocol level is host-based; this protocol 106 does not perform user authentication. A higher level protocol for 107 user authentication can be designed on top of this protocol. 109 The protocol has been designed to be simple, flexible, to allow 110 parameter negotiation, and to minimize the number of round-trips. 111 Key exchange method, public key algorithm, symmetric encryption 112 algorithm, message authentication algorithm, and hash algorithm are 113 all negotiated. It is expected that in most environments, only 2 114 round-trips will be needed for full key exchange, server 115 authentication, service request, and acceptance notification of 116 service request. The worst case is 3 round-trips. 118 2. Conventions Used in This Document 120 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 121 and "MAY" that appear in this document are to be interpreted as 122 described in [RFC2119] 124 The used data types and terminology are specified in the architecture 125 document [SSH-ARCH] 127 The architecture document also discusses the algorithm naming 128 conventions that MUST be used with the SSH protocols. 130 3. Connection Setup 132 SSH works over any 8-bit clean, binary-transparent transport. The 133 underlying transport SHOULD protect against transmission errors as 134 such errors cause the SSH connection to terminate. 136 The client initiates the connection. 138 3.1 Use over TCP/IP 140 When used over TCP/IP, the server normally listens for connections on 141 port 22. This port number has been registered with the IANA, and has 142 been officially assigned for SSH. 144 3.2 Protocol Version Exchange 146 When the connection has been established, both sides MUST send an 147 identification string of the form "SSH-protoversion-softwareversion 148 comments", followed by carriage return and newline characters (ASCII 149 13 and 10, respectively). Both sides MUST be able to process 150 identification strings without carriage return character. No null 151 character is sent. The maximum length of the string is 255 152 characters, including the carriage return and newline. 154 The part of the identification string preceding carriage return and 155 newline is used in the Diffie-Hellman key exchange (see Section 156 Section 6). 158 The server MAY send other lines of data before sending the version 159 string. Each line SHOULD be terminated by a carriage return and 160 newline. Such lines MUST NOT begin with "SSH-", and SHOULD be 161 encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). 162 Clients MUST be able to process such lines; they MAY be silently 163 ignored, or MAY be displayed to the client user; if they are 164 displayed, control character filtering discussed in [SSH-ARCH] SHOULD 165 be used. The primary use of this feature is to allow TCP-wrappers to 166 display an error message before disconnecting. 168 Version strings MUST consist of printable US-ASCII characters, not 169 including whitespaces or a minus sign (-). The version string is 170 primarily used to trigger compatibility extensions and to indicate 171 the capabilities of an implementation. The comment string should 172 contain additional information that might be useful in solving user 173 problems. 175 The protocol version described in this document is 2.0. 177 Key exchange will begin immediately after sending this identifier. 178 All packets following the identification string SHALL use the binary 179 packet protocol, to be described below. 181 3.3 Compatibility With Old SSH Versions 183 During the transition period, it is important to be able to work in a 184 way that is compatible with the installed SSH clients and servers 185 that use an older version of the protocol. Information in this 186 section is only relevant for implementations supporting compatibility 187 with SSH versions 1.x. 189 3.4 Old Client, New Server 191 Server implementations MAY support a configurable "compatibility" 192 flag that enables compatibility with old versions. When this flag is 193 on, the server SHOULD identify its protocol version as "1.99". 194 Clients using protocol 2.0 MUST be able to identify this as identical 195 to "2.0". In this mode the server SHOULD NOT send the carriage 196 return character (ASCII 13) after the version identification string. 198 In the compatibility mode the server SHOULD NOT send any further data 199 after its initialization string until it has received an 200 identification string from the client. The server can then determine 201 whether the client is using an old protocol, and can revert to the 202 old protocol if required. In the compatibility mode, the server MUST 203 NOT send additional data before the version string. 205 When compatibility with old clients is not needed, the server MAY 206 send its initial key exchange data immediately after the 207 identification string. 209 3.5 New Client, Old Server 211 Since the new client MAY immediately send additional data after its 212 identification string (before receiving server's identification), the 213 old protocol may already have been corrupted when the client learns 214 that the server is old. When this happens, the client SHOULD close 215 the connection to the server, and reconnect using the old protocol. 217 4. Binary Packet Protocol 219 Each packet is in the following format: 221 uint32 packet_length 222 byte padding_length 223 byte[n1] payload; n1 = packet_length - padding_length - 1 224 byte[n2] random padding; n2 = padding_length 225 byte[m] mac (message authentication code); m = mac_length 227 packet_length 228 The length of the packet (bytes), not including MAC or the 229 packet_length field itself. 231 padding_length 232 Length of padding (bytes). 234 payload 235 The useful contents of the packet. If compression has been 236 negotiated, this field is compressed. Initially, compression 237 MUST be "none". 239 random padding 240 Arbitrary-length padding, such that the total length of 241 (packet_length || padding_length || payload || padding) is a 242 multiple of the cipher block size or 8, whichever is larger. 244 There MUST be at least four bytes of padding. The padding 245 SHOULD consist of random bytes. The maximum amount of padding 246 is 255 bytes. 248 mac 249 Message authentication code. If message authentication has 250 been negotiated, this field contains the MAC bytes. Initially, 251 the MAC algorithm MUST be "none". 253 Note that length of the concatenation of packet length, padding 254 length, payload, and padding MUST be a multiple of the cipher block 255 size or 8, whichever is larger. This constraint MUST be enforced 256 even when using stream ciphers. Note that the packet length field is 257 also encrypted, and processing it requires special care when sending 258 or receiving packets. 260 The minimum size of a packet is 16 (or the cipher block size, 261 whichever is larger) bytes (plus MAC); implementations SHOULD decrypt 262 the length after receiving the first 8 (or cipher block size, 263 whichever is larger) bytes of a packet. 265 4.1 Maximum Packet Length 267 All implementations MUST be able to process packets with uncompressed 268 payload length of 32768 bytes or less and total packet size of 35000 269 bytes or less (including length, padding length, payload, padding, 270 and MAC.). The maximum of 35000 bytes is an arbitrary chosen value 271 larger than uncompressed size. Implementations SHOULD support longer 272 packets, where they might be needed, e.g. if an implementation wants 273 to send a very large number of certificates. Such packets MAY be 274 sent if the version string indicates that the other party is able to 275 process them. However, implementations SHOULD check that the packet 276 length is reasonable for the implementation to avoid denial-of- 277 service and/or buffer overflow attacks. 279 4.2 Compression 281 If compression has been negotiated, the payload field (and only it) 282 will be compressed using the negotiated algorithm. The length field 283 and MAC will be computed from the compressed payload. Encryption 284 will be done after compression. 286 Compression MAY be stateful, depending on the method. Compression 287 MUST be independent for each direction, and implementations MUST 288 allow independently choosing the algorithm for each direction. 290 The following compression methods are currently defined: 292 none REQUIRED no compression 293 zlib OPTIONAL ZLIB (LZ77) compression 295 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 296 The compression context is initialized after each key exchange, and 297 is passed from one packet to the next with only a partial flush being 298 performed at the end of each packet. A partial flush means that the 299 current compressed block is ended and all data will be output. If 300 the current block is not a stored block, one or more empty blocks are 301 added after the current block to ensure that there are at least 8 302 bits counting from the start of the end-of-block code of the current 303 block to the end of the packet payload. 305 Additional methods may be defined as specified in [SSH-ARCH]. 307 4.3 Encryption 309 An encryption algorithm and a key will be negotiated during the key 310 exchange. When encryption is in effect, the packet length, padding 311 length, payload and padding fields of each packet MUST be encrypted 312 with the given algorithm. 314 The encrypted data in all packets sent in one direction SHOULD be 315 considered a single data stream. For example, initialization vectors 316 SHOULD be passed from the end of one packet to the beginning of the 317 next packet. All ciphers SHOULD use keys with an effective key 318 length of 128 bits or more. 320 The ciphers in each direction MUST run independently of each other, 321 and implementations MUST allow independently choosing the algorithm 322 for each direction (if multiple algorithms are allowed by local 323 policy). 325 The following ciphers are currently defined: 327 3des-cbc REQUIRED three-key 3DES in CBC mode 328 blowfish-cbc RECOMMENDED Blowfish in CBC mode 329 twofish256-cbc OPTIONAL Twofish in CBC mode, 330 with 256-bit key 331 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 332 is being retained for 333 historical reasons) 334 twofish192-cbc OPTIONAL Twofish with 192-bit key 335 twofish128-cbc RECOMMENDED Twofish with 128-bit key 336 aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, 337 with 256-bit key 338 aes192-cbc OPTIONAL AES with 192-bit key 339 aes128-cbc RECOMMENDED AES with 128-bit key 340 serpent256-cbc OPTIONAL Serpent in CBC mode, with 341 256-bit key 342 serpent192-cbc OPTIONAL Serpent with 192-bit key 343 serpent128-cbc OPTIONAL Serpent with 128-bit key 344 arcfour OPTIONAL the ARCFOUR stream cipher 345 idea-cbc OPTIONAL IDEA in CBC mode 346 cast128-cbc OPTIONAL CAST-128 in CBC mode 347 none OPTIONAL no encryption; NOT RECOMMENDED 349 The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt- 350 encrypt), where the first 8 bytes of the key are used for the first 351 encryption, the next 8 bytes for the decryption, and the following 8 352 bytes for the final encryption. This requires 24 bytes of key data 353 (of which 168 bits are actually used). To implement CBC mode, outer 354 chaining MUST be used (i.e., there is only one initialization 355 vector). This is a block cipher with 8 byte blocks. This algorithm 356 is defined in [SCHNEIER] 358 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 359 [SCHNEIER]. This is a block cipher with 8 byte blocks. 361 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 362 with 256 bit keys as described [TWOFISH]. This is a block cipher 363 with 16 byte blocks. 365 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 367 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 369 The "aes256-cbc" cipher is AES (Advanced Encryption Standard), 370 formerly Rijndael, in CBC mode. This version uses 256-bit key. 372 The "aes192-cbc" cipher. Same as above but with 192-bit key. 374 The "aes128-cbc" cipher. Same as above but with 128-bit key. 376 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as 377 described in the Serpent AES submission. 379 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 381 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 383 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 384 Arcfour cipher is believed to be compatible with the RC4 cipher 385 [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. 386 Arcfour (and RC4) has problems with weak keys, and should be used 387 with caution. 389 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 390 IDEA is patented by Ascom AG. 392 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 393 [RFC2144]. 395 The "none" algorithm specifies that no encryption is to be done. 396 Note that this method provides no confidentiality protection, and it 397 is not recommended. Some functionality (e.g. password 398 authentication) may be disabled for security reasons if this cipher 399 is chosen. 401 Additional methods may be defined as specified in [SSH-ARCH]. 403 4.4 Data Integrity 405 Data integrity is protected by including with each packet a message 406 authentication code (MAC) that is computed from a shared secret, 407 packet sequence number, and the contents of the packet. 409 The message authentication algorithm and key are negotiated during 410 key exchange. Initially, no MAC will be in effect, and its length 411 MUST be zero. After key exchange, the selected MAC will be computed 412 before encryption from the concatenation of packet data: 414 mac = MAC(key, sequence_number || unencrypted_packet) 416 where unencrypted_packet is the entire packet without MAC (the length 417 fields, payload and padding), and sequence_number is an implicit 418 packet sequence number represented as uint32. The sequence number is 419 initialized to zero for the first packet, and is incremented after 420 every packet (regardless of whether encryption or MAC is in use). It 421 is never reset, even if keys/algorithms are renegotiated later. It 422 wraps around to zero after every 2^32 packets. The packet sequence 423 number itself is not included in the packet sent over the wire. 425 The MAC algorithms for each direction MUST run independently, and 426 implementations MUST allow choosing the algorithm independently for 427 both directions. 429 The MAC bytes resulting from the MAC algorithm MUST be transmitted 430 without encryption as the last part of the packet. The number of MAC 431 bytes depends on the algorithm chosen. 433 The following MAC algorithms are currently defined: 435 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 436 length = 20) 437 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 438 length = 12, key length = 20) 439 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 440 length = 16) 441 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 442 length = 12, key length = 16) 443 none OPTIONAL no MAC; NOT RECOMMENDED 445 The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use 446 only the first n bits of the resulting value. 448 The hash algorithms are described in [SCHNEIER]. 450 Additional methods may be defined as specified in [SSH-ARCH]. 452 4.5 Key Exchange Methods 454 The key exchange method specifies how one-time session keys are 455 generated for encryption and for authentication, and how the server 456 authentication is done. 458 Only one REQUIRED key exchange method has been defined: 460 diffie-hellman-group1-sha1 REQUIRED 462 This method is described later in this document. 464 Additional methods may be defined as specified in [SSH-ARCH]. 466 4.6 Public Key Algorithms 468 This protocol has been designed to be able to operate with almost any 469 public key format, encoding, and algorithm (signature and/or 470 encryption). 472 There are several aspects that define a public key type: 473 o Key format: how is the key encoded and how are certificates 474 represented. The key blobs in this protocol MAY contain 475 certificates in addition to keys. 476 o Signature and/or encryption algorithms. Some key types may not 477 support both signing and encryption. Key usage may also be 478 restricted by policy statements in e.g. certificates. In this 479 case, different key types SHOULD be defined for the different 480 policy alternatives. 482 o Encoding of signatures and/or encrypted data. This includes but 483 is not limited to padding, byte order, and data formats. 485 The following public key and/or certificate formats are currently defined: 487 ssh-dss REQUIRED sign Simple DSS 488 ssh-rsa RECOMMENDED sign Simple RSA 489 x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) 490 x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) 491 spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) 492 spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) 493 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 494 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 496 Additional key types may be defined as specified in [SSH-ARCH]. 498 The key type MUST always be explicitly known (from algorithm 499 negotiation or some other source). It is not normally included in 500 the key blob. 502 Certificates and public keys are encoded as follows: 504 string certificate or public key format identifier 505 byte[n] key/certificate data 507 The certificate part may have be a zero length string, but a public 508 key is required. This is the public key that will be used for 509 authentication; the certificate sequence contained in the certificate 510 blob can be used to provide authorization. 512 Public key / certifcate formats that do not explicitly specify a 513 signature format identifier MUST use the public key / certificate 514 format identifier as the signature identifier. 516 Signatures are encoded as follows: 517 string signature format identifier (as specified by the 518 public key / cert format) 519 byte[n] signature blob in format specific encoding. 521 The "ssh-dss" key format has the following specific encoding: 523 string "ssh-dss" 524 mpint p 525 mpint q 526 mpint g 527 mpint y 529 Here the p, q, g, and y parameters form the signature key blob. 531 Signing and verifying using this key format is done according to the 532 Digital Signature Standard [FIPS-186] using the SHA-1 hash. A 533 description can also be found in [SCHNEIER]. 535 The resulting signature is encoded as follows: 537 string "ssh-dss" 538 string dss_signature_blob 540 dss_signature_blob is encoded as a string containing r followed by s 541 (which are 160 bits long integers, without lengths or padding, 542 unsigned and in network byte order). 544 The "ssh-rsa" key format has the following specific encoding: 546 string "ssh-rsa" 547 mpint e 548 mpint n 550 Here the e and n parameters form the signature key blob. 552 Signing and verifying using this key format is done according to 553 [SCHNEIER] and [PKCS1] using the SHA-1 hash. 555 The resulting signature is encoded as follows: 557 string "ssh-rsa" 558 string rsa_signature_blob 560 rsa_signature_blob is encoded as a string containing s (which is an 561 integer, without lengths or padding, unsigned and in network byte 562 order). 564 The "spki-sign-rsa" method indicates that the certificate blob 565 contains a sequence of SPKI certificates. The format of SPKI 566 certificates is described in [RFC2693]. This method indicates that 567 the key (or one of the keys in the certificate) is an RSA-key. 569 The "spki-sign-dss". As above, but indicates that the key (or one of 570 the keys in the certificate) is a DSS-key. 572 The "pgp-sign-rsa" method indicates the certificates, the public key, 573 and the signature are in OpenPGP compatible binary format 574 ([RFC2440]). This method indicates that the key is an RSA-key. 576 The "pgp-sign-dss". As above, but indicates that the key is a DSS- 577 key. 579 5. Key Exchange 581 Key exchange begins by each side sending lists of supported 582 algorithms. Each side has a preferred algorithm in each category, 583 and it is assumed that most implementations at any given time will 584 use the same preferred algorithm. Each side MAY guess which 585 algorithm the other side is using, and MAY send an initial key 586 exchange packet according to the algorithm if appropriate for the 587 preferred method. 589 Guess is considered wrong, if: 590 o the kex algorithm and/or the host key algorithm is guessed wrong 591 (server and client have different preferred algorithm), or 592 o if any of the other algorithms cannot be agreed upon (the 593 procedure is defined below in Section Section 5.1). 595 Otherwise, the guess is considered to be right and the optimistically 596 sent packet MUST be handled as the first key exchange packet. 598 However, if the guess was wrong, and a packet was optimistically sent 599 by one or both parties, such packets MUST be ignored (even if the 600 error in the guess would not affect the contents of the initial 601 packet(s)), and the appropriate side MUST send the correct initial 602 packet. 604 Server authentication in the key exchange MAY be implicit. After a 605 key exchange with implicit server authentication, the client MUST 606 wait for response to its service request message before sending any 607 further data. 609 5.1 Algorithm Negotiation 611 Key exchange begins by each side sending the following packet: 613 byte SSH_MSG_KEXINIT 614 byte[16] cookie (random bytes) 615 string kex_algorithms 616 string server_host_key_algorithms 617 string encryption_algorithms_client_to_server 618 string encryption_algorithms_server_to_client 619 string mac_algorithms_client_to_server 620 string mac_algorithms_server_to_client 621 string compression_algorithms_client_to_server 622 string compression_algorithms_server_to_client 623 string languages_client_to_server 624 string languages_server_to_client 625 boolean first_kex_packet_follows 626 uint32 0 (reserved for future extension) 628 Each of the algorithm strings MUST be a comma-separated list of 629 algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each 630 supported (allowed) algorithm MUST be listed in order of preference. 632 The first algorithm in each list MUST be the preferred (guessed) 633 algorithm. Each string MUST contain at least one algorithm name. 635 cookie 636 The cookie MUST be a random value generated by the sender. Its 637 purpose is to make it impossible for either side to fully 638 determine the keys and the session identifier. 640 kex_algorithms 641 Key exchange algorithms were defined above. The first 642 algorithm MUST be the preferred (and guessed) algorithm. If 643 both sides make the same guess, that algorithm MUST be used. 644 Otherwise, the following algorithm MUST be used to choose a key 645 exchange method: iterate over client's kex algorithms, one at a 646 time. Choose the first algorithm that satisfies the following 647 conditions: 648 + the server also supports the algorithm, 649 + if the algorithm requires an encryption-capable host key, 650 there is an encryption-capable algorithm on the server's 651 server_host_key_algorithms that is also supported by the 652 client, and 653 + if the algorithm requires a signature-capable host key, 654 there is a signature-capable algorithm on the server's 655 server_host_key_algorithms that is also supported by the 656 client. 657 + If no algorithm satisfying all these conditions can be 658 found, the connection fails, and both sides MUST disconnect. 660 server_host_key_algorithms 661 List of the algorithms supported for the server host key. The 662 server lists the algorithms for which it has host keys; the 663 client lists the algorithms that it is willing to accept. 664 (There MAY be multiple host keys for a host, possibly with 665 different algorithms.) 667 Some host keys may not support both signatures and encryption 668 (this can be determined from the algorithm), and thus not all 669 host keys are valid for all key exchange methods. 671 Algorithm selection depends on whether the chosen key exchange 672 algorithm requires a signature or encryption capable host key. 673 It MUST be possible to determine this from the public key 674 algorithm name. The first algorithm on the client's list that 675 satisfies the requirements and is also supported by the server 676 MUST be chosen. If there is no such algorithm, both sides MUST 677 disconnect. 679 encryption_algorithms 680 Lists the acceptable symmetric encryption algorithms in order 681 of preference. The chosen encryption algorithm to each 682 direction MUST be the first algorithm on the client's list 683 that is also on the server's list. If there is no such 684 algorithm, both sides MUST disconnect. 686 Note that "none" must be explicitly listed if it is to be 687 acceptable. The defined algorithm names are listed in Section 688 Section 4.3. 690 mac_algorithms 691 Lists the acceptable MAC algorithms in order of preference. 692 The chosen MAC algorithm MUST be the first algorithm on the 693 client's list that is also on the server's list. If there is 694 no such algorithm, both sides MUST disconnect. 696 Note that "none" must be explicitly listed if it is to be 697 acceptable. The MAC algorithm names are listed in Section 698 Figure 1. 700 compression_algorithms 701 Lists the acceptable compression algorithms in order of 702 preference. The chosen compression algorithm MUST be the first 703 algorithm on the client's list that is also on the server's 704 list. If there is no such algorithm, both sides MUST 705 disconnect. 707 Note that "none" must be explicitly listed if it is to be 708 acceptable. The compression algorithm names are listed in 709 Section Section 4.2. 711 languages 712 This is a comma-separated list of language tags in order of 713 preference [RFC1766]. Both parties MAY ignore this list. If 714 there are no language preferences, this list SHOULD be empty. 716 first_kex_packet_follows 717 Indicates whether a guessed key exchange packet follows. If a 718 guessed packet will be sent, this MUST be TRUE. If no guessed 719 packet will be sent, this MUST be FALSE. 721 After receiving the SSH_MSG_KEXINIT packet from the other side, 722 each party will know whether their guess was right. If the 723 other party's guess was wrong, and this field was TRUE, the 724 next packet MUST be silently ignored, and both sides MUST then 725 act as determined by the negotiated key exchange method. If 726 the guess was right, key exchange MUST continue using the 727 guessed packet. 729 After the KEXINIT packet exchange, the key exchange algorithm is run. 730 It may involve several packet exchanges, as specified by the key 731 exchange method. 733 5.2 Output from Key Exchange 735 The key exchange produces two values: a shared secret K, and an 736 exchange hash H. Encryption and authentication keys are derived from 737 these. The exchange hash H from the first key exchange is 738 additionally used as the session identifier, which is a unique 739 identifier for this connection. It is used by authentication methods 740 as a part of the data that is signed as a proof of possession of a 741 private key. Once computed, the session identifier is not changed, 742 even if keys are later re-exchanged. 744 Each key exchange method specifies a hash function that is used in 745 the key exchange. The same hash algorithm MUST be used in key 746 derivation. Here, we'll call it HASH. 748 Encryption keys MUST be computed as HASH of a known value and K as 749 follows: 750 o Initial IV client to server: HASH(K || H || "A" || session_id) 751 (Here K is encoded as mpint and "A" as byte and session_id as raw 752 data."A" means the single character A, ASCII 65). 753 o Initial IV server to client: HASH(K || H || "B" || session_id) 754 o Encryption key client to server: HASH(K || H || "C" || session_id) 755 o Encryption key server to client: HASH(K || H || "D" || session_id) 756 o Integrity key client to server: HASH(K || H || "E" || session_id) 757 o Integrity key server to client: HASH(K || H || "F" || session_id) 759 Key data MUST be taken from the beginning of the hash output. 128 760 bits (16 bytes) SHOULD be used for algorithms with variable-length 761 keys. For other algorithms, as many bytes as are needed are taken 762 from the beginning of the hash value. If the key length in longer 763 than the output of the HASH, the key is extended by computing HASH of 764 the concatenation of K and H and the entire key so far, and appending 765 the resulting bytes (as many as HASH generates) to the key. This 766 process is repeated until enough key material is available; the key 767 is taken from the beginning of this value. In other words: 769 K1 = HASH(K || H || X || session_id) (X is e.g. "A") 770 K2 = HASH(K || H || K1) 771 K3 = HASH(K || H || K1 || K2) 772 ... 773 key = K1 || K2 || K3 || ... 775 This process will lose entropy if the amount of entropy in K is 776 larger than the internal state size of HASH. 778 5.3 Taking Keys Into Use 780 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 781 This message is sent with the old keys and algorithms. All messages 782 sent after this message MUST use the new keys and algorithms. 784 When this message is received, the new keys and algorithms MUST be 785 taken into use for receiving. 787 This message is the only valid message after key exchange, in 788 addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE 789 messages. The purpose of this message is to ensure that a party is 790 able to respond with a disconnect message that the other party can 791 understand if something goes wrong with the key exchange. 792 Implementations MUST NOT accept any other messages after key exchange 793 before receiving SSH_MSG_NEWKEYS. 795 byte SSH_MSG_NEWKEYS 797 6. Diffie-Hellman Key Exchange 799 The Diffie-Hellman key exchange provides a shared secret that can not 800 be determined by either party alone. The key exchange is combined 801 with a signature with the host key to provide host authentication. 803 In the following description (C is the client, S is the server; p is 804 a large safe prime, g is a generator for a subgroup of GF(p), and q 805 is the order of the subgroup; V_S is S's version string; V_C is C's 806 version string; K_S is S's public host key; I_C is C's KEXINIT 807 message and I_S S's KEXINIT message which have been exchanged before 808 this part begins): 810 1. C generates a random number x (1 < x < q) and computes e = g^x 811 mod p. C sends "e" to S. 813 2. S generates a random number y (0 < y < q) and computes f = g^y 814 mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C 815 || V_S || I_C || I_S || K_S || e || f || K) (these elements are 816 encoded according to their types; see below), and signature s on 817 H with its private host key. S sends "K_S || f || s" to C. The 818 signing operation may involve a second hashing operation. 820 3. C verifies that K_S really is the host key for S (e.g. using 821 certificates or a local database). C is also allowed to accept 822 the key without verification; however, doing so will render the 823 protocol insecure against active attacks (but may be desirable 824 for practical reasons in the short term in many environments). C 825 then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || 826 K_S || e || f || K), and verifies the signature s on H. 828 Either side MUST NOT send or accept e or f values that are not in the 829 range [1, p-1]. If this condition is violated, the key exchange 830 fails. 832 This is implemented with the following messages. The hash algorithm 833 for computing the exchange hash is defined by the method name, and is 834 called HASH. The public key algorithm for signing is negotiated with 835 the KEXINIT messages. 837 First, the client sends the following: 839 byte SSH_MSG_KEXDH_INIT 840 mpint e 842 The server responds with the following: 844 byte SSH_MSG_KEXDH_REPLY 845 string server public host key and certificates (K_S) 846 mpint f 847 string signature of H 849 The hash H is computed as the HASH hash of the concatenation of the 850 following: 852 string V_C, the client's version string (CR and NL excluded) 853 string V_S, the server's version string (CR and NL excluded) 854 string I_C, the payload of the client's SSH_MSG_KEXINIT 855 string I_S, the payload of the server's SSH_MSG_KEXINIT 856 string K_S, the host key 857 mpint e, exchange value sent by the client 858 mpint f, exchange value sent by the server 859 mpint K, the shared secret 861 This value is called the exchange hash, and it is used to 862 authenticate the key exchange. The exchange hash SHOULD be kept 863 secret. 865 The signature algorithm MUST be applied over H, not the original 866 data. Most signature algorithms include hashing and additional 867 padding. For example, "ssh-dss" specifies SHA-1 hashing; in that 868 case, the data is first hashed with HASH to compute H, and H is then 869 hashed with SHA-1 as part of the signing operation. 871 6.1 diffie-hellman-group1-sha1 873 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 874 exchange with SHA-1 as HASH, and the following group: 876 The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + 877 129093 ). Its hexadecimal value is: 879 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 880 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 881 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 882 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 883 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 884 FFFFFFFF FFFFFFFF. 886 In decimal, this value is: 888 179769313486231590770839156793787453197860296048756011706444 889 423684197180216158519368947833795864925541502180565485980503 890 646440548199239100050792877003355816639229553136239076508735 891 759914822574862575007425302077447712589550957937778424442426 892 617334727629299387668709205606050270810842907692932019128194 893 467627007. 895 The generator used with this prime is g = 2. The group order q is (p 896 - 1) / 2. 898 This group was taken from the ISAKMP/Oakley specification, and was 899 originally generated by Richard Schroeppel at the University of 900 Arizona. Properties of this prime are described in [Orm96]. 902 7. Key Re-Exchange 904 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when 905 not already doing a key exchange (as described in Section Section 906 5.1). When this message is received, a party MUST respond with its 907 own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT 908 already was a reply. Either party MAY initiate the re-exchange, but 909 roles MUST NOT be changed (i.e., the server remains the server, and 910 the client remains the client). 912 Key re-exchange is performed using whatever encryption was in effect 913 when the exchange was started. Encryption, compression, and MAC 914 methods are not changed before a new SSH_MSG_NEWKEYS is sent after 915 the key exchange (as in the initial key exchange). Re-exchange is 916 processed identically to the initial key exchange, except for the 917 session identifier that will remain unchanged. It is permissible to 918 change some or all of the algorithms during the re-exchange. Host 919 keys can also change. All keys and initialization vectors are 920 recomputed after the exchange. Compression and encryption contexts 921 are reset. 923 It is recommended that the keys are changed after each gigabyte of 924 transmitted data or after each hour of connection time, whichever 925 comes sooner. However, since the re-exchange is a public key 926 operation, it requires a fair amount of processing power and should 927 not be performed too often. 929 More application data may be sent after the SSH_MSG_NEWKEYS packet 930 has been sent; key exchange does not affect the protocols that lie 931 above the SSH transport layer. 933 8. Service Request 935 After the key exchange, the client requests a service. The service 936 is identified by a name. The format of names and procedures for 937 defining new names are defined in [SSH-ARCH]. 939 Currently, the following names have been reserved: 941 ssh-userauth 942 ssh-connection 944 Similar local naming policy is applied to the service names, as is 945 applied to the algorithm names; a local service should use the 946 "servicename@domain" syntax. 948 byte SSH_MSG_SERVICE_REQUEST 949 string service name 951 If the server rejects the service request, it SHOULD send an 952 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 954 When the service starts, it may have access to the session identifier 955 generated during the key exchange. 957 If the server supports the service (and permits the client to use 958 it), it MUST respond with the following: 960 byte SSH_MSG_SERVICE_ACCEPT 961 string service name 963 Message numbers used by services should be in the area reserved for 964 them (see Section 6 in [SSH-ARCH]). The transport level will 965 continue to process its own messages. 967 Note that after a key exchange with implicit server authentication, 968 the client MUST wait for response to its service request message 969 before sending any further data. 971 9. Additional Messages 973 Either party may send any of the following messages at any time. 975 9.1 Disconnection Message 977 byte SSH_MSG_DISCONNECT 978 uint32 reason code 979 string description [RFC2279] 980 string language tag [RFC1766] 982 This message causes immediate termination of the connection. All 983 implementations MUST be able to process this message; they SHOULD be 984 able to send this message. 986 The sender MUST NOT send or receive any data after this message, and 987 the recipient MUST NOT accept any data after receiving this message. 988 The description field gives a more specific explanation in a human- 989 readable form. The error code gives the reason in a more machine- 990 readable format (suitable for localization), and can have the 991 following values: 993 #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 994 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 995 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 996 #define SSH_DISCONNECT_RESERVED 4 997 #define SSH_DISCONNECT_MAC_ERROR 5 998 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 999 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1000 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1001 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1002 #define SSH_DISCONNECT_CONNECTION_LOST 10 1003 #define SSH_DISCONNECT_BY_APPLICATION 11 1004 #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1005 #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1006 #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1007 #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1009 If the description string is displayed, control character filtering 1010 discussed in [SSH-ARCH] should be used to avoid attacks by sending 1011 terminal control characters. 1013 9.2 Ignored Data Message 1015 byte SSH_MSG_IGNORE 1016 string data 1018 All implementations MUST understand (and ignore) this message at any 1019 time (after receiving the protocol version). No implementation is 1020 required to send them. This message can be used as an additional 1021 protection measure against advanced traffic analysis techniques. 1023 9.3 Debug Message 1025 byte SSH_MSG_DEBUG 1026 boolean always_display 1027 string message [RFC2279] 1028 string language tag [RFC1766] 1030 All implementations MUST understand this message, but they are 1031 allowed to ignore it. This message is used to pass the other side 1032 information that may help debugging. If always_display is TRUE, the 1033 message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed 1034 unless debugging information has been explicitly requested by the 1035 user. 1037 The message doesn't need to contain a newline. It is, however, 1038 allowed to consist of multiple lines separated by CRLF (Carriage 1039 Return - Line Feed) pairs. 1041 If the message string is displayed, terminal control character 1042 filtering discussed in [SSH-ARCH] should be used to avoid attacks by 1043 sending terminal control characters. 1045 9.4 Reserved Messages 1047 An implementation MUST respond to all unrecognized messages with an 1048 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1049 received. Such messages MUST be otherwise ignored. Later protocol 1050 versions may define other meanings for these message types. 1052 byte SSH_MSG_UNIMPLEMENTED 1053 uint32 packet sequence number of rejected message 1055 10. Summary of Message Numbers 1057 The following message numbers have been defined in this protocol: 1059 #define SSH_MSG_DISCONNECT 1 1060 #define SSH_MSG_IGNORE 2 1061 #define SSH_MSG_UNIMPLEMENTED 3 1062 #define SSH_MSG_DEBUG 4 1063 #define SSH_MSG_SERVICE_REQUEST 5 1064 #define SSH_MSG_SERVICE_ACCEPT 6 1066 #define SSH_MSG_KEXINIT 20 1067 #define SSH_MSG_NEWKEYS 21 1069 /* Numbers 30-49 used for kex packets. 1070 Different kex methods may reuse message numbers in 1071 this range. */ 1073 #define SSH_MSG_KEXDH_INIT 30 1074 #define SSH_MSG_KEXDH_REPLY 31 1076 11. Security Considerations 1078 This protocol provides a secure encrypted channel over an insecure 1079 network. It performs server host authentication, key exchange, 1080 encryption, and integrity protection. It also derives a unique 1081 session id that may be used by higher-level protocols. 1083 It is expected that this protocol will sometimes be used without 1084 insisting on reliable association between the server host key and the 1085 server host name. Such use is inherently insecure, but may be 1086 necessary in non-security critical environments, and still provides 1087 protection against passive attacks. However, implementors of 1088 protocols running on top of this protocol should keep this 1089 possibility in mind. 1091 This protocol is designed to be used over a reliable transport. If 1092 transmission errors or message manipulation occur, the connection is 1093 closed. The connection SHOULD be re-established if this occurs. 1094 Denial of service attacks of this type ("wire cutter") are almost 1095 impossible to avoid. 1097 The protocol was not designed to eliminate covert channels. For 1098 example, the padding, SSH_MSG_IGNORE messages, and several other 1099 places in the protocol can be used to pass covert information, and 1100 the recipient has no reliable way to verify whether such information 1101 is being sent. 1103 12. Trademark Issues 1105 As of this writing, SSH Communications Security Oy claims ssh as its 1106 trademark. As with all IPR claims the IETF takes no position 1107 regarding the validity or scope of this trademark claim. 1109 13. Additional Information 1111 The current document editor is: Darren.Moffat@Sun.COM. Comments on 1112 this internet draft should be sent to the IETF SECSH working group, 1113 details at: http://ietf.org/html.charters/secsh-charter.html 1115 References 1117 [FIPS-186] Federal Information Processing Standards Publication, 1118 ., "FIPS PUB 186, Digital Signature Standard", May 1119 1994. 1121 [Orm96] Orman, H., "The Okaley Key Determination Protcol 1122 version1, TR97-92", 1996. 1124 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, 1125 "Internet X.509 Public Key Infrastructure Certificate 1126 and CRL Profile", RFC 2459, January 1999. 1128 [RFC1034] Mockapetris, P., "Domain names - concepts and 1129 facilities", STD 13, RFC 1034, Nov 1987. 1131 [RFC1766] Alvestrand, H., "Tags for the Identification of 1132 Languages", RFC 1766, March 1995. 1134 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data 1135 Format Specification version 3.3", RFC 1950, May 1136 1996. 1138 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 1139 Specification version 1.3", RFC 1951, May 1996. 1141 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 1142 10646", RFC 2279, January 1998. 1144 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1145 Keyed-Hashing for Message Authentication", RFC 2104, 1146 February 1997. 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, March 1997. 1151 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 1152 2144, May 1997. 1154 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. 1155 Thayer, "OpenPGP Message Format", RFC 2440, November 1156 1998. 1158 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., 1159 Thomas, B. and T. Ylonen, "SPKI Certificate Theory", 1160 RFC 2693, September 1999. 1162 [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: 1163 protocols algorithms and source in code in C", 1996. 1165 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1166 128-Bit Block Cipher, 1st Edition", March 1999. 1168 [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- 1169 ietf-architecture-12.txt, July 2001. 1171 [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D 1172 draft-ietf-transport-13.txt, July 2001. 1174 [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- 1175 ietf-userauth-15.txt, July 2001. 1177 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- 1178 ietf-connect-15.txt, July 2001. 1180 Authors' Addresses 1182 Tatu Ylonen 1183 SSH Communications Security Corp 1184 Fredrikinkatu 42 1185 HELSINKI FIN-00100 1186 Finland 1188 EMail: ylo@ssh.com 1190 Tero Kivinen 1191 SSH Communications Security Corp 1192 Fredrikinkatu 42 1193 HELSINKI FIN-00100 1194 Finland 1196 EMail: kivinen@ssh.com 1198 Markku-Juhani O. Saarinen 1199 University of Jyvaskyla 1201 Timo J. Rinne 1202 SSH Communications Security Corp 1203 Fredrikinkatu 42 1204 HELSINKI FIN-00100 1205 Finland 1207 EMail: tri@ssh.com 1209 Sami Lehtinen 1210 SSH Communications Security Corp 1211 Fredrikinkatu 42 1212 HELSINKI FIN-00100 1213 Finland 1215 EMail: sjl@ssh.com 1217 Full Copyright Statement 1219 Copyright (C) The Internet Society (2002). All Rights Reserved. 1221 This document and translations of it may be copied and furnished to 1222 others, and derivative works that comment on or otherwise explain it 1223 or assist in its implementation may be prepared, copied, published 1224 and distributed, in whole or in part, without restriction of any 1225 kind, provided that the above copyright notice and this paragraph are 1226 included on all such copies and derivative works. However, this 1227 document itself may not be modified in any way, such as by removing 1228 the copyright notice or references to the Internet Society or other 1229 Internet organizations, except as needed for the purpose of 1230 developing Internet standards in which case the procedures for 1231 copyrights defined in the Internet Standards process must be 1232 followed, or as required to translate it into languages other than 1233 English. 1235 The limited permissions granted above are perpetual and will not be 1236 revoked by the Internet Society or its successors or assigns. 1238 This document and the information contained herein is provided on an 1239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1241 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1242 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1243 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1245 Acknowledgement 1247 Funding for the RFC Editor function is currently provided by the 1248 Internet Society.