| < draft-ietf-secsh-newmodes-04.txt | draft-ietf-secsh-newmodes-05.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Bellare | Network Working Group M. Bellare | |||
| Internet-Draft T. Kohno | Internet-Draft T. Kohno | |||
| Expires: October 8, 2005 UC San Diego | Expires: February 18, 2006 UC San Diego | |||
| C. Namprempre | C. Namprempre | |||
| Thammasat University | Thammasat University | |||
| April 8, 2005 | August 18, 2005 | |||
| SSH Transport Layer Encryption Modes | SSH Transport Layer Encryption Modes | |||
| draft-ietf-secsh-newmodes-04.txt | draft-ietf-secsh-newmodes-05.txt | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is subject to all provisions | This document is an Internet-Draft and is subject to all provisions | |||
| of Section 3 of RFC 3667. By submitting this Internet-Draft, each | of Section 3 of RFC 3667. By submitting this Internet-Draft, each | |||
| author represents that any applicable patent or other IPR claims of | author represents that any applicable patent or other IPR claims of | |||
| which he or she is aware have been or will be disclosed, and any of | which he or she is aware have been or will be disclosed, and any of | |||
| which he or she become aware will be disclosed, in accordance with | which he or she become aware will be disclosed, in accordance with | |||
| RFC 3668. | RFC 3668. | |||
| skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on October 8, 2005. | This Internet-Draft will expire on February 18, 2006. | |||
| By submitting this Internet-Draft, each author represents that any | ||||
| applicable patent or other IPR claims of which he or she is aware | ||||
| have been or will be disclosed, and any of which he or she becomes | ||||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
| Abstract | Abstract | |||
| Researchers have discovered that the authenticated encryption portion | Researchers have discovered that the authenticated encryption portion | |||
| of the current SSH Transport Protocol is vulnerable to several | of the current SSH Transport Protocol is vulnerable to several | |||
| attacks. | attacks. | |||
| This document describes new symmetric encryption methods for the SSH | This document describes new symmetric encryption methods for the SSH | |||
| Transport Protocol and gives specific recommendations on how | Transport Protocol and gives specific recommendations on how | |||
| frequently SSH implementations should rekey. | frequently SSH implementations should rekey. | |||
| Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH | In a paper at the Ninth ACM Conference on Computer and Communications | |||
| Security, Bellare, Kohno, and Namprempre prove that if an SSH | ||||
| application implements the modifications described in this document, | application implements the modifications described in this document, | |||
| then the symmetric cryptographic portion of that application will | then the symmetric cryptographic portion of that application will | |||
| provably resist chosen-plaintext, chosen-ciphertext, reaction-based | provably resist chosen-plaintext, chosen-ciphertext, reaction-based | |||
| privacy and integrity/authenticity attacks. | privacy, and integrity/authenticity attacks. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | |||
| 3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3 | 3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3 | |||
| 3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 3 | 3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 4 | |||
| 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
| 6.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 | 6.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
| 6.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8 | 6.2 Encryption Method Considerations . . . . . . . . . . . . . . . 9 | |||
| Normative References . . . . . . . . . . . . . . . . . . . . . 9 | Normative References . . . . . . . . . . . . . . . . . . . . . 9 | |||
| Non-Normative References . . . . . . . . . . . . . . . . . . . 10 | Non-Normative References . . . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| Intellectual Property Statement . . . . . . . . . . . . . . . 12 | Intellectual Property Statement . . . . . . . . . . . . . . . 12 | |||
| Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12 | Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12 | |||
| Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 | Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 1. Introduction | 1. Introduction | |||
| The symmetric portion of the SSH Transport Protocol was designed to | The symmetric portion of the SSH Transport Protocol was designed to | |||
| provide both privacy and integrity of encapsulated data. Researchers | provide both privacy and integrity of encapsulated data. Researchers | |||
| ([DAI,BKN1,BKN2]) have, however, identified several security problems | ([DAI,BKN1,BKN2]) have, however, identified several security problems | |||
| with the symmetric portion of the SSH Transport Protocol as described | with the symmetric portion of the SSH Transport Protocol as described | |||
| skipping to change at page 5, line 10 ¶ | skipping to change at page 5, line 20 ¶ | |||
| blowfish-ctr OPTIONAL Blowfish in SDCTR mode | blowfish-ctr OPTIONAL Blowfish in SDCTR mode | |||
| twofish128-ctr OPTIONAL Twofish in SDCTR mode, | twofish128-ctr OPTIONAL Twofish in SDCTR mode, | |||
| with 128-bit key | with 128-bit key | |||
| twofish192-ctr OPTIONAL Twofish with 192-bit key | twofish192-ctr OPTIONAL Twofish with 192-bit key | |||
| twofish256-ctr OPTIONAL Twofish with 256-bit key | twofish256-ctr OPTIONAL Twofish with 256-bit key | |||
| serpent128-ctr OPTIONAL Serpent in SDCTR mode, with | serpent128-ctr OPTIONAL Serpent in SDCTR mode, with | |||
| with 128-bit key | with 128-bit key | |||
| serpent192-ctr OPTIONAL Serpent with 192-bit key | serpent192-ctr OPTIONAL Serpent with 192-bit key | |||
| serpent256-ctr OPTIONAL Serpent with 256-bit key | serpent256-ctr OPTIONAL Serpent with 256-bit key | |||
| idea-ctr OPTIONAL IDEA in SDCTR mode | idea-ctr OPTIONAL IDEA in SDCTR mode | |||
| cast128-ctr OPTIONAL CAST-128 in SDCTR mode | cast128-ctr OPTIONAL CAST-128 in SDCTR mode, | |||
| with 128-bit key | ||||
| The label <cipher>-ctr means that the block cipher <cipher> is to be | The label <cipher>-ctr means that the block cipher <cipher> is to be | |||
| used in "stateful-decryption counter" (SDCTR) mode. Let L be the | used in "stateful-decryption counter" (SDCTR) mode. Let L be the | |||
| block length of <cipher> in bits. In stateful-decryption counter | block length of <cipher> in bits. In stateful-decryption counter | |||
| mode both the sender and the receiver maintain an internal L-bit | mode both the sender and the receiver maintain an internal L-bit | |||
| counter X. The initial value of X should be the initial IV (as | counter X. The initial value of X should be the initial IV (as | |||
| computed in Section 7.2 of [SSH-TRANS]) interpreted as an L-bit | computed in Section 7.2 of [SSH-TRANS]) interpreted as an L-bit | |||
| unsigned integer in network-byte-order. If X=(2**L)-1, then | unsigned integer in network-byte-order. If X=(2**L)-1, then | |||
| "increment X" has the traditional semantics of "set X to 0." We use | "increment X" has the traditional semantics of "set X to 0." We use | |||
| the notation <X> to mean "convert X to an L-bit string in network- | the notation <X> to mean "convert X to an L-bit string in network- | |||
| skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 38 ¶ | |||
| The "twofish256-ctr" method uses Twofish with 256-bit keys. | The "twofish256-ctr" method uses Twofish with 256-bit keys. | |||
| The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] | The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] | |||
| with 128-bit keys. The block size is 16 bytes. | with 128-bit keys. The block size is 16 bytes. | |||
| The "serpent192-ctr" method uses Serpent with 192-bit keys. | The "serpent192-ctr" method uses Serpent with 192-bit keys. | |||
| The "serpent256-ctr" method uses Serpent with 256-bit keys. | The "serpent256-ctr" method uses Serpent with 256-bit keys. | |||
| The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. | The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block | |||
| size is 8 bytes. | ||||
| The "cast128-ctr" method uses the CAST-128 cipher [RFC2144]. The | The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys | |||
| block size is 8 bytes. | [RFC2144]. The block size is 8 bytes. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| The twelve encryption algorithm names defined in Section 4 are to be | The twelve encryption algorithm names defined in Section 4 are to be | |||
| added to the Secure Shell Encryption Algorithm Name registry | added to the Secure Shell Encryption Algorithm Name registry | |||
| established by Section 4.11.1 of [SSH-IANA]. | established by Section 4.11.1 of [SSH-IANA]. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| This document describes additional encryption methods and | This document describes additional encryption methods and | |||
| skipping to change at page 8, line 38 ¶ | skipping to change at page 8, line 48 ¶ | |||
| Recommendation (2) states that SSH implementations should rekey | Recommendation (2) states that SSH implementations should rekey | |||
| before encrypting more than 2**(L/4) blocks with the same key | before encrypting more than 2**(L/4) blocks with the same key | |||
| (assuming L is at least 128). This recommendation is designed to | (assuming L is at least 128). This recommendation is designed to | |||
| minimize the risk of birthday attacks against the encryption method's | minimize the risk of birthday attacks against the encryption method's | |||
| underlying block cipher. For example, there is a theoretical privacy | underlying block cipher. For example, there is a theoretical privacy | |||
| attack against stateful-decryption counter mode if an adversary is | attack against stateful-decryption counter mode if an adversary is | |||
| allowed to encrypt approximately 2**(L/2) messages with the same key. | allowed to encrypt approximately 2**(L/2) messages with the same key. | |||
| It is because of these birthday attacks that implementors are highly | It is because of these birthday attacks that implementors are highly | |||
| encouraged to use secure block ciphers with large block lengths. | encouraged to use secure block ciphers with large block lengths. | |||
| Additionally, recommendation (2) is designed to protect an encryptor | ||||
| from encrypting more than 2**L blocks with the same key. The | ||||
| motivation here is that, if an encryptor were to use SDCTR mode to | ||||
| encrypt more than 2**L blocks with the same key, then the encryptor | ||||
| would reuse keystream, and the reuse of keystream can lead to serious | ||||
| privacy attacks [SCHNEIER]. | ||||
| 6.2 Encryption Method Considerations | 6.2 Encryption Method Considerations | |||
| Researchers have shown that the original CBC-based encryption methods | Researchers have shown that the original CBC-based encryption methods | |||
| in [SSH-TRANS] are vulnerable to chosen-plaintext privacy attacks | in [SSH-TRANS] are vulnerable to chosen-plaintext privacy attacks | |||
| [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption | [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption | |||
| methods described in Section 4 of this document were designed to be | methods described in Section 4 of this document were designed to be | |||
| secure replacements to the original encryption methods described in | secure replacements to the original encryption methods described in | |||
| [SSH-TRANS]. | [SSH-TRANS]. | |||
| skipping to change at page 9, line 21 ¶ | skipping to change at page 9, line 37 ¶ | |||
| can still be) random. This eliminates the need to generate | can still be) random. This eliminates the need to generate | |||
| cryptographically-secure pseudorandom bytes for each packet. | cryptographically-secure pseudorandom bytes for each packet. | |||
| One property of counter mode encryption is that it does not require | One property of counter mode encryption is that it does not require | |||
| messages to be padded to a multiple of the block cipher's block | messages to be padded to a multiple of the block cipher's block | |||
| length. Although not padding messages can reduce the protocol's | length. Although not padding messages can reduce the protocol's | |||
| network consumption, this document requires padding to be a multiple | network consumption, this document requires padding to be a multiple | |||
| of the block cipher's block length in order to (1) not alter the | of the block cipher's block length in order to (1) not alter the | |||
| packet description in [SSH-TRANS] and (2) not leak precise | packet description in [SSH-TRANS] and (2) not leak precise | |||
| information about the length of the packet's payload data. (Although | information about the length of the packet's payload data. (Although | |||
| there may be some networks savings from padding to only 8-bytes even | there may be some network savings from padding to only 8-bytes even | |||
| if the block cipher uses 16-byte blocks, because of (1) we do not | if the block cipher uses 16-byte blocks, because of (1) we do not | |||
| make that recommendation here.) | make that recommendation here.) | |||
| In addition to stateful-decryption counter mode, [BKN1,BKN2] describe | In addition to stateful-decryption counter mode, [BKN1,BKN2] describe | |||
| other provably-secure encryption methods for use with the SSH | other provably-secure encryption methods for use with the SSH | |||
| Transport Protocol. The stateful-decryption counter mode methods in | Transport Protocol. The stateful-decryption counter mode methods in | |||
| Section 4 are, however, the preferred alternatives to the insecure | Section 4 are, however, the preferred alternatives to the insecure | |||
| methods in [SSH-TRANS] because stateful-decryption counter mode is | methods in [SSH-TRANS] because stateful-decryption counter mode is | |||
| the most efficient (both in terms of network consumption and in terms | the most efficient (both in terms of network consumption and in terms | |||
| of the number of required cryptographic operations per packet). | of the number of required cryptographic operations per packet). | |||
| End of changes. 14 change blocks. | ||||
| 14 lines changed or deleted | 28 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||