idnits 2.17.1 draft-ietf-secsh-transport-16.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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11. Security Considerations' ) ** 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.) ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 129: '...conventions that MUST be used with the...' RFC 2119 keyword, line 134: '...rlying transport SHOULD protect agains...' RFC 2119 keyword, line 147: '...n established, both sides MUST send an...' RFC 2119 keyword, line 150: '...10, respectively). Both sides MUST be...' RFC 2119 keyword, line 160: '... The server MAY send other lines ...' (135 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 511 has weird spacing: '... string cert...' == Line 524 has weird spacing: '... string sig...' == Line 545 has weird spacing: '... string dss...' == Line 565 has weird spacing: '... string rsa...' == Line 625 has weird spacing: '... string kex...' == (21 more instances...) -- 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 (July 14, 2003) is 7585 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 section? 'RFC2119' on line 1175 looks like a reference -- Missing reference section? 'SSH-ARCH' on line 1197 looks like a reference -- Missing reference section? 'RFC2279' on line 1168 looks like a reference -- Missing reference section? 'RFC1950' on line 1161 looks like a reference -- Missing reference section? 'RFC1951' on line 1165 looks like a reference -- Missing reference section? 'SCHNEIER' on line 1190 looks like a reference -- Missing reference section? 'TWOFISH' on line 1194 looks like a reference -- Missing reference section? 'RFC2144' on line 1179 looks like a reference -- Missing reference section? 'RFC2104' on line 1171 looks like a reference -- Missing reference section? 'FIPS-186' on line 1143 looks like a reference -- Missing reference section? 'PKCS1' on line 560 looks like a reference -- Missing reference section? 'RFC2693' on line 1186 looks like a reference -- Missing reference section? 'RFC2440' on line 1182 looks like a reference -- Missing reference section? '16' on line 624 looks like a reference -- Missing reference section? 'RFC1766' on line 1158 looks like a reference -- Missing reference section? 'Orm96' on line 1147 looks like a reference -- Missing reference section? 'RFC2459' on line 1150 looks like a reference -- Missing reference section? 'RFC1034' on line 1155 looks like a reference -- Missing reference section? 'SSH-TRANS' on line 1200 looks like a reference -- Missing reference section? 'SSH-USERAUTH' on line 1203 looks like a reference -- Missing reference section? 'SSH-CONNECT' on line 1206 looks like a reference -- Missing reference section? 'SSH-NUMBERS' on line 1209 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 25 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: January 12, 2004 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 July 14, 2003 12 SSH Transport Layer Protocol 13 draft-ietf-secsh-transport-16.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 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 12, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 SSH is a protocol for secure remote login and other secure network 46 services over an insecure network. 48 This document describes the SSH transport layer protocol which 49 typically runs on top of TCP/IP. The protocol can be used as a 50 basis for a number of secure network services. It provides strong 51 encryption, server authentication, and integrity protection. It 52 may also provide compression. 54 Key exchange method, public key algorithm, symmetric encryption 55 algorithm, message authentication algorithm, and hash algorithm 56 are all negotiated. 58 This document also describes the Diffie-Hellman key exchange 59 method and the minimal set of algorithms that are needed to 60 implement the SSH transport layer protocol. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 66 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 4 69 3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 5 70 3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 5 71 3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 6 72 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 6 73 4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 7 74 4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 11 78 4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 11 79 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 14 81 5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 17 82 5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 18 83 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 19 84 6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 20 85 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 86 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 22 87 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 22 88 9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 23 89 9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 23 90 9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 24 91 9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 24 92 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 24 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 25 95 13. Additional Information . . . . . . . . . . . . . . . . . . . . 25 96 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 98 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 29 100 1. Introduction 102 The SSH transport layer is a secure low level transport protocol. 103 It provides strong encryption, cryptographic host authentication, 104 and integrity protection. 106 Authentication in this protocol level is host-based; this protocol 107 does not perform user authentication. A higher level protocol for 108 user authentication can be designed on top of this protocol. 110 The protocol has been designed to be simple, flexible, to allow 111 parameter negotiation, and to minimize the number of round-trips. 112 Key exchange method, public key algorithm, symmetric encryption 113 algorithm, message authentication algorithm, and hash algorithm 114 are all negotiated. It is expected that in most environments, 115 only 2 round-trips will be needed for full key exchange, server 116 authentication, service request, and acceptance notification of 117 service request. The worst case is 3 round-trips. 119 2. Conventions Used in This Document 121 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 122 NOT", and "MAY" that appear in this document are to be interpreted 123 as described in [RFC2119] 125 The used data types and terminology are specified in the 126 architecture document [SSH-ARCH] 128 The architecture document also discusses the algorithm naming 129 conventions that MUST be used with the SSH protocols. 131 3. Connection Setup 133 SSH works over any 8-bit clean, binary-transparent transport. The 134 underlying transport SHOULD protect against transmission errors as 135 such errors cause the SSH connection to terminate. 137 The client initiates the connection. 139 3.1 Use over TCP/IP 141 When used over TCP/IP, the server normally listens for connections 142 on port 22. This port number has been registered with the IANA, 143 and has been officially assigned for SSH. 145 3.2 Protocol Version Exchange 147 When the connection has been established, both sides MUST send an 148 identification string of the form "SSH-protoversion- 149 softwareversion comments", followed by carriage return and newline 150 characters (ASCII 13 and 10, respectively). Both sides MUST be 151 able to process identification strings without carriage return 152 character. No null character is sent. The maximum length of the 153 string is 255 characters, including the carriage return and 154 newline. 156 The part of the identification string preceding carriage return 157 and newline is used in the Diffie-Hellman key exchange (see 158 Section Section 6). 160 The server MAY send other lines of data before sending the version 161 string. Each line SHOULD be terminated by a carriage return and 162 newline. Such lines MUST NOT begin with "SSH-", and SHOULD be 163 encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). 164 Clients MUST be able to process such lines; they MAY be silently 165 ignored, or MAY be displayed to the client user; if they are 166 displayed, control character filtering discussed in [SSH-ARCH] 167 SHOULD be used. The primary use of this feature is to allow TCP- 168 wrappers to display an error message before disconnecting. 170 Version strings MUST consist of printable US-ASCII characters, not 171 including whitespaces or a minus sign (-). The version string is 172 primarily used to trigger compatibility extensions and to indicate 173 the capabilities of an implementation. The comment string should 174 contain additional information that might be useful in solving 175 user problems. 177 The protocol version described in this document is 2.0. 179 Key exchange will begin immediately after sending this identifier. 180 All packets following the identification string SHALL use the 181 binary packet protocol, to be described below. 183 3.3 Compatibility With Old SSH Versions 185 During the transition period, it is important to be able to work 186 in a way that is compatible with the installed SSH clients and 187 servers that use an older version of the protocol. Information in 188 this section is only relevant for implementations supporting 189 compatibility with SSH versions 1.x. 191 3.4 Old Client, New Server 193 Server implementations MAY support a configurable "compatibility" 194 flag that enables compatibility with old versions. When this flag 195 is on, the server SHOULD identify its protocol version as "1.99". 197 Clients using protocol 2.0 MUST be able to identify this as 198 identical to "2.0". In this mode the server SHOULD NOT send the 199 carriage return character (ASCII 13) after the version 200 identification string. 202 In the compatibility mode the server SHOULD NOT send any further 203 data after its initialization string until it has received an 204 identification string from the client. The server can then 205 determine whether the client is using an old protocol, and can 206 revert to the old protocol if required. In the compatibility 207 mode, the server MUST NOT send additional data before the version 208 string. 210 When compatibility with old clients is not needed, the server MAY 211 send its initial key exchange data immediately after the 212 identification string. 214 3.5 New Client, Old Server 216 Since the new client MAY immediately send additional data after 217 its identification string (before receiving server's 218 identification), the old protocol may already have been corrupted 219 when the client learns that the server is old. When this happens, 220 the client SHOULD close the connection to the server, and 221 reconnect using the old protocol. 223 4. Binary Packet Protocol 225 Each packet is in the following format: 227 uint32 packet_length 228 byte padding_length 229 byte[n1] payload; n1 = packet_length - padding_length - 1 230 byte[n2] random padding; n2 = padding_length 231 byte[m] mac (message authentication code); m = mac_length 233 packet_length 234 The length of the packet (bytes), not including MAC or the 235 packet_length field itself. 237 padding_length 238 Length of padding (bytes). 240 payload 241 The useful contents of the packet. If compression has been 242 negotiated, this field is compressed. Initially, 243 compression MUST be "none". 245 random padding 246 Arbitrary-length padding, such that the total length of 247 (packet_length || padding_length || payload || padding) is a 248 multiple of the cipher block size or 8, whichever is larger. 249 There MUST be at least four bytes of padding. The padding 250 SHOULD consist of random bytes. The maximum amount of 251 padding is 255 bytes. 253 mac 254 Message authentication code. If message authentication has 255 been negotiated, this field contains the MAC bytes. 256 Initially, the MAC algorithm MUST be "none". 258 Note that length of the concatenation of packet length, padding 259 length, payload, and padding MUST be a multiple of the cipher 260 block size or 8, whichever is larger. This constraint MUST be 261 enforced even when using stream ciphers. Note that the packet 262 length field is also encrypted, and processing it requires special 263 care when sending or receiving packets. 265 The minimum size of a packet is 16 (or the cipher block size, 266 whichever is larger) bytes (plus MAC); implementations SHOULD 267 decrypt the length after receiving the first 8 (or cipher block 268 size, whichever is larger) bytes of a packet. 270 4.1 Maximum Packet Length 272 All implementations MUST be able to process packets with 273 uncompressed payload length of 32768 bytes or less and total 274 packet size of 35000 bytes or less (including length, padding 275 length, payload, padding, and MAC.). The maximum of 35000 bytes 276 is an arbitrary chosen value larger than uncompressed size. 277 Implementations SHOULD support longer packets, where they might be 278 needed, e.g. if an implementation wants to send a very large 279 number of certificates. Such packets MAY be sent if the version 280 string indicates that the other party is able to process them. 281 However, implementations SHOULD check that the packet length is 282 reasonable for the implementation to avoid denial-of-service 283 and/or buffer overflow attacks. 285 4.2 Compression 287 If compression has been negotiated, the payload field (and only 288 it) will be compressed using the negotiated algorithm. The length 289 field and MAC will be computed from the compressed payload. 290 Encryption will be done after compression. 292 Compression MAY be stateful, depending on the method. Compression 293 MUST be independent for each direction, and implementations MUST 294 allow independently choosing the algorithm for each direction. 296 The following compression methods are currently defined: 298 none REQUIRED no compression 299 zlib OPTIONAL ZLIB (LZ77) compression 301 The "zlib" compression is described in [RFC1950] and in [RFC1951]. 302 The compression context is initialized after each key exchange, 303 and is passed from one packet to the next with only a partial 304 flush being performed at the end of each packet. A partial flush 305 means that the current compressed block is ended and all data will 306 be output. If the current block is not a stored block, one or 307 more empty blocks are added after the current block to ensure that 308 there are at least 8 bits counting from the start of the end-of- 309 block code of the current block to the end of the packet payload. 311 Additional methods may be defined as specified in [SSH-ARCH]. 313 4.3 Encryption 315 An encryption algorithm and a key will be negotiated during the 316 key exchange. When encryption is in effect, the packet length, 317 padding length, payload and padding fields of each packet MUST be 318 encrypted with the given algorithm. 320 The encrypted data in all packets sent in one direction SHOULD be 321 considered a single data stream. For example, initialization 322 vectors SHOULD be passed from the end of one packet to the 323 beginning of the next packet. All ciphers SHOULD use keys with an 324 effective key length of 128 bits or more. 326 The ciphers in each direction MUST run independently of each 327 other, and implementations MUST allow independently choosing the 328 algorithm for each direction (if multiple algorithms are allowed 329 by local policy). 331 The following ciphers are currently defined: 333 3des-cbc REQUIRED three-key 3DES in CBC mode 334 blowfish-cbc RECOMMENDED Blowfish in CBC mode 335 twofish256-cbc OPTIONAL Twofish in CBC mode, 336 with 256-bit key 337 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 338 is being retained for 339 historical reasons) 341 twofish192-cbc OPTIONAL Twofish with 192-bit key 342 twofish128-cbc RECOMMENDED Twofish with 128-bit key 343 aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, 344 with 256-bit key 345 aes192-cbc OPTIONAL AES with 192-bit key 346 aes128-cbc RECOMMENDED AES with 128-bit key 347 serpent256-cbc OPTIONAL Serpent in CBC mode, with 348 256-bit key 349 serpent192-cbc OPTIONAL Serpent with 192-bit key 350 serpent128-cbc OPTIONAL Serpent with 128-bit key 351 arcfour OPTIONAL the ARCFOUR stream cipher 352 idea-cbc OPTIONAL IDEA in CBC mode 353 cast128-cbc OPTIONAL CAST-128 in CBC mode 354 none OPTIONAL no encryption; NOT RECOMMENDED 356 The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt- 357 encrypt), where the first 8 bytes of the key are used for the 358 first encryption, the next 8 bytes for the decryption, and the 359 following 8 bytes for the final encryption. This requires 24 360 bytes of key data (of which 168 bits are actually used). To 361 implement CBC mode, outer chaining MUST be used (i.e., there is 362 only one initialization vector). This is a block cipher with 8 363 byte blocks. This algorithm is defined in [SCHNEIER] 365 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit 366 keys [SCHNEIER]. This is a block cipher with 8 byte blocks. 368 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC 369 mode, with 256 bit keys as described [TWOFISH]. This is a block 370 cipher with 16 byte blocks. 372 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 374 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 376 The "aes256-cbc" cipher is AES (Advanced Encryption Standard), 377 formerly Rijndael, in CBC mode. This version uses 256-bit key. 379 The "aes192-cbc" cipher. Same as above but with 192-bit key. 381 The "aes128-cbc" cipher. Same as above but with 128-bit key. 383 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as 384 described in the Serpent AES submission. 386 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 388 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 390 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 391 Arcfour cipher is believed to be compatible with the RC4 cipher 392 [SCHNEIER]. RC4 is a registered trademark of RSA Data Security 393 Inc. Arcfour (and RC4) has problems with weak keys, and should be 394 used with caution. 396 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 397 IDEA is patented by Ascom AG. 399 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode 400 [RFC2144]. 402 The "none" algorithm specifies that no encryption is to be done. 403 Note that this method provides no confidentiality protection, and 404 it is not recommended. Some functionality (e.g. password 405 authentication) may be disabled for security reasons if this 406 cipher is chosen. 408 Additional methods may be defined as specified in [SSH-ARCH]. 410 4.4 Data Integrity 412 Data integrity is protected by including with each packet a 413 message authentication code (MAC) that is computed from a shared 414 secret, packet sequence number, and the contents of the packet. 416 The message authentication algorithm and key are negotiated during 417 key exchange. Initially, no MAC will be in effect, and its length 418 MUST be zero. After key exchange, the selected MAC will be 419 computed before encryption from the concatenation of packet data: 421 mac = MAC(key, sequence_number || unencrypted_packet) 423 where unencrypted_packet is the entire packet without MAC (the 424 length fields, payload and padding), and sequence_number is an 425 implicit packet sequence number represented as uint32. The 426 sequence number is initialized to zero for the first packet, and 427 is incremented after every packet (regardless of whether 428 encryption or MAC is in use). It is never reset, even if 429 keys/algorithms are renegotiated later. It wraps around to zero 430 after every 2^32 packets. The packet sequence number itself is 431 not included in the packet sent over the wire. 433 The MAC algorithms for each direction MUST run independently, and 434 implementations MUST allow choosing the algorithm independently 435 for both directions. 437 The MAC bytes resulting from the MAC algorithm MUST be transmitted 438 without encryption as the last part of the packet. The number of 439 MAC bytes depends on the algorithm chosen. 441 The following MAC algorithms are currently defined: 443 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 444 length = 20) 445 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 446 length = 12, key length = 20) 447 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 448 length = 16) 449 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 450 length = 12, key length = 16) 451 none OPTIONAL no MAC; NOT RECOMMENDED 453 The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs 454 use only the first n bits of the resulting value. 456 The hash algorithms are described in [SCHNEIER]. 458 Additional methods may be defined as specified in [SSH-ARCH]. 460 4.5 Key Exchange Methods 462 The key exchange method specifies how one-time session keys are 463 generated for encryption and for authentication, and how the 464 server authentication is done. 466 Only one REQUIRED key exchange method has been defined: 468 diffie-hellman-group1-sha1 REQUIRED 470 This method is described later in this document. 472 Additional methods may be defined as specified in [SSH-ARCH]. 474 4.6 Public Key Algorithms 476 This protocol has been designed to be able to operate with almost 477 any public key format, encoding, and algorithm (signature and/or 478 encryption). 480 There are several aspects that define a public key type: 481 o Key format: how is the key encoded and how are certificates 482 represented. The key blobs in this protocol MAY contain 483 certificates in addition to keys. 484 o Signature and/or encryption algorithms. Some key types may not 485 support both signing and encryption. Key usage may also be 486 restricted by policy statements in e.g. certificates. In this 487 case, different key types SHOULD be defined for the different 488 policy alternatives. 489 o Encoding of signatures and/or encrypted data. This includes 490 but is not limited to padding, byte order, and data formats. 492 The following public key and/or certificate formats are currently defined: 494 ssh-dss REQUIRED sign Simple DSS 495 ssh-rsa RECOMMENDED sign Simple RSA 496 x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) 497 x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) 498 spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) 499 spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) 500 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 501 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 503 Additional key types may be defined as specified in [SSH-ARCH]. 505 The key type MUST always be explicitly known (from algorithm 506 negotiation or some other source). It is not normally included in 507 the key blob. 509 Certificates and public keys are encoded as follows: 511 string certificate or public key format identifier 512 byte[n] key/certificate data 514 The certificate part may have be a zero length string, but a 515 public key is required. This is the public key that will be used 516 for authentication; the certificate sequence contained in the 517 certificate blob can be used to provide authorization. 519 Public key / certifcate formats that do not explicitly specify a 520 signature format identifier MUST use the public key / certificate 521 format identifier as the signature identifier. 523 Signatures are encoded as follows: 524 string signature format identifier (as specified by the 525 public key / cert format) 526 byte[n] signature blob in format specific encoding. 528 The "ssh-dss" key format has the following specific encoding: 530 string "ssh-dss" 531 mpint p 532 mpint q 533 mpint g 534 mpint y 536 Here the p, q, g, and y parameters form the signature key blob. 538 Signing and verifying using this key format is done according to 539 the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A 540 description can also be found in [SCHNEIER]. 542 The resulting signature is encoded as follows: 544 string "ssh-dss" 545 string dss_signature_blob 547 dss_signature_blob is encoded as a string containing r followed by 548 s (which are 160 bits long integers, without lengths or padding, 549 unsigned and in network byte order). 551 The "ssh-rsa" key format has the following specific encoding: 553 string "ssh-rsa" 554 mpint e 555 mpint n 557 Here the e and n parameters form the signature key blob. 559 Signing and verifying using this key format is done according to 560 [SCHNEIER] and [PKCS1] using the SHA-1 hash. 562 The resulting signature is encoded as follows: 564 string "ssh-rsa" 565 string rsa_signature_blob 567 rsa_signature_blob is encoded as a string containing s (which is 568 an integer, without lengths or padding, unsigned and in network 569 byte order). 571 The "spki-sign-rsa" method indicates that the certificate blob 572 contains a sequence of SPKI certificates. The format of SPKI 573 certificates is described in [RFC2693]. This method indicates 574 that the key (or one of the keys in the certificate) is an RSA- 575 key. 577 The "spki-sign-dss". As above, but indicates that the key (or one 578 of the keys in the certificate) is a DSS-key. 580 The "pgp-sign-rsa" method indicates the certificates, the public 581 key, and the signature are in OpenPGP compatible binary format 582 ([RFC2440]). This method indicates that the key is an RSA-key. 584 The "pgp-sign-dss". As above, but indicates that the key is a 585 DSS-key. 587 5. Key Exchange 589 Key exchange begins by each side sending lists of supported 590 algorithms. Each side has a preferred algorithm in each category, 591 and it is assumed that most implementations at any given time will 592 use the same preferred algorithm. Each side MAY guess which 593 algorithm the other side is using, and MAY send an initial key 594 exchange packet according to the algorithm if appropriate for the 595 preferred method. 597 Guess is considered wrong, if: 598 o the kex algorithm and/or the host key algorithm is guessed 599 wrong (server and client have different preferred algorithm), 600 or 601 o if any of the other algorithms cannot be agreed upon (the 602 procedure is defined below in Section Section 5.1). 604 Otherwise, the guess is considered to be right and the 605 optimistically sent packet MUST be handled as the first key 606 exchange packet. 608 However, if the guess was wrong, and a packet was optimistically 609 sent by one or both parties, such packets MUST be ignored (even if 610 the error in the guess would not affect the contents of the 611 initial packet(s)), and the appropriate side MUST send the correct 612 initial packet. 614 Server authentication in the key exchange MAY be implicit. After 615 a key exchange with implicit server authentication, the client 616 MUST wait for response to its service request message before 617 sending any further data. 619 5.1 Algorithm Negotiation 621 Key exchange begins by each side sending the following packet: 623 byte SSH_MSG_KEXINIT 624 byte[16] cookie (random bytes) 625 string kex_algorithms 626 string server_host_key_algorithms 627 string encryption_algorithms_client_to_server 628 string encryption_algorithms_server_to_client 629 string mac_algorithms_client_to_server 630 string mac_algorithms_server_to_client 631 string compression_algorithms_client_to_server 632 string compression_algorithms_server_to_client 633 string languages_client_to_server 634 string languages_server_to_client 635 boolean first_kex_packet_follows 636 uint32 0 (reserved for future extension) 638 Each of the algorithm strings MUST be a comma-separated list of 639 algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each 640 supported (allowed) algorithm MUST be listed in order of 641 preference. 643 The first algorithm in each list MUST be the preferred (guessed) 644 algorithm. Each string MUST contain at least one algorithm name. 646 cookie 647 The cookie MUST be a random value generated by the sender. 648 Its purpose is to make it impossible for either side to 649 fully determine the keys and the session identifier. 651 kex_algorithms 652 Key exchange algorithms were defined above. The first 653 algorithm MUST be the preferred (and guessed) algorithm. If 654 both sides make the same guess, that algorithm MUST be used. 655 Otherwise, the following algorithm MUST be used to choose a 656 key exchange method: iterate over client's kex algorithms, 657 one at a time. Choose the first algorithm that satisfies 658 the following conditions: 659 + the server also supports the algorithm, 660 + if the algorithm requires an encryption-capable host key, 661 there is an encryption-capable algorithm on the server's 662 server_host_key_algorithms that is also supported by the 663 client, and 664 + if the algorithm requires a signature-capable host key, 665 there is a signature-capable algorithm on the server's 666 server_host_key_algorithms that is also supported by the 667 client. 668 + If no algorithm satisfying all these conditions can be 669 found, the connection fails, and both sides MUST 670 disconnect. 672 server_host_key_algorithms 673 List of the algorithms supported for the server host key. 674 The server lists the algorithms for which it has host keys; 675 the client lists the algorithms that it is willing to 676 accept. (There MAY be multiple host keys for a host, 677 possibly with different algorithms.) 679 Some host keys may not support both signatures and 680 encryption (this can be determined from the algorithm), and 681 thus not all host keys are valid for all key exchange 682 methods. 684 Algorithm selection depends on whether the chosen key 685 exchange algorithm requires a signature or encryption 686 capable host key. It MUST be possible to determine this 687 from the public key algorithm name. The first algorithm on 688 the client's list that satisfies the requirements and is 689 also supported by the server MUST be chosen. If there is no 690 such algorithm, both sides MUST disconnect. 692 encryption_algorithms 693 Lists the acceptable symmetric encryption algorithms in 694 order of preference. The chosen encryption algorithm to 695 each direction MUST be the first algorithm on the client's 696 list that is also on the server's list. If there is no such 697 algorithm, both sides MUST disconnect. 699 Note that "none" must be explicitly listed if it is to be 700 acceptable. The defined algorithm names are listed in 701 Section Section 4.3. 703 mac_algorithms 704 Lists the acceptable MAC algorithms in order of preference. 705 The chosen MAC algorithm MUST be the first algorithm on the 706 client's list that is also on the server's list. If there 707 is no such algorithm, both sides MUST disconnect. 709 Note that "none" must be explicitly listed if it is to be 710 acceptable. The MAC algorithm names are listed in Section 711 Figure 1. 713 compression_algorithms 714 Lists the acceptable compression algorithms in order of 715 preference. The chosen compression algorithm MUST be the 716 first algorithm on the client's list that is also on the 717 server's list. If there is no such algorithm, both sides 718 MUST disconnect. 720 Note that "none" must be explicitly listed if it is to be 721 acceptable. The compression algorithm names are listed in 722 Section Section 4.2. 724 languages 725 This is a comma-separated list of language tags in order of 726 preference [RFC1766]. Both parties MAY ignore this list. 727 If there are no language preferences, this list SHOULD be 728 empty. 730 first_kex_packet_follows 731 Indicates whether a guessed key exchange packet follows. If 732 a guessed packet will be sent, this MUST be TRUE. If no 733 guessed packet will be sent, this MUST be FALSE. 735 After receiving the SSH_MSG_KEXINIT packet from the other 736 side, each party will know whether their guess was right. 737 If the other party's guess was wrong, and this field was 738 TRUE, the next packet MUST be silently ignored, and both 739 sides MUST then act as determined by the negotiated key 740 exchange method. If the guess was right, key exchange MUST 741 continue using the guessed packet. 743 After the KEXINIT packet exchange, the key exchange algorithm is 744 run. It may involve several packet exchanges, as specified by the 745 key exchange method. 747 5.2 Output from Key Exchange 749 The key exchange produces two values: a shared secret K, and an 750 exchange hash H. Encryption and authentication keys are derived 751 from these. The exchange hash H from the first key exchange is 752 additionally used as the session identifier, which is a unique 753 identifier for this connection. It is used by authentication 754 methods as a part of the data that is signed as a proof of 755 possession of a private key. Once computed, the session 756 identifier is not changed, even if keys are later re-exchanged. 758 Each key exchange method specifies a hash function that is used in 759 the key exchange. The same hash algorithm MUST be used in key 760 derivation. Here, we'll call it HASH. 762 Encryption keys MUST be computed as HASH of a known value and K as 763 follows: 764 o Initial IV client to server: HASH(K || H || "A" || session_id) 765 (Here K is encoded as mpint and "A" as byte and session_id as 766 raw data."A" means the single character A, ASCII 65). 767 o Initial IV server to client: HASH(K || H || "B" || session_id) 768 o Encryption key client to server: HASH(K || H || "C" || 769 session_id) 771 o Encryption key server to client: HASH(K || H || "D" || 772 session_id) 773 o Integrity key client to server: HASH(K || H || "E" || 774 session_id) 775 o Integrity key server to client: HASH(K || H || "F" || 776 session_id) 778 Key data MUST be taken from the beginning of the hash output. 128 779 bits (16 bytes) SHOULD be used for algorithms with variable-length 780 keys. For other algorithms, as many bytes as are needed are taken 781 from the beginning of the hash value. If the key length in longer 782 than the output of the HASH, the key is extended by computing HASH 783 of the concatenation of K and H and the entire key so far, and 784 appending the resulting bytes (as many as HASH generates) to the 785 key. This process is repeated until enough key material is 786 available; the key is taken from the beginning of this value. In 787 other words: 789 K1 = HASH(K || H || X || session_id) (X is e.g. "A") 790 K2 = HASH(K || H || K1) 791 K3 = HASH(K || H || K1 || K2) 792 ... 793 key = K1 || K2 || K3 || ... 795 This process will lose entropy if the amount of entropy in K is 796 larger than the internal state size of HASH. 798 5.3 Taking Keys Into Use 800 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. 801 This message is sent with the old keys and algorithms. All 802 messages sent after this message MUST use the new keys and 803 algorithms. 805 When this message is received, the new keys and algorithms MUST be 806 taken into use for receiving. 808 This message is the only valid message after key exchange, in 809 addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE 810 messages. The purpose of this message is to ensure that a party 811 is able to respond with a disconnect message that the other party 812 can understand if something goes wrong with the key exchange. 813 Implementations MUST NOT accept any other messages after key 814 exchange before receiving SSH_MSG_NEWKEYS. 816 byte SSH_MSG_NEWKEYS 818 6. Diffie-Hellman Key Exchange 820 The Diffie-Hellman key exchange provides a shared secret that can 821 not be determined by either party alone. The key exchange is 822 combined with a signature with the host key to provide host 823 authentication. 825 In the following description (C is the client, S is the server; p 826 is a large safe prime, g is a generator for a subgroup of GF(p), 827 and q is the order of the subgroup; V_S is S's version string; V_C 828 is C's version string; K_S is S's public host key; I_C is C's 829 KEXINIT message and I_S S's KEXINIT message which have been 830 exchanged before this part begins): 832 1. C generates a random number x (1 < x < q) and computes e = g^x 833 mod p. C sends "e" to S. 835 2. S generates a random number y (0 < y < q) and computes f = g^y 836 mod p. S receives "e". It computes K = e^y mod p, H = 837 hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these 838 elements are encoded according to their types; see below), and 839 signature s on H with its private host key. S sends "K_S || f 840 || s" to C. The signing operation may involve a second 841 hashing operation. 843 3. C verifies that K_S really is the host key for S (e.g. using 844 certificates or a local database). C is also allowed to 845 accept the key without verification; however, doing so will 846 render the protocol insecure against active attacks (but may 847 be desirable for practical reasons in the short term in many 848 environments). C then computes K = f^x mod p, H = hash(V_C || 849 V_S || I_C || I_S || K_S || e || f || K), and verifies the 850 signature s on H. 852 Either side MUST NOT send or accept e or f values that are not in 853 the range [1, p-1]. If this condition is violated, the key 854 exchange fails. 856 This is implemented with the following messages. The hash 857 algorithm for computing the exchange hash is defined by the method 858 name, and is called HASH. The public key algorithm for signing is 859 negotiated with the KEXINIT messages. 861 First, the client sends the following: 863 byte SSH_MSG_KEXDH_INIT 864 mpint e 866 The server responds with the following: 868 byte SSH_MSG_KEXDH_REPLY 869 string server public host key and certificates (K_S) 870 mpint f 871 string signature of H 873 The hash H is computed as the HASH hash of the concatenation of 874 the following: 876 string V_C, the client's version string (CR and NL excluded) 877 string V_S, the server's version string (CR and NL excluded) 878 string I_C, the payload of the client's SSH_MSG_KEXINIT 879 string I_S, the payload of the server's SSH_MSG_KEXINIT 880 string K_S, the host key 881 mpint e, exchange value sent by the client 882 mpint f, exchange value sent by the server 883 mpint K, the shared secret 885 This value is called the exchange hash, and it is used to 886 authenticate the key exchange. The exchange hash SHOULD be kept 887 secret. 889 The signature algorithm MUST be applied over H, not the original 890 data. Most signature algorithms include hashing and additional 891 padding. For example, "ssh-dss" specifies SHA-1 hashing; in that 892 case, the data is first hashed with HASH to compute H, and H is 893 then hashed with SHA-1 as part of the signing operation. 895 6.1 diffie-hellman-group1-sha1 897 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman 898 key exchange with SHA-1 as HASH, and the following group: 900 The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 901 Pi + 129093 ). Its hexadecimal value is: 903 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 904 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 905 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 906 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 907 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 908 FFFFFFFF FFFFFFFF. 910 In decimal, this value is: 912 179769313486231590770839156793787453197860296048756011706444 913 423684197180216158519368947833795864925541502180565485980503 914 646440548199239100050792877003355816639229553136239076508735 915 759914822574862575007425302077447712589550957937778424442426 916 617334727629299387668709205606050270810842907692932019128194 917 467627007. 919 The generator used with this prime is g = 2. The group order q is 920 (p - 1) / 2. 922 This group was taken from the ISAKMP/Oakley specification, and was 923 originally generated by Richard Schroeppel at the University of 924 Arizona. Properties of this prime are described in [Orm96]. 926 7. Key Re-Exchange 928 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet 929 when not already doing a key exchange (as described in Section 930 Section 5.1). When this message is received, a party MUST respond 931 with its own SSH_MSG_KEXINIT message except when the received 932 SSH_MSG_KEXINIT already was a reply. Either party MAY initiate 933 the re-exchange, but roles MUST NOT be changed (i.e., the server 934 remains the server, and the client remains the client). 936 Key re-exchange is performed using whatever encryption was in 937 effect when the exchange was started. Encryption, compression, 938 and MAC methods are not changed before a new SSH_MSG_NEWKEYS is 939 sent after the key exchange (as in the initial key exchange). Re- 940 exchange is processed identically to the initial key exchange, 941 except for the session identifier that will remain unchanged. It 942 is permissible to change some or all of the algorithms during the 943 re-exchange. Host keys can also change. All keys and 944 initialization vectors are recomputed after the exchange. 945 Compression and encryption contexts are reset. 947 It is recommended that the keys are changed after each gigabyte of 948 transmitted data or after each hour of connection time, whichever 949 comes sooner. However, since the re-exchange is a public key 950 operation, it requires a fair amount of processing power and 951 should not be performed too often. 953 More application data may be sent after the SSH_MSG_NEWKEYS packet 954 has been sent; key exchange does not affect the protocols that lie 955 above the SSH transport layer. 957 8. Service Request 959 After the key exchange, the client requests a service. The 960 service is identified by a name. The format of names and 961 procedures for defining new names are defined in [SSH-ARCH]. 963 Currently, the following names have been reserved: 965 ssh-userauth 966 ssh-connection 968 Similar local naming policy is applied to the service names, as is 969 applied to the algorithm names; a local service should use the 970 "servicename@domain" syntax. 972 byte SSH_MSG_SERVICE_REQUEST 973 string service name 975 If the server rejects the service request, it SHOULD send an 976 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. 978 When the service starts, it may have access to the session 979 identifier generated during the key exchange. 981 If the server supports the service (and permits the client to use 982 it), it MUST respond with the following: 984 byte SSH_MSG_SERVICE_ACCEPT 985 string service name 987 Message numbers used by services should be in the area reserved 988 for them (see Section 6 in [SSH-ARCH]). The transport level will 989 continue to process its own messages. 991 Note that after a key exchange with implicit server 992 authentication, the client MUST wait for response to its service 993 request message before sending any further data. 995 9. Additional Messages 997 Either party may send any of the following messages at any time. 999 9.1 Disconnection Message 1001 byte SSH_MSG_DISCONNECT 1002 uint32 reason code 1003 string description [RFC2279] 1004 string language tag [RFC1766] 1006 This message causes immediate termination of the connection. All 1007 implementations MUST be able to process this message; they SHOULD 1008 be able to send this message. 1010 The sender MUST NOT send or receive any data after this message, 1011 and the recipient MUST NOT accept any data after receiving this 1012 message. The description field gives a more specific explanation 1013 in a human-readable form. The error code gives the reason in a 1014 more machine-readable format (suitable for localization), and can 1015 have the following values: 1017 #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 1018 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 1019 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 1020 #define SSH_DISCONNECT_RESERVED 4 1021 #define SSH_DISCONNECT_MAC_ERROR 5 1022 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 1023 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 1024 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 1025 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 1026 #define SSH_DISCONNECT_CONNECTION_LOST 10 1027 #define SSH_DISCONNECT_BY_APPLICATION 11 1028 #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 1029 #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 1030 #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 1031 #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 1033 If the description string is displayed, control character 1034 filtering discussed in [SSH-ARCH] should be used to avoid attacks 1035 by sending terminal control characters. 1037 9.2 Ignored Data Message 1039 byte SSH_MSG_IGNORE 1040 string data 1042 All implementations MUST understand (and ignore) this message at 1043 any time (after receiving the protocol version). No 1044 implementation is required to send them. This message can be used 1045 as an additional protection measure against advanced traffic 1046 analysis techniques. 1048 9.3 Debug Message 1050 byte SSH_MSG_DEBUG 1051 boolean always_display 1052 string message [RFC2279] 1053 string language tag [RFC1766] 1055 All implementations MUST understand this message, but they are 1056 allowed to ignore it. This message is used to pass the other side 1057 information that may help debugging. If always_display is TRUE, 1058 the message SHOULD be displayed. Otherwise, it SHOULD NOT be 1059 displayed unless debugging information has been explicitly 1060 requested by the user. 1062 The message doesn't need to contain a newline. It is, however, 1063 allowed to consist of multiple lines separated by CRLF (Carriage 1064 Return - Line Feed) pairs. 1066 If the message string is displayed, terminal control character 1067 filtering discussed in [SSH-ARCH] should be used to avoid attacks 1068 by sending terminal control characters. 1070 9.4 Reserved Messages 1072 An implementation MUST respond to all unrecognized messages with 1073 an SSH_MSG_UNIMPLEMENTED message in the order in which the 1074 messages were received. Such messages MUST be otherwise ignored. 1075 Later protocol versions may define other meanings for these 1076 message types. 1078 byte SSH_MSG_UNIMPLEMENTED 1079 uint32 packet sequence number of rejected message 1081 10. Summary of Message Numbers 1083 The following message numbers have been defined in this protocol: 1085 #define SSH_MSG_DISCONNECT 1 1086 #define SSH_MSG_IGNORE 2 1087 #define SSH_MSG_UNIMPLEMENTED 3 1088 #define SSH_MSG_DEBUG 4 1089 #define SSH_MSG_SERVICE_REQUEST 5 1090 #define SSH_MSG_SERVICE_ACCEPT 6 1092 #define SSH_MSG_KEXINIT 20 1093 #define SSH_MSG_NEWKEYS 21 1095 /* Numbers 30-49 used for kex packets. 1096 Different kex methods may reuse message numbers in 1097 this range. */ 1099 #define SSH_MSG_KEXDH_INIT 30 1100 #define SSH_MSG_KEXDH_REPLY 31 1102 11. Security Considerations 1104 This protocol provides a secure encrypted channel over an insecure 1105 network. It performs server host authentication, key exchange, 1106 encryption, and integrity protection. It also derives a unique 1107 session id that may be used by higher-level protocols. 1109 Full security considerations for this protocol are provided in 1110 Section 8 of [SSH-ARCH] 1112 12. Intellectual Property 1114 The IETF takes no position regarding the validity or scope of any 1115 intellectual property or other rights that might be claimed to 1116 pertain to the implementation or use of the technology described 1117 in this document or the extent to which any license under such 1118 rights might or might not be available; neither does it represent 1119 that it has made any effort to identify any such rights. 1120 Information on the IETF's procedures with respect to rights in 1121 standards-track and standards-related documentation can be found 1122 in BCP-11. Copies of claims of rights made available for 1123 publication and any assurances of licenses to be made available, 1124 or the result of an attempt made to obtain a general license or 1125 permission for the use of such proprietary rights by implementers 1126 or users of this specification can be obtained from the IETF 1127 Secretariat. 1129 The IETF has been notified of intellectual property rights claimed 1130 in regard to some or all of the specification contained in this 1131 document. For more information consult the online list of claimed 1132 rights. 1134 13. Additional Information 1136 The current document editor is: Darren.Moffat@Sun.COM. Comments 1137 on this internet draft should be sent to the IETF SECSH working 1138 group, details at: http://ietf.org/html.charters/secsh- 1139 charter.html 1141 References 1143 [FIPS-186] Federal Information Processing Standards 1144 Publication, ., "FIPS PUB 186, Digital Signature 1145 Standard", May 1994. 1147 [Orm96] Orman, H., "The Okaley Key Determination Protcol 1148 version1, TR97-92", 1996. 1150 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, 1151 "Internet X.509 Public Key Infrastructure 1152 Certificate and CRL Profile", RFC 2459, January 1153 1999. 1155 [RFC1034] Mockapetris, P., "Domain names - concepts and 1156 facilities", STD 13, RFC 1034, Nov 1987. 1158 [RFC1766] Alvestrand, H., "Tags for the Identification of 1159 Languages", RFC 1766, March 1995. 1161 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data 1162 Format Specification version 3.3", RFC 1950, May 1163 1996. 1165 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 1166 Specification version 1.3", RFC 1951, May 1996. 1168 [RFC2279] Yergeau, F., "UTF-8, a transformation format of 1169 ISO 10646", RFC 2279, January 1998. 1171 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1172 Keyed-Hashing for Message Authentication", RFC 1173 2104, February 1997. 1175 [RFC2119] Bradner, S., "Key words for use in RFCs to 1176 Indicate Requirement Levels", BCP 14, RFC 2119, 1177 March 1997. 1179 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", 1180 RFC 2144, May 1997. 1182 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. 1183 Thayer, "OpenPGP Message Format", RFC 2440, 1184 November 1998. 1186 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., 1187 Thomas, B. and T. Ylonen, "SPKI Certificate 1188 Theory", RFC 2693, September 1999. 1190 [SCHNEIER] Schneier, B., "Applied Cryptography Second 1191 Edition: protocols algorithms and source in code 1192 in C", 1996. 1194 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: 1195 A 128-Bit Block Cipher, 1st Edition", March 1999. 1197 [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D 1198 draft-ietf-architecture-14.txt, July 2003. 1200 [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D 1201 draft-ietf-transport-16.txt, July 2003. 1203 [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D 1204 draft-ietf-userauth-17.txt, July 2003. 1206 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- 1207 ietf-connect-17.txt, July 2003. 1209 [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned 1210 Numbers", I-D draft-ietf-secsh-assignednumbers- 1211 03.txt, July 2003. 1213 Authors' Addresses 1215 Tatu Ylonen 1216 SSH Communications Security Corp 1217 Fredrikinkatu 42 1218 HELSINKI FIN-00100 1219 Finland 1221 EMail: ylo@ssh.com 1223 Tero Kivinen 1224 SSH Communications Security Corp 1225 Fredrikinkatu 42 1226 HELSINKI FIN-00100 1227 Finland 1229 EMail: kivinen@ssh.com 1231 Markku-Juhani O. Saarinen 1232 University of Jyvaskyla 1233 Timo J. Rinne 1234 SSH Communications Security Corp 1235 Fredrikinkatu 42 1236 HELSINKI FIN-00100 1237 Finland 1239 EMail: tri@ssh.com 1241 Sami Lehtinen 1242 SSH Communications Security Corp 1243 Fredrikinkatu 42 1244 HELSINKI FIN-00100 1245 Finland 1247 EMail: sjl@ssh.com 1249 Full Copyright Statement 1251 Copyright (C) The Internet Society (2003). All Rights Reserved. 1253 This document and translations of it may be copied and furnished 1254 to others, and derivative works that comment on or otherwise 1255 explain it or assist in its implementation may be prepared, 1256 copied, published and distributed, in whole or in part, without 1257 restriction of any kind, provided that the above copyright notice 1258 and this paragraph are included on all such copies and derivative 1259 works. However, this document itself may not be modified in any 1260 way, such as by removing the copyright notice or references to the 1261 Internet Society or other Internet organizations, except as needed 1262 for the purpose of developing Internet standards in which case the 1263 procedures for copyrights defined in the Internet Standards 1264 process must be followed, or as required to translate it into 1265 languages other than English. 1267 The limited permissions granted above are perpetual and will not 1268 be revoked by the Internet Society or its successors or assigns. 1270 This document and the information contained herein is provided on 1271 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1272 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1273 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1274 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1277 Acknowledgement 1279 Funding for the RFC Editor function is currently provided by the 1280 Internet Society.