idnits 2.17.1 draft-tso-telnet-enc-des-cfb-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Abstract section. ** 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 (November 1998) is 9292 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 96 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ts'o, Editor 3 Internet-Draft Massachusetts Institute of Technology 4 draft-tso-telnet-enc-des-cfb-01.txt November 1998 6 Telnet Encryption: DES 64 bit Cipher Feedback 8 Status of this Memo 10 This document is an Internet-Draft. 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 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Command Names and Codes 28 Encryption Type 30 DES_CFB64 1 32 Suboption Commands 34 CFB64_IV 1 35 CFB64_IV_OK 2 36 CFB64_IV_BAD 3 37 CFB64_CHALLENGE 4 38 CFB64_RESPONSE 5 40 2. Command Meanings 42 IAC SB ENCRYPT IS DES_CFB64 CFB64_IV IAC SE 44 The sender of this command generates a random 8 byte initial vec- 45 tor, and sends it to the other side of the connection using the 46 CFB64_IV command. The initial vector is sent in clear text. Only 47 the side of the connection that is WILL ENCRYPT may send the 48 CFB64_IV command. 50 IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK IAC SE 51 IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE 53 The sender of these commands either accepts or rejects the initial 54 vector received in a CFB64_IV command. Only the side of the con- 55 nection that is DO ENCRYPT may send the CFB64_IV_OK and 56 CFB64_IV_BAD commands. 58 3. Implementation Rules 60 Once a CFB64_IV_OK command has been received, the WILL ENCRYPT side 61 of the connection should do keyid negotiation using the ENC_KEYID 62 command. Once the keyid negotiation has successfully identified a 63 common keyid, then START and END commands may be sent by the side of 64 the connection that is WILL ENCRYPT. Data will be encrypted using 65 the DES 64 bit Cipher Feedback algorithm. 67 If encryption (decryption) is turned off and back on again, and the 68 same keyid is used when re-starting the encryption (decryption), the 69 intervening clear text must not change the state of the encryption 70 (decryption) machine. 72 If a START command is sent (received) with a different keyid, the en- 73 cryption (decryption) machine must be re-initialized immediately fol- 74 lowing the end of the START command with the new key and the initial 75 vector sent (received) in the last CFB64_IV command. 77 If a new CFB64_IV command is sent (received), and encryption (decryp- 78 tion) is enabled, the encryption (decryption) machine must be re- 79 initialized immediately following the end of the CFB64_IV command 80 with the new initial vector, and the keyid sent (received) in the 81 last START command. 83 If encryption (decryption) is not enabled when a CFB64_IV command is 84 sent (received), the encryption (decryption) machine must be re- 85 initialized after the next START command, with the keyid sent (re- 86 ceived) in that START command, and the initial vector sent (received) 87 in this CFB64_IV command. 89 4. Algorithm 91 Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit 92 vector, D[n] is the nth chunk of 64 bits of data to encrypt (de- 93 crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) 94 data, then: 96 V[0] = DES(V[i], key) 97 O[n] = D[n] V[n] 98 V[n+1] = DES(O[n], key) 100 5. Security considerations 102 Encryption using Cipher Feedback does not ensure data integrity; the 103 active attacker has a limited ability to modify text, if he can 104 predict the clear-text that was being transmitted. The limitations 105 faced by the attacker (that only 8 bytes can be modified at a time, 106 and the following 8-byte block of data will be corrupted, thus making 107 detection likely) are significant, but it is possible that an active 108 attacker still might be able to exploit this weakness. 110 The tradeoff here is that adding a message authentication code (MAC) 111 will significantly increase the number of bytes needed to send a sin- 112 gle character in the telnet protocol, which will impact performance 113 on slow (i.e. dialup) links. 115 6. Acknowledgments 117 This document was originally written by Dave Borman of Cray Research 118 with the assistance of the IETF Telnet Working Group. 120 Author's Address 122 Theodore Ts'o, Editor 123 Massachusetts Institute of Technology 124 MIT Room E40-343 125 77 Massachusetts Ave. 126 Cambridge, MA 02139 128 Phone: (617) 253-8091 130 EMail: tytso@mit.edu