idnits 2.17.1 draft-altman-telnet-enc-des3-cfb-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 229 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9194 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) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jeffrey Altman 2 Internet-Draft Columbia University 3 draft-altman-telnet-enc-des3-cfb-01.txt February 1999 5 Telnet Encryption: DES3 64 bit Cipher Feedback 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 Abstract 32 This document specifies how to use the Triple-DES encryption algorithm 33 in cipher feedback mode with the telnet encryption option. 35 1. Command Names and Codes 37 Encryption Type 39 DES3_CFB64 3 41 Suboption Commands 43 CFB64_IV 1 44 CFB64_IV_OK 2 45 CFB64_IV_BAD 3 47 2. Command Meanings 49 IAC SB ENCRYPT IS DES3_CFB64 CFB64_IV IAC SE 51 The sender of this command generates a random 8 byte initial vec- 52 tor, and sends it to the other side of the connection using the 53 CFB64_IV command. The initial vector is sent in clear text. Only 54 the side of the connection that is WILL ENCRYPT may send the 55 CFB64_IV command. 57 IAC SB ENCRYPT REPLY DES3_CFB64 CFB64_IV_OK IAC SE 58 IAC SB ENCRYPT REPLY DES3_CFB64 CFB64_IV_BAD IAC SE 60 The sender of these commands either accepts or rejects the initial 61 vector received in a CFB64_IV command. Only the side of the con- 62 nection that is DO ENCRYPT may send the CFB64_IV_OK and 63 CFB64_IV_BAD commands. The CFB64_IV_OK command MUST be sent for 64 backwards compatibility with existing implementations; there real- 65 ly isn't any reason why a sender would need to send the 66 CFB64_IV_BAD command except in the case of a protocol violation 67 where the IV sent was not of the correct length (i.e., 8 bytes). 69 3. Implementation Rules 71 Once a CFB64_IV_OK command has been received, the WILL ENCRYPT side 72 of the connection should do keyid negotiation using the ENC_KEYID 73 command. Once the keyid negotiation has successfully identified a 74 common keyid, then START and END commands may be sent by the side of 75 the connection that is WILL ENCRYPT. Data will be encrypted using 76 the DES3 64 bit Cipher Feedback algorithm. 78 If encryption (decryption) is turned off and back on again, and the 79 same keyid is used when re-starting the encryption (decryption), the 80 intervening clear text must not change the state of the encryption 81 (decryption) machine. 83 If a START command is sent (received) with a different keyid, the en- 84 cryption (decryption) machine must be re-initialized immediately fol- 85 lowing the end of the START command with the new key and the initial 86 vector sent (received) in the last CFB64_IV command. 88 If a new CFB64_IV command is sent (received), and encryption (decryp- 89 tion) is enabled, the encryption (decryption) machine must be re-ini 90 tialized immediately following the end of the CFB64_IV command with 91 the new initial vector, and the keyid sent (received) in the last 92 START command. 94 If encryption (decryption) is not enabled when a CFB64_IV command is 95 sent (received), the encryption (decryption) machine must be re-ini 96 tialized after the next START command, with the keyid sent (received) 97 in that START command, and the initial vector sent (received) in this 98 CFB64_IV command. 100 4. Algorithm 102 DES3 64 bit Cipher Feedback 104 key1 key2 key3 105 | | | 106 v v v 107 +-------+ +-------+ +-------+ 108 +->| DES-e |->| DES-d |->| DES-e |-- + 109 | +-------+ +-------+ +-------+ | 110 | v 111 INPUT --(-------------------------------->(+)+---> DATA 112 | | 113 +------------------------------------+ 115 Given: 116 iV: Initial vector, 64 bits (8 bytes) long. 117 Dn: the nth chunk of 64 bits (8 bytes) of data to encrypt (decrypt). 118 On: the nth chunk of 64 bits (8 bytes) of encrypted (decrypted) output. 120 V0 = DES-e(DES-d(DES-e(iV, key1),key2),key3) 121 On = Dn ^ Vn 122 V(n+1) = DES-e(DES-d(DES-e(On, key1),key2),key3) 124 5. Integration with the AUTHENTICATION telnet option 126 As noted in the telnet ENCRYPTION option specifications, a keyid val- 127 ue of zero indicates the default encryption key, as might be derived 128 from the telnet AUTHENTICATION option. If the default encryption key 129 negotiated as a result of the telnet AUTHENTICATION option contains 130 less than 16 bytes, then the DES_CFB64 option must not be offered or 131 used as a valid telnet encryption option. 133 The following rules are to be followed for creating three DES encryp- 134 tion keys based upon the available encrypt key data: 136 keys_to_use = bytes of key data / DES block size (8 bytes) 138 where the keys are labeled "key1" through "key6" with "key1" being 139 the first 8 bytes; "key2" the second 8 bytes; ... and "key6" being 140 sixth 8 bytes (if available). 142 When two keys are available: 144 . data sent from the server is encrypted with key1, decrypted with 145 key2, and encrypted with key1; 147 . data sent from the client is encrypted with key2, decrypted with 148 key1, and encrypted with key2 150 When three keys are available: 152 . data sent from the server is encrypted with key1, decrypted with 153 key2, and encrypted with key3; 155 . data sent from the client is encrypted with key2, decrypted with 156 key3, and encrypted with key1 158 When four keys are available: 160 . data sent from the server is encrypted with key1, decrypted with 161 key2, and encrypted with key3; 163 . data sent from the client is encrypted with key2, decrypted with 164 key4, and encrypted with key1 166 When five keys are available: 168 . data sent from the server is encrypted with key1, decrypted with 169 key2, and encrypted with key3; 171 . data sent from the client is encrypted with key2, decrypted with 172 key4, and encrypted with key5 174 When six keys are available: 176 . data sent from the server is encrypted with key1, decrypted with 177 key2, and encrypted with key3; 179 . data sent from the client is encrypted with key4, decrypted with 180 key5, and encrypted with key6 182 In all cases, the keys used by DES3_CFB64 must have their parity 183 corrected after they are determined using the above algorithm. 185 Note that the above algorithm assumes that it is safe to use a non- 186 DES key (or part of a non-DES key) as a DES key. This is not neces- 187 sarily true of all cipher systems, but we specify this behaviour as 188 the default since it is true for most authentication systems in popu- 189 lar use today, and for compatibility with existing implementations. 190 New telnet AUTHENTICATION mechanisms may specify althernative methods 191 for determining the keys to be used for this cipher suite in their 192 specification, if the session key negotiated by that authentication 193 mechanism is not a DES key and and where this algorithm may not be 194 safely used. 196 6. Security considerations 198 Encryption using Cipher Feedback does not ensure data integrity; the 199 active attacker has a limited ability to modify text, if he can 200 predict the clear-text that was being transmitted. The limitations 201 faced by the attacker (that only 8 bytes can be modified at a time, 202 and the following 8-byte block of data will be corrupted, thus making 203 detection likely) are significant, but it is possible that an active 204 attacker still might be able to exploit this weakness. 206 The tradeoff here is that adding a message authentication code (MAC) 207 will significantly increase the number of bytes needed to send a sin- 208 gle character in the telnet protocol, which will impact performance 209 on slow (i.e. dialup) links. 211 7. Acknowledgments 213 This document was based on the "Telnet Encryption: DES 64 bit Cipher 214 Feedback" draft originally written by Dave Borman of Cray Research 215 with the assistance of the IETF Telnet Working Group. 217 Author's Address 219 Jeffrey Altman, Editor 220 Columbia University 221 612 West 115th Street Room 716 222 New York NY 10025 USA 224 Phone: +1 (212) 854-1344 226 EMail: jaltman@columbia.edu 228 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 229 The Kermit Project * Columbia University 230 612 West 115th St #716 * New York, NY * 10025 231 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org