idnits 2.17.1 draft-ietf-secsh-newmodes-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.1 on line 43. -- Found old boilerplate from RFC 3978, Section 5.5 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 551), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 47. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 18, 2005) is 6819 days in the past. Is this intentional? 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: 'RFC2119' is mentioned on line 109, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' ** Downref: Normative reference to an Informational RFC: RFC 2144 -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'SERPENT' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bellare 3 Internet-Draft T. Kohno 4 Expires: February 18, 2006 UC San Diego 5 C. Namprempre 6 Thammasat University 7 August 18, 2005 9 SSH Transport Layer Encryption Modes 11 draft-ietf-secsh-newmodes-05.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 18, 2006. 40 By submitting this Internet-Draft, each author represents that any 41 applicable patent or other IPR claims of which he or she is aware 42 have been or will be disclosed, and any of which he or she becomes 43 aware will be disclosed, in accordance with Section 6 of BCP 79. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). All Rights Reserved. 49 Abstract 51 Researchers have discovered that the authenticated encryption portion 52 of the current SSH Transport Protocol is vulnerable to several 53 attacks. 55 This document describes new symmetric encryption methods for the SSH 56 Transport Protocol and gives specific recommendations on how 57 frequently SSH implementations should rekey. 59 In a paper at the Ninth ACM Conference on Computer and Communications 60 Security, Bellare, Kohno, and Namprempre prove that if an SSH 61 application implements the modifications described in this document, 62 then the symmetric cryptographic portion of that application will 63 provably resist chosen-plaintext, chosen-ciphertext, reaction-based 64 privacy, and integrity/authenticity attacks. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 70 3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3 72 3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 4 73 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 77 6.2 Encryption Method Considerations . . . . . . . . . . . . . . . 9 78 Normative References . . . . . . . . . . . . . . . . . . . . . 9 79 Non-Normative References . . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 81 Intellectual Property Statement . . . . . . . . . . . . . . . 12 82 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12 83 Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The symmetric portion of the SSH Transport Protocol was designed to 88 provide both privacy and integrity of encapsulated data. Researchers 89 ([DAI,BKN1,BKN2]) have, however, identified several security problems 90 with the symmetric portion of the SSH Transport Protocol as described 91 in [SSH-TRANS]. For example, the encryption mode specified in [SSH- 92 TRANS] is vulnerable to a chosen-plaintext privacy attack. 94 Additionally, if not rekeyed frequently enough, the SSH Transport 95 Protocol may leak information about payload data. This latter 96 property is true regardless of what encryption mode is used. 98 In [BKN1,BKN2] Bellare, Kohno, and Namprempre show how to modify the 99 symmetric portion of the SSH Transport Protocol so that it provably 100 preserves privacy and integrity against chosen-plaintext, chosen- 101 ciphertext, and reaction attacks. This document instantiates the 102 recommendations described in [BKN1,BKN2]. 104 2. Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 The used data types and terminology are specified in the architecture 111 document [SSH-ARCH]. 113 The SSH Transport Protocol is specified in the transport document 114 [SSH-TRANS]. 116 3. Rekeying 118 Section 9 of [SSH-TRANS] suggests that SSH implementations rekey 119 after every gigabyte of transmitted data. [SSH-TRANS] does not, 120 however, discuss all the problems that could arise if an SSH 121 implementation does not rekey frequently enough. This section serves 122 to strengthen the suggestion in [SSH-TRANS] by giving firm upper 123 bounds on the tolerable number of encryptions between rekeying 124 operations. In Section 6 we discuss the motivation for these 125 rekeying recommendations in more detail. 127 This section makes two recommendations. Informally, the first 128 recommendation is intended to protects against possible information 129 leakage through the MAC tag and the second recommendation is intended 130 to protect against possible information leakage through the block 131 cipher. Note that, depending on the block length of the underlying 132 block cipher and the length of the encrypted packets, the first 133 recommendation may supersede the second recommendation, or vice 134 versa. 136 3.1 First Rekeying Recommendation 138 Because of possible information leakage through the MAC tag, SSH 139 implementations SHOULD rekey at least once every 2**32 outgoing 140 packets. More explicitly, after a key exchange an SSH implementation 141 SHOULD NOT send more than 2**32 packets before rekeying again. 143 SSH implementations SHOULD also attempt to rekey before receiving 144 more than 2**32 packets since the last rekey operation. The 145 preferred way to do this is to rekey after receiving more than 2**31 146 packets since the last rekey operation. 148 3.2 Second Rekeying Recommendation 150 Because of a birthday property of block ciphers and some modes of 151 operation, implementations must be careful not to encrypt too many 152 blocks with the same encryption key. 154 Let L be the block length (in bits) of an SSH encryption method's 155 block cipher (e.g., 128 for AES). If L is at least 128 then, after 156 rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4) 157 blocks before rekeying again. If L is at least 128, then SSH 158 implementations should also attempt to force a rekey before receiving 159 more than 2**(L/4) blocks. If L is less than 128 (which is the case 160 for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, 161 although it may be too expensive to rekey every 2**(L/4) blocks, it 162 is still advisable for SSH implementations to follow the original 163 recommendation in [SSH-TRANS]: rekey at least once every gigabyte of 164 transmitted data. 166 Note that if L is less than or equal to 128, then the recommendation 167 in this subsection supersedes the recommendation in Section 3.1. If 168 an SSH implementation uses a block cipher with a larger block size 169 (e.g., Rijndael with 256-bit blocks), then the recommendations in the 170 above paragraph may supersede the recommendations in this paragraph 171 (depending on the lengths of the packets). 173 4. Encryption Modes 175 This document describes new encryption methods for use with the SSH 176 Transport Protocol. These encryption methods are in addition to the 177 encryption methods described in Section 6.3 of [SSH-TRANS]. 179 Recall from [SSH-TRANS] that the encryption methods in each direction 180 of an SSH connection MUST run independently of each other and that, 181 when encryption is in effect, the packet length, padding length, 182 payload, and padding fields of each packet MUST be encrypted with the 183 chosen method. Further recall that the total length of the 184 concatenation of the packet length, padding length, payload, and 185 padding MUST be a multiple of the cipher's block size when the 186 cipher's block size is greater than or equal to 8 bytes (which is the 187 case for all of the following methods). 189 This document describes the following new methods: 191 aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, 192 with 128-bit key 193 aes192-ctr RECOMMENDED AES with 192-bit key 194 aes256-ctr RECOMMENDED AES with 256-bit key 195 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode 196 blowfish-ctr OPTIONAL Blowfish in SDCTR mode 197 twofish128-ctr OPTIONAL Twofish in SDCTR mode, 198 with 128-bit key 199 twofish192-ctr OPTIONAL Twofish with 192-bit key 200 twofish256-ctr OPTIONAL Twofish with 256-bit key 201 serpent128-ctr OPTIONAL Serpent in SDCTR mode, with 202 with 128-bit key 203 serpent192-ctr OPTIONAL Serpent with 192-bit key 204 serpent256-ctr OPTIONAL Serpent with 256-bit key 205 idea-ctr OPTIONAL IDEA in SDCTR mode 206 cast128-ctr OPTIONAL CAST-128 in SDCTR mode, 207 with 128-bit key 209 The label -ctr means that the block cipher is to be 210 used in "stateful-decryption counter" (SDCTR) mode. Let L be the 211 block length of in bits. In stateful-decryption counter 212 mode both the sender and the receiver maintain an internal L-bit 213 counter X. The initial value of X should be the initial IV (as 214 computed in Section 7.2 of [SSH-TRANS]) interpreted as an L-bit 215 unsigned integer in network-byte-order. If X=(2**L)-1, then 216 "increment X" has the traditional semantics of "set X to 0." We use 217 the notation to mean "convert X to an L-bit string in network- 218 byte-order." Naturally, implementations may differ in how the 219 internal value X is stored. For example, implementations may store X 220 as multiple unsigned 32-bit counters. 222 To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each 223 blocks of length L), the encryptor first encrypts with 224 to obtain a block B1. The block B1 is then XORed with P1 to generate 225 the ciphertext block C1. The counter X is then incremented and the 226 process is repeated for each subsequent block in order to generate 227 the entire ciphertext C=C1||C2||...||Cn corresponding to the packet 228 P. Note that the counter X is not included in the ciphertext. Also 229 note that the keystream can be pre-computed and that encryption is 230 parallelizable. 232 To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also 233 maintains its own copy of X), first encrypts its copy of with 234 to generate a block B1 and then XORs B1 to C1 to get P1. 235 The decryptor then increments its copy of the counter X and repeats 236 the above process for each block to obtain the plaintext packet 237 P=P1||P2||...||Pn. As before, the keystream can be pre-computed and 238 decryption is parallelizable. 240 The "aes128-ctr" method uses AES (the Advanced Encryption Standard, 241 formerly Rijndael) with 128-bit keys [AES]. The block size is 16 242 bytes. 244 The "aes192-ctr" method uses AES with 192-bit keys. 246 The "aes256-ctr" method uses AES with 256-bit keys. 248 The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt- 249 encrypt), where the first 8 bytes of the key are used for the first 250 encryption, the next 8 bytes for the decryption, and the following 8 251 bytes for the final encryption. This requires 24 bytes of key data 252 (of which 168 bits are actually used). The block size is 8 bytes. 253 This algorithm is defined in [DES]. 255 The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER]. 256 The block size is 8 bytes. (Note that "blowfish-cbc" from [SSH- 257 TRANS] uses 128-bit keys.) 259 The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. 260 The block size is 16 bytes. 262 The "twofish192-ctr" method uses Twofish with 192-bit keys. 264 The "twofish256-ctr" method uses Twofish with 256-bit keys. 266 The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] 267 with 128-bit keys. The block size is 16 bytes. 269 The "serpent192-ctr" method uses Serpent with 192-bit keys. 271 The "serpent256-ctr" method uses Serpent with 256-bit keys. 273 The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block 274 size is 8 bytes. 276 The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys 277 [RFC2144]. The block size is 8 bytes. 279 5. IANA Considerations 281 The twelve encryption algorithm names defined in Section 4 are to be 282 added to the Secure Shell Encryption Algorithm Name registry 283 established by Section 4.11.1 of [SSH-IANA]. 285 6. Security Considerations 287 This document describes additional encryption methods and 288 recommendations for the SSH Transport Protocol [SSH-TRANS]. 289 [BKN1,BKN2] prove that if an SSH application incorporates the methods 290 and recommendations described in this document, then the symmetric 291 cryptographic portion of that application will resist a large class 292 of privacy and integrity attacks. 294 This section is designed to help implementors understand the 295 security-related motivations for, as well as possible consequences of 296 deviating from, the methods and recommendations described in this 297 document. Additional motivation and discussion, as well as proofs of 298 security, appear in the research paper [BKN1,BKN2]. 300 Please note that the notion of "prove" in the context of [BKN1,BKN2] 301 is that of practice-oriented reductionist security: if an attacker is 302 able to break the symmetric portion of the SSH Transport Protocol 303 using a certain type of attack (e.g., a chosen-ciphertext attack), 304 then the attacker will also be able to break one of the transport 305 protocol's underlying components (e.g., the underlying block cipher 306 or MAC). If we make the reasonable assumption that the underlying 307 components (such as AES and HMAC-SHA1) are secure, then the attacker 308 against the symmetric portion of the SSH protocol cannot be very 309 successful (since otherwise there would be a contradiction). Please 310 see [BKN1,BKN2] for details. In particular, attacks are not 311 impossible; just extremely improbable (unless the building blocks, 312 like AES, are insecure). 314 Note also that cryptography often plays only a small (but critical) 315 role in an application's overall security. In the case of the SSH 316 Transport Protocol, even though an application might implement the 317 symmetric portion of the SSH protocol exactly as described in this 318 document, the application may still be vulnerable to non-protocol- 319 based attacks (as an egregious example, an application might save 320 cryptographic keys in cleartext to an unprotected file). 321 Consequently, even though the methods described herein come with 322 proofs of security, developers must still execute caution when 323 developing applications that implement these methods. 325 6.1 Rekeying Considerations 327 Section 3 of this document makes two rekeying recommendations: (1) 328 rekey at least once every 2**32 packets and (2) rekey after a certain 329 number of encrypted blocks (e.g., 2**(L/4) blocks if the block 330 cipher's block length L is at least 128 bits). The motivations for 331 recommendations (1) and (2) are different, and we consider each 332 recommendation in turn. Briefly, (1) is designed to protect against 333 information leakage through the SSH protocol's underlying MAC and (2) 334 is designed to protect against information leakage through the SSH 335 protocol's underlying encryption scheme. Please note that, depending 336 on the encryption method's block length L and the number of blocks 337 encrypted per packet, recommendation (1) may supersede recommendation 338 (2) or vice versa. 340 Recommendation (1) states that SSH implementations should rekey at 341 least once every 2**32 packets. If more than 2**32 packets are 342 encrypted and MACed by the SSH Transport Protocol between rekeyings, 343 then the SSH Transport Protocol may become vulnerable to replay and 344 re-ordering attacks, meaning that an adversary may be able to 345 convince the receiver to accept the same message more than once or to 346 accept messages out of order. Additionally, the underlying MAC may 347 begin to leak information about the protocol's payload data. In more 348 detail, an adversary looks for a collision between the MACs 349 associated to two packets that were MACed with the same 32-bit 350 sequence number (see Section 4.4 of [SSH-TRANS]); if a collision is 351 found, then the payload data associated with those two ciphertexts is 352 probably identical. Note that this problem occurs regardless of how 353 secure the underlying encryption method is. Also note that although 354 compressing payload data before encrypting and MACing and the use of 355 random padding may reduce the risk of information leakage through the 356 underlying MAC, compression and the use of random padding will not 357 prevent information leakage. Implementors who decide not to rekey at 358 least once every 2**32 packets should understand these issues. These 359 issues are discussed further in [BKN1,BKN2]. 361 One alternative to recommendation (1) would be to make the SSH 362 Transport Protocol's sequence number more than 32 bits long. This 363 document does not suggest increasing the length of the sequence 364 number because doing so could hinder interoperability with older 365 version of the SSH protocol. Another alternative to recommendation 366 (1) would be to switch from basic HMAC to a another MAC, such as a 367 MAC that has its own internal counter (because of the 32-bit counter 368 already present in the protocol, such a counter would only need to be 369 incremented once every 2**32 packets). 371 Recommendation (2) states that SSH implementations should rekey 372 before encrypting more than 2**(L/4) blocks with the same key 373 (assuming L is at least 128). This recommendation is designed to 374 minimize the risk of birthday attacks against the encryption method's 375 underlying block cipher. For example, there is a theoretical privacy 376 attack against stateful-decryption counter mode if an adversary is 377 allowed to encrypt approximately 2**(L/2) messages with the same key. 378 It is because of these birthday attacks that implementors are highly 379 encouraged to use secure block ciphers with large block lengths. 380 Additionally, recommendation (2) is designed to protect an encryptor 381 from encrypting more than 2**L blocks with the same key. The 382 motivation here is that, if an encryptor were to use SDCTR mode to 383 encrypt more than 2**L blocks with the same key, then the encryptor 384 would reuse keystream, and the reuse of keystream can lead to serious 385 privacy attacks [SCHNEIER]. 387 6.2 Encryption Method Considerations 389 Researchers have shown that the original CBC-based encryption methods 390 in [SSH-TRANS] are vulnerable to chosen-plaintext privacy attacks 391 [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption 392 methods described in Section 4 of this document were designed to be 393 secure replacements to the original encryption methods described in 394 [SSH-TRANS]. 396 Many people shy away from counter mode-based encryption schemes 397 because, when used incorrectly (such as when the keystream is allowed 398 to repeat), counter mode can be very insecure. Fortunately, the 399 common concerns with counter mode do not apply to SSH because of the 400 rekeying recommendations and because of the additional protection 401 provided by the transport protocol's MAC. This discussion is 402 formalized with proofs of security in [BKN1,BKN2]. 404 As an additional note, when one of the stateful-decryption counter 405 mode encryption methods (Section 4) is used, then the padding 406 included in an SSH packet (Section 4 of [SSH-TRANS]) need not be (but 407 can still be) random. This eliminates the need to generate 408 cryptographically-secure pseudorandom bytes for each packet. 410 One property of counter mode encryption is that it does not require 411 messages to be padded to a multiple of the block cipher's block 412 length. Although not padding messages can reduce the protocol's 413 network consumption, this document requires padding to be a multiple 414 of the block cipher's block length in order to (1) not alter the 415 packet description in [SSH-TRANS] and (2) not leak precise 416 information about the length of the packet's payload data. (Although 417 there may be some network savings from padding to only 8-bytes even 418 if the block cipher uses 16-byte blocks, because of (1) we do not 419 make that recommendation here.) 421 In addition to stateful-decryption counter mode, [BKN1,BKN2] describe 422 other provably-secure encryption methods for use with the SSH 423 Transport Protocol. The stateful-decryption counter mode methods in 424 Section 4 are, however, the preferred alternatives to the insecure 425 methods in [SSH-TRANS] because stateful-decryption counter mode is 426 the most efficient (both in terms of network consumption and in terms 427 of the number of required cryptographic operations per packet). 429 Normative References 431 [AES] National Institute of Standards and Technology, 432 "Advanced Encryption Standard (AES)", Federal 433 Information Processing Standards Publication 197, 434 November 2001. 436 [DES] National Institute of Standards and Technology, 437 "Data Encryption Standard (DES)", Federal Information 438 Processing Standards Publication 46-3, October 1999. 440 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 441 2144, May 1997. 443 [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: 444 Protocols algorithms and source in code in C", Wiley, 445 1996. 447 [SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A 448 proposal for the Advanced Encryption Standard", NIST 449 AES Proposal, 1998. 451 [SSH-ARCH] Ylonen, T. and Lonvick, C., "SSH Protocol 452 Architecture", I-D 453 draft-ietf-secsh-architecture-22.txt, March 2005. 455 [SSH-IANA] Lehtinen, S. and Lonvick, C., "SSH Protocol Assigned 456 Numbers", I-D 457 draft-ietf-secsh-assignednumbers-12.txt, March 2005. 459 [SSH-TRANS] Ylonen, T. and Lonvick, C., "SSH Transport Layer 460 Protocol", I-D draft-ietf-secsh-transport-24.txt, 461 March 2005. 463 [TWOFISH] Schneier, B., et. al., "The Twofish Encryptions 464 Algorithm: A 128-bit block cipher, 1st Edition", 465 Wiley, 1999. 467 Non-Normative References 469 [BKN1] Bellare, M., Kohno, T., and Namprempre, C., 470 "Authenticated Encryption in SSH: Provably Fixing the 471 SSH Binary Packet Protocol", Ninth ACM Conference on 472 Computer and Communications Security, 2002. 474 [BKN2] Bellare, M., Kohno, T., and Namprempre, C., 475 "Breaking and Provably Repairing the SSH 476 Authenticated Encryption Scheme: A Case Study of the 477 Encode-then-Encrypt-and-MAC Paradigm", 478 ACM Transactions on Information and System Security, 479 7(2), May 2004. 481 [DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to 482 the ietf-ssh@netbsd.org email list, 2002. 484 Authors' Addresses: 486 Mihir Bellare 487 Department of Computer Science and Engineering 488 University of California at San Diego 489 9500 Gilman Drive, MC 0114 490 La Jolla, CA 92093-0114 492 Phone: +1 858-822-2977 493 EMail: mihir@cs.ucsd.edu 495 Tadayoshi Kohno 496 Department of Computer Science and Engineering 497 University of California at San Diego 498 9500 Gilman Drive, MC 0114 499 La Jolla, CA 92093-0114 501 Phone: +1 858-822-2977 502 EMail: tkohno@cs.ucsd.edu 504 Chanathip Namprempre 505 Thammasat University 506 Faculty of Engineering 507 Electrical Engineering Department 508 Rangsit Campus, Klong Luang 509 Pathumthani, Thailand 12121 511 EMail: meaw@alum.mit.edu 513 Intellectual Property Statement 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed to 517 pertain to the implementation or use of the technology described in 518 this document or the extent to which any license under such rights 519 might or might not be available; nor does it represent that it has 520 made any independent effort to identify any such rights. Information 521 on the procedures with respect to rights in RFC documents can be 522 found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use of 527 such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository at 529 http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at ietf- 535 ipr@ietf.org. 537 Disclaimer of Validity 539 This document and the information contained herein are provided on an 540 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 541 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 542 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 543 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 544 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 545 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 547 Copyright Statement 549 Copyright (C) The Internet Society (2005). This document is subject 550 to the rights, licenses and restrictions contained in BCP 78, and 551 except as set forth therein, the authors retain all their rights. 553 Acknowledgments 555 Mihir Bellare and Chanathip Namprempre were supported by NSF Grant 556 CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership 557 Development Award. Tadayoshi Kohno was supported by a National 558 Defense Science and Engineering Graduate Fellowship and an IBM Ph.D. 559 Fellowship.