idnits 2.17.1 draft-tso-telnet-enc-des-ofb-00.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-25) 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 (February 1998) is 9566 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 94 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. -------------------------------------------------------------------------------- 1 Internet-Draft Massachusetts Institute of Technology 2 draft-tso-telnet-enc-des-ofb-00.txt February 1998 4 Telnet Encryption: DES 64 bit Output Feedback 6 Status of this Memo 8 This document is an Internet-Draft. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six months 14 and may be updated, replaced, or obsoleted by other documents at any 15 time. It is inappropriate to use Internet- Drafts as reference 16 material or to cite them other than as "work in progress." 18 To view the entire list of current Internet-Drafts, please check the 19 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 20 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 21 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 22 ftp.isi.edu (US West Coast). 24 1. Command Names and Codes 26 Encryption Type 28 DES_OFB64 2 30 Suboption Commands 32 OFB64_IV 1 33 OFB64_IV_OK 2 34 OFB64_IV_BAD 3 35 OFB64_CHALLENGE 4 36 OFB64_RESPONSE 5 38 2. Command Meanings 40 IAC SB ENCRYPT IS DES_OFB64 OFB64_IV IAC SE 42 The sender of this command generates a random 8 byte initial vec- 43 tor, and sends it to the other side of the connection using the 44 OFB64_IV command. The initial vector is sent in clear text. Only 45 the side of the connection that is WILL ENCRYPT may send the 46 OFB64_IV command 48 IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_OK IAC SE 49 IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_BAD IAC SE 51 The sender of these commands either accepts or rejects the initial 52 vector received in a OFB64_IV command. Only the side of the con- 53 nection that is DO ENCRYPT may send the OFB64_IV_OK and 54 OFB64_IV_BAD commands. 56 3. Implementation Rules 58 Once a OFB64_IV_OK command has been received, the WILL ENCRYPT side 59 of the connection should do keyid negotiation using the ENC_KEYID 60 command. Once the keyid negotiation has successfully identified a 61 common keyid, then START and END commands may be sent by the side of 62 the connection that is WILL ENCRYPT. Data will be encrypted using 63 the DES 64 bit Output Feedback algorithm. 65 If encryption (decryption) is turned off and back on again, and the 66 same keyid is used when re-starting the encryption (decryption), the 67 intervening clear text must not change the state of the encryption 68 (decryption) machine. 70 If a START command is sent (received) with a different keyid, the en- 71 cryption (decryption) machine must be re-initialized immediately fol- 72 lowing the end of the START command with the new key and the initial 73 vector sent (received) in the last OFB64_IV command. 75 If a new OFB64_IV command is sent (received), and encryption (decryp- 76 tion) is enabled, the encryption (decryption) machine must be re- 77 initialized immediately following the end of the OFB64_IV command 78 with the new initial vector, and the keyid sent (received) in the 79 last START command. 81 If encryption (decryption) is not enabled when a OFB64_IV command is 82 sent (received), the encryption (decryption) machine must be re- 83 initialized after the next START command, with the keyid sent (re- 84 ceived) in that START command, and the initial vector sent (received) 85 in this OFB64_IV command. 87 4. Algorithm 89 Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit 90 vector, D[n] is the nth chunk of 64 bits of data to encrypt (de- 91 crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) 92 data, then: 94 V[0] = DES(V[i], key) 95 V[n+1] = DES(V[n], key) 96 O[n] = D[n] V[n] 98 5. Security considerations 100 Encryption using Output Feedback does not ensure data integrity; an 101 active attacker may be able to substitute text, if he can predict the 102 clear-text that was being transmitted. 104 This option was originally drafted back when CPU speeds where not 105 necessarily fast enough to do allow use of CFB. Since then, CPU's 106 have gotten much faster. Given the inherent weaknesses in Output 107 Feedback mode, perhaps it should be deprecated in favor of CFB modes? 109 6. Acknowledgements 111 This document was originally written by Dave Borman of Cray Research 112 with the assistance of the IETF Telnet Working Group. 113 Author's Address 115 Theodore Ts'o, Editor 116 Massachusetts Institute of Technology 117 MIT Room E40-343 118 77 Massachusetts Ave. 119 Cambridge, MA 02139 121 Phone: (617) 253-8091 123 EMail: tytso@mit.edu