idnits 2.17.1 draft-ietf-secsh-transport-10.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 484 has weird spacing: '... string cert...' == Line 509 has weird spacing: '... string dss...' == Line 529 has weird spacing: '... string rsa...' == Line 593 has weird spacing: '... string kex...' == Line 594 has weird spacing: '... string ser...' == (20 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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 524, but not defined -- Looks like a reference, but probably isn't: '16' on line 592 == Unused Reference: 'RFC-1034' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'SECSH-USERAUTH' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'SECSH-CONNECT' is defined on line 1134, 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' == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-08 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-10 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-10 Summary: 12 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ylonen 2 INTERNET-DRAFT T. Kivinen 3 draft-ietf-secsh-transport-10.txt M. Saarinen 4 Expires: 2 September, 2001 T. Rinne 5 S. Lehtinen 6 SSH Communications Security 7 2 March, 2001 9 Secure Shell Transport Layer Protocol 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The Secure Shell Remote Login Protocol is a protocol for secure remote 36 login and other secure network services over an insecure network. This 37 document describes the Secure Shell transport layer protocol which typi- 38 cally runs on top of TCP/IP. The protocol can be used as a basis for a 39 number of secure network services. It provides strong encryption, server 40 authentication, and integrity protection. It may also provide compres- 41 sion. Key exchange method, public key algorithm, symmetric encryption 42 algorithm, message authentication algorithm, and hash algorithm are all 43 negotiated. This document also describes the Diffie-Hellman key 44 exchange method and the minimal set of algorithms that are needed to 45 implement the Secure Shell transport layer protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 51 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2. Protocol Version Exchange . . . . . . . . . . . . . . . . . 3 54 3.3. Compatibility With Old Secure Shell Versions . . . . . . . . 4 55 3.3.1. Old Client, New Server . . . . . . . . . . . . . . . . . 4 56 3.3.2. New Client, Old Server . . . . . . . . . . . . . . . . . 4 57 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Maximum Packet Length . . . . . . . . . . . . . . . . . . . 5 59 4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.5. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 9 63 4.6. Public Key Algorithms . . . . . . . . . . . . . . . . . . . 9 64 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.1. Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 12 66 5.2. Output from Key Exchange . . . . . . . . . . . . . . . . . . 14 67 5.3. Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 15 68 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . . 15 69 6.1. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 17 70 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . . 17 71 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . . 18 72 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . . 18 73 9.1. Disconnection Message . . . . . . . . . . . . . . . . . . . 19 74 9.2. Ignored Data Message . . . . . . . . . . . . . . . . . . . . 19 75 9.3. Debug Message . . . . . . . . . . . . . . . . . . . . . . . 19 76 9.4. Reserved Messages . . . . . . . . . . . . . . . . . . . . . 20 77 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 20 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 79 12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 21 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Introduction 85 The Secure Shell transport layer protocol is a secure low level 86 transport protocol. It provides strong encryption, cryptographic host 87 authentication, and integrity protection. 89 Authentication in this protocol level is host-based; this protocol does 90 not perform user authentication. A higher level protocol for user 91 authentication can be designed on top of this protocol. 93 The protocol has been designed to be simple, flexible, to allow 94 parameter negotiation, and to minimize the number of round-trips. Key 95 exchange method, public key algorithm, symmetric encryption algorithm, 96 message authentication algorithm, and hash algorithm are all negotiated. 97 It is expected that in most environments, only 2 round-trips will be 98 needed for full key exchange, server authentication, service request, 99 and acceptance notification of service request. The worst case is 3 100 round-trips. 102 2. Conventions Used in This Document 104 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and 105 "MAY" that appear in this document are to be interpreted as described in 106 [RFC-2119]. 108 The used data types and terminology are specified in the architecture 109 document [SECSH-ARCH]. 111 The architecture document also discusses the algorithm naming 112 conventions that MUST be used with the Secure Shell protocols. 113 3. Connection Setup 115 The Secure Shell Transport Layer Protocol works over any 8-bit clean, 116 binary-transparent transport. The underlying transport SHOULD protect 117 against transmission errors as such errors cause the Secure Shell 118 connection to terminate. 120 The client initiates the connection. 122 3.1. Use over TCP/IP 124 When used over TCP/IP, the server normally listens for connections on 125 port 22. This port number has been registered with the IANA, and has 126 been officially assigned for Secure Shell. 128 3.2. Protocol Version Exchange 130 When the connection has been established, both sides MUST send an 131 identification string of the form "SSH-protoversion-softwareversion 132 comments", followed by carriage return and newline characters (ASCII 13 133 and 10, respectively). Both sides MUST be able to process 134 identification strings without carriage return character. No null 135 character is sent. The maximum length of the string is 255 characters, 136 including the carriage return and newline. 138 The part of the identification string preceding carriage return and 139 newline is used in the Diffie-Hellman key exchange (see Section 140 ``Diffie-Hellman Key Exchange''). 142 The server MAY send other lines of data before sending the version 143 string. Each line SHOULD be terminated by a carriage return and 144 newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 145 in ISO-10646 UTF-8 [RFC-2279] (language is not specified). Clients MUST 146 be able to process such lines; they MAY be silently ignored, or MAY be 147 displayed to the client user; if they are displayed, control character 148 filtering discussed in [SECSH-ARCH] SHOULD be used. The primary use of 149 this feature is to allow TCP-wrappers to display an error message before 150 disconnecting. 152 Version strings MUST consist of printable US-ASCII characters, not 153 including whitespaces or a minus sign (-). The version string is 154 primarily used to trigger compatibility extensions and to indicate the 155 capabilities of an implementation. The comment string should contain 156 additional information that might be useful in solving user problems. 158 The protocol version described in this document is 2.0. 160 Key exchange will begin immediately after sending this identifier. All 161 packets following the identification string SHALL use the binary packet 162 protocol, to be described below. 164 3.3. Compatibility With Old Secure Shell Versions 166 During the transition period, it is important to be able to work in a 167 way that is compatible with the installed Secure Shell clients and 168 servers that use an older version of the protocol. Information in this 169 section is only relevant for implementations supporting compatibility 170 with Secure Shell versions 1.x. 172 3.3.1. Old Client, New Server 174 Server implementations MAY support a configurable "compatibility" flag 175 that enables compatibility with old versions. When this flag is on, the 176 server SHOULD identify its protocol version as "1.99". Clients using 177 protocol 2.0 MUST be able to identify this as identical to "2.0". In 178 this mode the server SHOULD NOT send the carriage return character 179 (ASCII 13) after the version identification string. 181 In the compatibility mode the server SHOULD NOT send any further data 182 after its initialization string until it has received an identification 183 string from the client. The server can then determine whether the 184 client is using an old protocol, and can revert to the old protocol if 185 required. In the compatibility mode, the server MUST NOT send 186 additional data before the version string. 188 When compatibility with old clients is not needed, the server MAY send 189 its initial key exchange data immediately after the identification 190 string. 192 3.3.2. New Client, Old Server 194 Since the new client MAY immediately send additional data after its 195 identification string (before receiving server's identification), the 196 old protocol may already have been corrupted when the client learns that 197 the server is old. When this happens, the client SHOULD close the 198 connection to the server, and reconnect using the old protocol. 200 4. Binary Packet Protocol 202 Each packet is in the following format: 204 uint32 packet_length 205 byte padding_length 206 byte[n1] payload; n1 = packet_length - padding_length - 1 207 byte[n2] random padding; n2 = padding_length 208 byte[m] mac (message authentication code); m = mac_length 210 packet_length 211 The length of the packet (bytes), not including MAC or the 212 packet_length field itself. 214 padding_length 215 Length of padding (bytes). 217 payload 218 The useful contents of the packet. If compression has been 219 negotiated, this field is compressed. Initially, compression MUST 220 be "none". 222 Padding 223 Arbitrary-length padding, such that the total length of 224 (packet_length || padding_length || payload || padding) is a 225 multiple of the cipher block size or 8, whichever is larger. 226 There MUST be at least four bytes of padding. The padding SHOULD 227 consist of random bytes. The maximum amount of padding is 255 228 bytes. 230 MAC 231 Message authentication code. If message authentication has been 232 negotiated, this field contains the MAC bytes. Initially, the MAC 233 algorithm MUST be "none". 235 Note that length of the concatenation of packet length, padding length, 236 payload, and padding MUST be a multiple of the cipher block size or 8, 237 whichever is larger. This constraint MUST be enforced even when using 238 stream ciphers. Note that the packet length field is also encrypted, 239 and processing it requires special care when sending or receiving 240 packets. 242 The minimum size of a packet is 16 (or the cipher block size, whichever 243 is larger) bytes (plus MAC); implementations SHOULD decrypt the length 244 after receiving the first 8 (or cipher block size, whichever is larger) 245 bytes of a packet. 247 4.1. Maximum Packet Length 249 All implementations MUST be able to process packets with uncompressed 250 payload length of 32768 bytes or less and total packet size of 35000 251 bytes or less (including length, padding length, payload, padding, and 252 MAC.). The maximum of 35000 bytes is an arbitrary chosen value larger 253 than uncompressed size. Implementations SHOULD support longer packets, 254 where they might be needed, e.g. if an implementation wants to send a 255 very large number of certificates. Such packets MAY be sent if the 256 version string indicates that the other party is able to process them. 257 However, implementations SHOULD check that the packet length is 258 reasonable for the implementation to avoid denial-of-service and/or 259 buffer overflow attacks. 261 4.2. Compression 263 If compression has been negotiated, the payload field (and only it) will 264 be compressed using the negotiated algorithm. The length field and MAC 265 will be computed from the compressed payload. Encryption will be done 266 after compression. 268 Compression MAY be stateful, depending on the method. Compression MUST 269 be independent for each direction, and implementations MUST allow 270 independently choosing the algorithm for each direction. 272 The following compression methods are currently defined: 274 none REQUIRED no compression 275 zlib OPTIONAL ZLIB (LZ77) compression 277 The "zlib" compression is described in [RFC-1950] and in [RFC-1951]. The 278 compression context is initialized after each key exchange, and is 279 passed from one packet to the next with only a partial flush being 280 performed at the end of each packet. A partial flush means that all data 281 will be output, but the next packet will continue using compression 282 tables from the end of the previous packet. 284 Additional methods may be defined as specified in [SECSH-ARCH]. 286 4.3. Encryption 288 An encryption algorithm and a key will be negotiated during the key 289 exchange. When encryption is in effect, the packet length, padding 290 length, payload and padding fields of each packet MUST be encrypted with 291 the given algorithm. 293 The encrypted data in all packets sent in one direction SHOULD be 294 considered a single data stream. For example, initialization vectors 295 SHOULD be passed from the end of one packet to the beginning of the next 296 packet. All ciphers SHOULD use keys with an effective key length of 128 297 bits or more. 299 The ciphers in each direction MUST run independently of each other, and 300 implementations MUST allow independently choosing the algorithm for each 301 direction (if multiple algorithms are allowed by local policy). 303 The following ciphers are currently defined: 305 3des-cbc REQUIRED three-key 3DES in CBC mode 306 blowfish-cbc RECOMMENDED Blowfish in CBC mode 307 twofish256-cbc OPTIONAL Twofish in CBC mode, 308 with 256-bit key 309 twofish-cbc OPTIONAL alias for "twofish256-cbc" (this 310 is being retained for 311 historical reasons) 312 twofish192-cbc OPTIONAL Twofish with 192-bit key 313 twofish128-cbc RECOMMENDED Twofish with 128-bit key 314 aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, 315 with 256-bit key 316 aes192-cbc OPTIONAL AES with 192-bit key 317 aes128-cbc RECOMMENDED AES with 128-bit key 318 serpent256-cbc OPTIONAL Serpent in CBC mode, with 319 256-bit key 320 serpent192-cbc OPTIONAL Serpent with 192-bit key 321 serpent128-cbc OPTIONAL Serpent with 128-bit key 322 arcfour OPTIONAL the ARCFOUR stream cipher 323 idea-cbc OPTIONAL IDEA in CBC mode 324 cast128-cbc OPTIONAL CAST-128 in CBC mode 325 none OPTIONAL no encryption; NOT RECOMMENDED 327 The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-encrypt), 328 where the first 8 bytes of the key are used for the first encryption, 329 the next 8 bytes for the decryption, and the following 8 bytes for the 330 final encryption. This requires 24 bytes of key data (of which 168 bits 331 are actually used). To implement CBC mode, outer chaining MUST be used 332 (i.e., there is only one initialization vector). This is a block cipher 333 with 8 byte blocks. This algorithm is defined in [SCHNEIER]. 335 The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys 336 [SCHNEIER]. This is a block cipher with 8 byte blocks. 338 The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 339 with 256 bit keys as described [TWOFISH]. This is a block cipher with 16 340 byte blocks. 342 The "twofish192-cbc" cipher. Same as above but with 192-bit key. 344 The "twofish128-cbc" cipher. Same as above but with 128-bit key. 346 The "aes256-cbc" cipher is AES (Advanced Encryption Standard), formerly 347 Rijndael, in CBC mode. This version uses 256-bit key. 349 The "aes192-cbc" cipher. Same as above but with 192-bit key. 351 The "aes128-cbc" cipher. Same as above but with 128-bit key. 353 The "serpent256-cbc" cipher in CBC mode, with 256-bit key as described 354 in the Serpent AES submission. 356 The "serpent192-cbc" cipher. Same as above but with 192-bit key. 358 The "serpent128-cbc" cipher. Same as above but with 128-bit key. 360 The "arcfour" is the Arcfour stream cipher with 128 bit keys. The 361 Arcfour cipher is believed to be compatible with the RC4 cipher 362 [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. 363 Arcfour (and RC4) has problems with weak keys, and should be used with 364 caution. 366 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. IDEA is 367 patented by Ascom AG. 369 The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC-2144]. 371 The "none" algorithm specifies that no encryption is to be done. Note 372 that this method provides no confidentiality protection, and it is not 373 recommended. Some functionality (e.g. password authentication) may be 374 disabled for security reasons if this cipher is chosen. 376 Additional methods may be defined as specified in [SECSH-ARCH]. 378 4.4. Data Integrity 380 Data integrity is protected by including with each packet a message 381 authentication code (MAC) that is computed from a shared secret, packet 382 sequence number, and the contents of the packet. 384 The message authentication algorithm and key are negotiated during key 385 exchange. Initially, no MAC will be in effect, and its length MUST be 386 zero. After key exchange, the selected MAC will be computed before 387 encryption from the concatenation of packet data: 389 mac = MAC(key, sequence_number || unencrypted_packet) 391 where unencrypted_packet is the entire packet without MAC (the length 392 fields, payload and padding), and sequence_number is an implicit packet 393 sequence number represented as uint32. The sequence number is 394 initialized to zero for the first packet, and is incremented after every 395 packet (regardless of whether encryption or MAC is in use). It is never 396 reset, even if keys/algorithms are renegotiated later. It wraps around 397 to zero after every 2^32 packets. The packet sequence number itself is 398 not included in the packet sent over the wire. 400 The MAC algorithms for each direction MUST run independently, and 401 implementations MUST allow choosing the algorithm independently for both 402 directions. 404 The MAC bytes resulting from the MAC algorithm MUST be transmitted 405 without encryption as the last part of the packet. The number of MAC 406 bytes depends on the algorithm chosen. 408 The following MAC algorithms are currently defined: 410 hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key 411 length = 20) 412 hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest 413 length = 12, key length = 20) 414 hmac-md5 OPTIONAL HMAC-MD5 (digest length = key 415 length = 16) 416 hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest 417 length = 12, key length = 16) 418 none OPTIONAL no MAC; NOT RECOMMENDED 420 The "hmac-*" algorithms are described in [RFC-2104]. The "*-n" MACs use 421 only the first n bits of the resulting value. 423 The hash algorithms are described in [SCHNEIER]. 425 The "none" method is NOT RECOMMENDED. An active attacker may be able to 426 modify transmitted data if this is used. 428 Additional methods may be defined as specified in [SECSH-ARCH]. 430 4.5. Key Exchange Methods 432 The key exchange method specifies how one-time session keys are 433 generated for encryption and for authentication, and how the server 434 authentication is done. 436 Only one REQUIRED key exchange method has been defined: 438 diffie-hellman-group1-sha1 REQUIRED 440 This method is described later in this document. 442 Additional methods may be defined as specified in [SECSH-ARCH]. 444 4.6. Public Key Algorithms 446 This protocol has been designed to be able to operate with almost any 447 public key format, encoding, and algorithm (signature and/or 448 encryption). 450 There are several aspects that define a public key type: 452 o Key format: how is the key encoded and how are certificates 453 represented. The key blobs in this protocol MAY contain certificates 454 in addition to keys. 456 o Signature and/or encryption algorithms. Some key types may not 457 support both signing and encryption. Key usage may also be 458 restricted by policy statements in e.g. certificates. In this case, 459 different key types SHOULD be defined for the different policy 460 alternatives. 462 o Encoding of signatures and/or encrypted data. This includes but is 463 not limited to padding, byte order, and data formats. 465 The following public key and/or certificate formats are currently 466 defined: 468 ssh-dss REQUIRED sign Simple DSS 469 ssh-rsa RECOMMENDED sign Simple RSA 470 x509v3-sign-rsa RECOMMENDED sign X.509 certificates (RSA key) 471 x509v3-sign-dss RECOMMENDED sign X.509 certificates (DSS key) 472 spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) 473 spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) 474 pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 475 pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 477 Additional key types may be defined as specified in [SECSH-ARCH]. 479 The key type MUST always be explicitly known (from algorithm negotiation 480 or some other source). It is not normally included in the key blob. 482 Certificates and public keys are encoded as follows: 484 string certificate or public key format identifier 485 byte[n] key/certificate data 487 The certificate part may have be a zero length string, but a public key 488 is required. This is the public key that will be used for 489 authentication; the certificate sequence contained in the certificate 490 blob can be used to provide authorization. 492 The "ssh-dss" key format has the following specific encoding: 494 string "ssh-dss" 495 mpint p 496 mpint q 497 mpint g 498 mpint y 500 Here the p, q, g, and y parameters form the signature key blob. 502 Signing and verifying using this key format is done according to the 503 Digital Signature Standard [FIPS-186] using the SHA-1 hash. A 504 description can also be found in [SCHNEIER]. 506 The resulting signature is encoded as follows: 508 string "ssh-dss" 509 string dss_signature_blob 511 dss_signature_blob is encoded as a string containing r followed by s 512 (which are 160 bits long integers, without lengths or padding, unsigned 513 and in network byte order). 515 The "ssh-rsa" key format has the following specific encoding: 517 string "ssh-rsa" 518 mpint e 519 mpint n 521 Here the e and n parameters form the signature key blob. 523 Signing and verifying using this key format is done according to 524 [SCHNEIER] and [PKCS1] using the SHA-1 hash. 526 The resulting signature is encoded as follows: 528 string "ssh-rsa" 529 string rsa_signature_blob 531 rsa_signature_blob is encoded as a string containing s (which is an 532 integer, without lengths or padding, unsigned and in network byte 533 order). 535 The "x509v3-sign-rsa" method indicates that the certificates, the public 536 key, and the resulting signature are in X.509v3 compatible DER-encoded 537 format. The formats used in X.509v3 is described in [RFC-2459]. This 538 method indicates that the key (or one of the keys in the certificate) is 539 an RSA-key. 541 The "x509v3-sign-dss". As above, but indicates that the key (or one of 542 the keys in the certificate) is a DSS-key. 544 The "spki-sign-rsa" method indicates that the certificate blob contains 545 a sequence of SPKI certificates. The format of SPKI certificates is 546 described in [RFC-2693]. This method indicates that the key (or one of 547 the keys in the certificate) is an RSA-key. 549 The "spki-sign-dss". As above, but indicates that the key (or one of the 550 keys in the certificate) is a DSS-key. 552 The "pgp-sign-rsa" method indicates the certificates, the public key, 553 and the signature are in OpenPGP compatible binary format ([RFC-2440]). 554 This method indicates that the key is an RSA-key. 556 The "pgp-sign-dss". As above, but indicates that the key is a DSS-key. 558 5. Key Exchange 560 Key exchange begins by each side sending lists of supported algorithms. 561 Each side has a preferred algorithm in each category, and it is assumed 562 that most implementations at any given time will use the same preferred 563 algorithm. Each side MAY guess which algorithm the other side is using, 564 and MAY send an initial key exchange packet according to the algorithm 565 if appropriate for the preferred method. 567 Guess is considered wrong, if: 569 o the kex algorithm and/or the host key algorithm is guessed wrong 570 (server and client have different preferred algorithm), or 572 o if any of the other algorithms cannot be agreed upon (the procedure 573 is defined below in Section ``Algorithm Negotiation''). 575 Otherwise, the guess is considered to be right and the optimistically 576 sent packet MUST be handled as the first key exchange packet. 578 However, if the guess was wrong, and a packet was optimistically sent by 579 one or both parties, such packets MUST be ignored (even if the error in 580 the guess would not affect the contents of the initial packet(s)), and 581 the appropriate side MUST send the correct initial packet. 583 Server authentication in the key exchange MAY be implicit. After a key 584 exchange with implicit server authentication, the client MUST wait for 585 response to its service request message before sending any further data. 587 5.1. Algorithm Negotiation 589 Key exchange begins by each side sending the following packet: 591 byte SSH_MSG_KEXINIT 592 byte[16] cookie (random bytes) 593 string kex_algorithms 594 string server_host_key_algorithms 595 string encryption_algorithms_client_to_server 596 string encryption_algorithms_server_to_client 597 string mac_algorithms_client_to_server 598 string mac_algorithms_server_to_client 599 string compression_algorithms_client_to_server 600 string compression_algorithms_server_to_client 601 string languages_client_to_server 602 string languages_server_to_client 603 boolean first_kex_packet_follows 604 uint32 0 (reserved for future extension) 606 Each of the algorithm strings MUST be a comma-separated list of 607 algorithm names (see ''Algorithm Naming'' in [SECSH-ARCH]). Each 608 supported (allowed) algorithm MUST be listed in order of preference. 610 The first algorithm in each list MUST be the preferred (guessed) 611 algorithm. Each string MUST contain at least one algorithm name. 613 cookie 614 The cookie MUST be a random value generated by the sender. Its 615 purpose is to make it impossible for either side to fully 616 determine the keys and the session identifier. 618 kex_algorithms 619 Key exchange algorithms were defined above. The first algorithm 620 MUST be the preferred (and guessed) algorithm. If both sides make 621 the same guess, that algorithm MUST be used. Otherwise, the 622 following algorithm MUST be used to choose a key exchange method: 623 iterate over client's kex algorithms, one at a time. Choose the 624 first algorithm that satisfies the following conditions: 626 o the server also supports the algorithm, 628 o if the algorithm requires an encryption-capable host key, there is 629 an encryption-capable algorithm on the server's 630 server_host_key_algorithms that is also supported by the client, 631 and 633 o if the algorithm requires a signature-capable host key, there is a 634 signature-capable algorithm on the server's 635 server_host_key_algorithms that is also supported by the client. 637 If no algorithm satisfying all these conditions can be found, the 638 connection fails, and both sides MUST disconnect. 640 server_host_key_algorithms 641 List of the algorithms supported for the server host key. The 642 server lists the algorithms for which it has host keys; the client 643 lists the algorithms that it is willing to accept. (There MAY be 644 multiple host keys for a host, possibly with different 645 algorithms.) 647 Some host keys may not support both signatures and encryption 648 (this can be determined from the algorithm), and thus not all host 649 keys are valid for all key exchange methods. 651 Algorithm selection depends on whether the chosen key exchange 652 algorithm requires a signature or encryption capable host key. It 653 MUST be possible to determine this from the public key algorithm 654 name. The first algorithm on the client's list that satisfies the 655 requirements and is also supported by the server MUST be chosen. 656 If there is no such algorithm, both sides MUST disconnect. 658 encryption_algorithms 659 Lists the acceptable symmetric encryption algorithms in order of 660 preference. The chosen encryption algorithm to each direction 661 MUST be the first algorithm on the client's list that is also on 662 the server's list. If there is no such algorithm, both sides MUST 663 disconnect. 665 Note that "none" must be explicitly listed if it is to be 666 acceptable. The defined algorithm names are listed in Section 667 ``Encryption''. 669 mac_algorithms 670 Lists the acceptable MAC algorithms in order of preference. The 671 chosen MAC algorithm MUST be the first algorithm on the client's 672 list that is also on the server's list. If there is no such 673 algorithm, both sides MUST disconnect. 675 Note that "none" must be explicitly listed if it is to be 676 acceptable. The MAC algorithm names are listed in Section ``Data 677 Integrity''. 679 compression_algorithms 680 Lists the acceptable compression algorithms in order of 681 preference. The chosen compression algorithm MUST be the first 682 algorithm on the client's list that is also on the server's list. 683 If there is no such algorithm, both sides MUST disconnect. 685 Note that "none" must be explicitly listed if it is to be 686 acceptable. The compression algorithm names are listed in Section 687 ``Compression''. 688 languages 689 This is a comma-separated list of language tags in order of 690 preference [RFC-1766]. Both parties MAY ignore this list. If there 691 are no language preferences, this list SHOULD be empty. 693 first_kex_packet_follows 694 Indicates whether a guessed key exchange packet follows. If a 695 guessed packet will be sent, this MUST be TRUE. If no guessed 696 packet will be sent, this MUST be FALSE. 698 After receiving the SSH_MSG_KEXINIT packet from the other side, 699 each party will know whether their guess was right. If the other 700 party's guess was wrong, and this field was TRUE, the next packet 701 MUST be silently ignored, and both sides MUST then act as 702 determined by the negotiated key exchange method. If the guess 703 was right, key exchange MUST continue using the guessed packet. 705 After the KEXINIT packet exchange, the key exchange algorithm is run. It 706 may involve several packet exchanges, as specified by the key exchange 707 method. 709 5.2. Output from Key Exchange 711 The key exchange produces two values: a shared secret K, and an exchange 712 hash H. Encryption and authentication keys are derived from these. The 713 exchange hash H from the first key exchange is additionally used as the 714 session identifier, which is a unique identifier for this connection. 715 It is used by authentication methods as a part of the data that is 716 signed as a proof of possession of a private key. Once computed, the 717 session identifier is not changed, even if keys are later re-exchanged. 719 Each key exchange method specifies a hash function that is used in the 720 key exchange. The same hash algorithm MUST be used in key derivation. 721 Here, we'll call it HASH. 723 Encryption keys MUST be computed as HASH of a known value and K as 724 follows: 726 o Initial IV client to server: HASH(K || H || "A" || session_id) (Here 727 K is encoded as mpint and "A" as byte and session_id as raw data."A" 728 means the single character A, ASCII 65). 730 o Initial IV server to client: HASH(K || H || "B" || session_id) 732 o Encryption key client to server: HASH(K || H || "C" || session_id) 734 o Encryption key server to client: HASH(K || H || "D" || session_id) 735 o Integrity key client to server: HASH(K || H || "E" || session_id) 737 o Integrity key server to client: HASH(K || H || "F" || session_id) 739 Key data MUST be taken from the beginning of the hash output. 128 bits 740 (16 bytes) SHOULD be used for algorithms with variable-length keys. For 741 other algorithms, as many bytes as are needed are taken from the 742 beginning of the hash value. If the key length in longer than the output 743 of the HASH, the key is extended by computing HASH of the concatenation 744 of K and H and the entire key so far, and appending the resulting bytes 745 (as many as HASH generates) to the key. This process is repeated until 746 enough key material is available; the key is taken from the beginning of 747 this value. In other words: 749 K1 = HASH(K || H || X || session_id) (X is e.g. "A") 750 K2 = HASH(K || H || K1) 751 K3 = HASH(K || H || K1 || K2) 752 ... 753 key = K1 || K2 || K3 || ... 755 This process will lose entropy if the amount of entropy in K is larger 756 than the internal state size of HASH. 758 5.3. Taking Keys Into Use 760 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This 761 message is sent with the old keys and algorithms. All messages sent 762 after this message MUST use the new keys and algorithms. 764 When this message is received, the new keys and algorithms MUST be taken 765 into use for receiving. 767 This message is the only valid message after key exchange, in addition 768 to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. The 769 purpose of this message is to ensure that a party is able to respond 770 with a disconnect message that the other party can understand if 771 something goes wrong with the key exchange. Implementations MUST NOT 772 accept any other messages after key exchange before receiving 773 SSH_MSG_NEWKEYS. 775 byte SSH_MSG_NEWKEYS 777 6. Diffie-Hellman Key Exchange 779 The Diffie-Hellman key exchange provides a shared secret that can not be 780 determined by either party alone. The key exchange is combined with a 781 signature with the host key to provide host authentication. 783 In the following description (C is the client, S is the server; p is a 784 large safe prime, g is a generator for a subgroup of GF(p), and q is the 785 order of the subgroup; V_S is S's version string; V_C is C's version 786 string; K_S is S's public host key; I_C is C's KEXINIT message and I_S 787 S's KEXINIT message which have been exchanged before this part begins): 789 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. 790 C sends "e" to S. 792 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. 793 S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || 794 I_C || I_S || K_S || e || f || K) (these elements are encoded 795 according to their types; see below), and signature s on H with its 796 private host key. S sends "K_S || f || s" to C. The signing 797 operation may involve a second hashing operation. 799 3. C verifies that K_S really is the host key for S (e.g. using 800 certificates or a local database). C is also allowed to accept the 801 key without verification; however, doing so will render the protocol 802 insecure against active attacks (but may be desirable for practical 803 reasons in the short term in many environments). C then computes K = 804 f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), 805 and verifies the signature s on H. 807 Either side MUST NOT send or accept e or f values that are not in the 808 range [1, p-1]. If this condition is violated, the key exchange 809 fails. 811 This is implemented with the following messages. The hash algorithm for 812 computing the exchange hash is defined by the method name, and is called 813 HASH. The public key algorithm for signing is negotiated with the 814 KEXINIT messages. 816 First, the client sends the following: 818 byte SSH_MSG_KEXDH_INIT 819 mpint e 821 The server responds with the following: 823 byte SSH_MSG_KEXDH_REPLY 824 string server public host key and certificates (K_S) 825 mpint f 826 string signature of H 828 The hash H is computed as the HASH hash of the concatenation of the 829 following: 831 string V_C, the client's version string (CR and NL excluded) 832 string V_S, the server's version string (CR and NL excluded) 833 string I_C, the payload of the client's SSH_MSG_KEXINIT 834 string I_S, the payload of the server's SSH_MSG_KEXINIT 835 string K_S, the host key 836 mpint e, exchange value sent by the client 837 mpint f, exchange value sent by the server 838 mpint K, the shared secret 840 This value is called the exchange hash, and it is used to authenticate 841 the key exchange. The exchange hash SHOULD be kept secret. 843 The signature algorithm MUST be applied over H, not the original data. 844 Most signature algorithms include hashing and additional padding. For 845 example, "ssh-dss" specifies SHA-1 hashing; in that case, the data is 846 first hashed with HASH to compute H, and H is then hashed with SHA-1 as 847 part of the signing operation. 849 6.1. diffie-hellman-group1-sha1 851 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key 852 exchange with SHA-1 as HASH, and the following group: 854 The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + 855 129093 ). Its hexadecimal value is: 857 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 858 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 859 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 860 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 861 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 862 FFFFFFFF FFFFFFFF. 864 In decimal, this value is: 866 179769313486231590770839156793787453197860296048756011706444 867 423684197180216158519368947833795864925541502180565485980503 868 646440548199239100050792877003355816639229553136239076508735 869 759914822574862575007425302077447712589550957937778424442426 870 617334727629299387668709205606050270810842907692932019128194 871 467627007. 873 The generator used with this prime is g = 2. The group order q is (p - 874 1) / 2. 876 This group was taken from the ISAKMP/Oakley specification, and was 877 originally generated by Richard Schroeppel at the University of Arizona. 878 Properties of this prime are described in [Orm96]. 880 7. Key Re-Exchange 882 Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when not 883 already doing a key exchange (as described in Section ``Algorithm 884 Negotiation''). When this message is received, a party MUST respond 885 with its own SSH_MSG_KEXINIT message except when the received 886 SSH_MSG_KEXINIT already was a reply. Either party MAY initiate the re- 887 exchange, but roles MUST NOT be changed (i.e., the server remains the 888 server, and the client remains the client). 890 Key re-exchange is performed using whatever encryption was in effect 891 when the exchange was started. Encryption, compression, and MAC methods 892 are not changed before a new SSH_MSG_NEWKEYS is sent after the key 893 exchange (as in the initial key exchange). Re-exchange is processed 894 identically to the initial key exchange, except for the session 895 identifier that will remain unchanged. It is permissible to change some 896 or all of the algorithms during the re-exchange. Host keys can also 897 change. All keys and initialization vectors are recomputed after the 898 exchange. Compression and encryption contexts are reset. 900 It is recommended that the keys are changed after each gigabyte of 901 transmitted data or after each hour of connection time, whichever comes 902 sooner. However, since the re-exchange is a public key operation, it 903 requires a fair amount of processing power and should not be performed 904 too often. 906 More application data may be sent after the SSH_MSG_NEWKEYS packet has 907 been sent; key exchange does not affect the protocols that lie above the 908 Secure Shell transport layer. 910 8. Service Request 912 After the key exchange, the client requests a service. The service is 913 identified by a name. The format of names and procedures for defining 914 new names are defined in [SECSH-ARCH]. 916 Currently, the following names have been reserved: 918 ssh-userauth 919 ssh-connection 921 Similar local naming policy is applied to the service names, as is 922 applied to the algorithm names; a local service should use the 923 "servicename@domain" syntax. 925 byte SSH_MSG_SERVICE_REQUEST 926 string service name 928 If the server rejects the service request, it SHOULD send an appropriate 929 SSH_MSG_DISCONNECT message and MUST disconnect. 931 When the service starts, it may have access to the session identifier 932 generated during the key exchange. 934 If the server supports the service (and permits the client to use it), 935 it MUST respond with the following: 937 byte SSH_MSG_SERVICE_ACCEPT 938 string service name 940 Message numbers used by services should be in the area reserved for them 941 (see Section ``Summary of Message Numbers''). The transport level will 942 continue to process its own messages. 944 Note that after a key exchange with implicit server authentication, the 945 client MUST wait for response to its service request message before 946 sending any further data. 948 9. Additional Messages 950 Either party may send any of the following messages at any time. 952 9.1. Disconnection Message 954 byte SSH_MSG_DISCONNECT 955 uint32 reason code 956 string description [RFC-2279] 957 string language tag [RFC-1766] 959 This message causes immediate termination of the connection. All 960 implementations MUST be able to process this message; they SHOULD be 961 able to send this message. 963 The sender MUST NOT send or receive any data after this message, and the 964 recipient MUST NOT accept any data after receiving this message. The 965 description field gives a more specific explanation in a human-readable 966 form. The error code gives the reason in a more machine-readable format 967 (suitable for localization), and can have the following values: 969 #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 970 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 971 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 972 #define SSH_DISCONNECT_RESERVED 4 973 #define SSH_DISCONNECT_MAC_ERROR 5 974 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 975 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 976 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 977 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 978 #define SSH_DISCONNECT_CONNECTION_LOST 10 979 #define SSH_DISCONNECT_BY_APPLICATION 11 980 #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 981 #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 982 #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 983 #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 985 If the description string is displayed, control character filtering 986 discussed in [SECSH-ARCH] should be used to avoid attacks by sending 987 terminal control characters. 989 9.2. Ignored Data Message 991 byte SSH_MSG_IGNORE 992 string data 994 All implementations MUST understand (and ignore) this message at any 995 time (after receiving the protocol version). No implementation is 996 required to send them. This message can be used as an additional 997 protection measure against advanced traffic analysis techniques. 999 9.3. Debug Message 1000 byte SSH_MSG_DEBUG 1001 boolean always_display 1002 string message [RFC-2279] 1003 string language tag [RFC-1766] 1005 All implementations MUST understand this message, but they are allowed 1006 to ignore it. This message is used to pass the other side information 1007 that may help debugging. If always_display is TRUE, the message SHOULD 1008 be displayed. Otherwise, it SHOULD NOT be displayed unless debugging 1009 information has been explicitly requested by the user. 1011 The message doesn't need to contain a newline. It is, however, allowed 1012 to consist of multiple lines separated by CRLF (Carriage Return - Line 1013 Feed) pairs. 1015 If the message string is displayed, terminal control character filtering 1016 discussed in [SECSH-ARCH] should be used to avoid attacks by sending 1017 terminal control characters. 1019 9.4. Reserved Messages 1021 An implementation MUST respond to all unrecognized messages with an 1022 SSH_MSG_UNIMPLEMENTED message in the order in which the messages were 1023 received. Such messages MUST be otherwise ignored. Later protocol 1024 versions may define other meanings for these message types. 1026 byte SSH_MSG_UNIMPLEMENTED 1027 uint32 packet sequence number of rejected message 1029 10. Summary of Message Numbers 1031 The following message numbers have been defined in this protocol: 1033 #define SSH_MSG_DISCONNECT 1 1034 #define SSH_MSG_IGNORE 2 1035 #define SSH_MSG_UNIMPLEMENTED 3 1036 #define SSH_MSG_DEBUG 4 1037 #define SSH_MSG_SERVICE_REQUEST 5 1038 #define SSH_MSG_SERVICE_ACCEPT 6 1040 #define SSH_MSG_KEXINIT 20 1041 #define SSH_MSG_NEWKEYS 21 1043 /* Numbers 30-49 used for kex packets. 1044 Different kex methods may reuse message numbers in 1045 this range. */ 1047 #define SSH_MSG_KEXDH_INIT 30 1048 #define SSH_MSG_KEXDH_REPLY 31 1050 11. Security Considerations 1052 This protocol provides a secure encrypted channel over an insecure 1053 network. It performs server host authentication, key exchange, 1054 encryption, and integrity protection. It also derives a unique session 1055 id that may be used by higher-level protocols. 1057 It is expected that this protocol will sometimes be used without 1058 insisting on reliable association between the server host key and the 1059 server host name. Such use is inherently insecure, but may be necessary 1060 in non-security critical environments, and still provides protection 1061 against passive attacks. However, implementors of protocols running on 1062 top of this protocol should keep this possibility in mind. 1064 This protocol is designed to be used over a reliable transport. If 1065 transmission errors or message manipulation occur, the connection is 1066 closed. The connection SHOULD be re-established if this occurs. Denial 1067 of service attacks of this type ("wire cutter") are almost impossible to 1068 avoid. 1070 The protocol was not designed to eliminate covert channels. For 1071 example, the padding, SSH_MSG_IGNORE messages, and several other places 1072 in the protocol can be used to pass covert information, and the 1073 recipient has no reliable way to verify whether such information is 1074 being sent. 1076 12. Trademark Issues 1078 "ssh" is a registered trademark of SSH Communications Security Corp in 1079 the United States and/or other countries. 1081 13. References 1083 [FIPS-186] Federal Information Processing Standards Publication (FIPS 1084 PUB) 186, Digital Signature Standard, 18 May 1994. 1086 [Orm96] Orman, H: "The Oakley Key Determination Protocol", version 1, 1087 TR97-92, Department of Computer Science Technical Report, University of 1088 Arizona. 1090 [RFC-2459] Housley, R., et al: "Internet X.509 Public Key 1091 Infrastructure, Certificate and CRL Profile", January 1999. 1093 [RFC-1034] Mockapetris, P: "Domain Names - Concepts and Facilities", 1094 November 1987. 1096 [RFC-1766] Alvestrand, H: "Tags for the Identification of Languages", 1097 March 1995. 1099 [RFC-1950] Deutch, P. and Gailly, J-L: "ZLIB Compressed Data Format 1100 Specification version 3.3", May 1996. 1102 [RFC-1951] Deutch, P: "DEFLATE Compressed Data Format Specification 1103 version 1.3", May 1996. 1105 [RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646", 1106 January 1998. 1108 [RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R: "HMAC: Keyed- 1109 Hashing for Message Authentication", February 1997 1111 [RFC-2119] Bradner, S: "Key words for use in RFCs to indicate 1112 Requirement Levels", March 1997. 1114 [RFC-2144] Adams, C: "The CAST-128 Encryption Algorithm", May 1997. 1116 [RFC-2440] Callas, J., et al: "OpenPGP Message Format", November 1998. 1118 [RFC-2693] Ellison, C., et al: "SPKI Certificate Theory", September 1119 1999. 1121 [SCHNEIER] Schneier, B: "Applied Cryptography Second Edition: protocols, 1122 algorithms, and source code in C", 2nd edition, John Wiley & Sons, New 1123 York, NY, 1996. 1125 [TWOFISH] Schneir, B., et al:"The Twofish Encryption Algorithm: A 1126 128-Bit Block Cipher", 1st edition, John Wiley & Sons, 22 March 1999 1128 [SECSH-ARCH] Ylonen, T., et al: "Secure Shell Remote Login Protocol 1129 Architecture", Internet-Draft, draft-ietf-secsh-architecture-08.txt 1131 [SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication 1132 Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt 1134 [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", 1135 Internet-Draft, draft-ietf-secsh-connect-10.txt 1137 14. Authors' Addresses 1139 Tatu Ylonen 1140 SSH Communications Security Corp 1141 Fredrikinkatu 42 1142 FIN-00100 HELSINKI 1143 Finland 1144 E-mail: ylo@ssh.com 1146 Tero Kivinen 1147 SSH Communications Security Corp 1148 Fredrikinkatu 42 1149 FIN-00100 HELSINKI 1150 Finland 1151 E-mail: kivinen@ssh.com 1153 Markku-Juhani O. Saarinen 1154 University of Jyvaskyla 1156 Timo J. Rinne 1157 SSH Communications Security Corp 1158 Fredrikinkatu 42 1159 FIN-00100 HELSINKI 1160 Finland 1161 E-mail: tri@ssh.com 1163 Sami Lehtinen 1164 SSH Communications Security Corp 1165 Fredrikinkatu 42 1166 FIN-00100 HELSINKI 1167 Finland 1168 E-mail: sjl@ssh.com