idnits 2.17.1 draft-tso-telnet-enc-des-cfb-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 == 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.) 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 (July 1999) is 9053 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 section? '0' on line 100 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ts'o, Editor 2 Internet-Draft VA Linux Systems 3 draft-tso-telnet-enc-des-cfb-02.txt July 1999 5 Telnet Encryption: DES 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 0. Abstract 28 This document specifies how to use the DES encryption algorithm in 29 cipher feedback mode with the telnet encryption option. 31 1. Command Names and Codes 33 Encryption Type 35 DES_CFB64 1 37 Suboption Commands 39 CFB64_IV 1 40 CFB64_IV_OK 2 41 CFB64_IV_BAD 3 42 CFB64_CHALLENGE 4 43 CFB64_RESPONSE 5 45 2. Command Meanings 47 IAC SB ENCRYPT IS DES_CFB64 CFB64_IV IAC SE 49 The sender of this command generates a random 8 byte initial vec- 50 tor, and sends it to the other side of the connection using the 51 CFB64_IV command. The initial vector is sent in clear text. Only 52 the side of the connection that is WILL ENCRYPT may send the 53 CFB64_IV command. 55 IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK IAC SE 56 IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE 58 The sender of these commands either accepts or rejects the initial 59 vector received in a CFB64_IV command. Only the side of the con- 60 nection that is DO ENCRYPT may send the CFB64_IV_OK and 61 CFB64_IV_BAD commands. 63 3. Implementation Rules 65 Once a CFB64_IV_OK command has been received, the WILL ENCRYPT side 66 of the connection should do keyid negotiation using the ENC_KEYID 67 command. Once the keyid negotiation has successfully identified a 68 common keyid, then START and END commands may be sent by the side of 69 the connection that is WILL ENCRYPT. Data will be encrypted using 70 the DES 64 bit Cipher Feedback algorithm. 72 If encryption (decryption) is turned off and back on again, and the 73 same keyid is used when re-starting the encryption (decryption), the 74 intervening clear text must not change the state of the encryption 75 (decryption) machine. 77 If a START command is sent (received) with a different keyid, the en- 78 cryption (decryption) machine must be re-initialized immediately fol- 79 lowing the end of the START command with the new key and the initial 80 vector sent (received) in the last CFB64_IV command. 82 If a new CFB64_IV command is sent (received), and encryption (decryp- 83 tion) is enabled, the encryption (decryption) machine must be re-ini- 84 tialized immediately following the end of the CFB64_IV command with 85 the new initial vector, and the keyid sent (received) in the last 86 START command. 88 If encryption (decryption) is not enabled when a CFB64_IV command is 89 sent (received), the encryption (decryption) machine must be re-ini- 90 tialized after the next START command, with the keyid sent (received) 91 in that START command, and the initial vector sent (received) in this 92 CFB64_IV command. 94 4. Algorithm 95 Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit 96 vector, D[n] is the nth chunk of 64 bits of data to encrypt (de- 97 crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) 98 data, then: 100 V[0] = DES(V[i], key) 101 O[n] = D[n] V[n] 102 V[n+1] = DES(O[n], key) 104 5. Security considerations 106 Encryption using Cipher Feedback does not ensure data integrity; the 107 active attacker has a limited ability to modify text, if he can pre- 108 dict the clear-text that was being transmitted. The limitations 109 faced by the attacker (that only 8 bytes can be modified at a time, 110 and the following 8-byte block of data will be corrupted, thus making 111 detection likely) are significant, but it is possible that an active 112 attacker still might be able to exploit this weakness. 114 The tradeoff here is that adding a message authentication code (MAC) 115 will significantly increase the number of bytes needed to send a sin- 116 gle character in the telnet protocol, which will impact performance 117 on slow (i.e. dialup) links. 119 6. Acknowledgments 121 This document was originally written by Dave Borman of Cray Research 122 with the assistance of the IETF Telnet Working Group. 124 Author's Address 126 Theodore Ts'o, Editor 127 VA Linux Systems 128 43 Pleasant St. 129 Medford, MA 02155 131 Phone: (781) 391-3464 133 EMail: tytso@valinux.com