idnits 2.17.1 draft-tso-telnet-enc-des-cfb-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-26) 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 a Security Considerations 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 9567 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 95 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 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 Massachusetts Institute of Technology 3 draft-tso-telnet-enc-des-cfb-00.txt February 1998 5 Telnet Encryption: DES 64 bit Cipher Feedback 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as "work in progress." 19 To view the entire list of current Internet-Drafts, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 1. Command Names and Codes 27 Encryption Type 29 DES_CFB64 1 31 Suboption Commands 33 CFB64_IV 1 34 CFB64_IV_OK 2 35 CFB64_IV_BAD 3 36 CFB64_CHALLENGE 4 37 CFB64_RESPONSE 5 39 2. Command Meanings 41 IAC SB ENCRYPT IS DES_CFB64 CFB64_IV IAC SE 43 The sender of this command generates a random 8 byte initial vec- 44 tor, and sends it to the other side of the connection using the 45 CFB64_IV command. The initial vector is sent in clear text. Only 46 the side of the connection that is WILL ENCRYPT may send the 47 CFB64_IV command. 49 IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK IAC SE 50 IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE 52 The sender of these commands either accepts or rejects the initial 53 vector received in a CFB64_IV command. Only the side of the con- 54 nection that is DO ENCRYPT may send the CFB64_IV_OK and 55 CFB64_IV_BAD commands. 57 3. Implementation Rules 59 Once a CFB64_IV_OK command has been received, the WILL ENCRYPT side 60 of the connection should do keyid negotiation using the ENC_KEYID 61 command. Once the keyid negotiation has successfully identified a 62 common keyid, then START and END commands may be sent by the side of 63 the connection that is WILL ENCRYPT. Data will be encrypted using 64 the DES 64 bit Cipher Feedback algorithm. 66 If encryption (decryption) is turned off and back on again, and the 67 same keyid is used when re-starting the encryption (decryption), the 68 intervening clear text must not change the state of the encryption 69 (decryption) machine. 71 If a START command is sent (received) with a different keyid, the en- 72 cryption (decryption) machine must be re-initialized immediately fol- 73 lowing the end of the START command with the new key and the initial 74 vector sent (received) in the last CFB64_IV command. 76 If a new CFB64_IV command is sent (received), and encryption (decryp- 77 tion) is enabled, the encryption (decryption) machine must be re- 78 initialized immediately following the end of the CFB64_IV command 79 with the new initial vector, and the keyid sent (received) in the 80 last START command. 82 If encryption (decryption) is not enabled when a CFB64_IV command is 83 sent (received), the encryption (decryption) machine must be re- 84 initialized after the next START command, with the keyid sent (re- 85 ceived) in that START command, and the initial vector sent (received) 86 in this CFB64_IV command. 88 4. Algorithm 90 Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit 91 vector, D[n] is the nth chunk of 64 bits of data to encrypt (de- 92 crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) 93 data, then: 95 V[0] = DES(V[i], key) 96 O[n] = D[n] V[n] 97 V[n+1] = DES(O[n], key) 99 Author's Address 101 Theodore Ts'o, Editor 102 Massachusetts Institute of Technology 103 MIT Room E40-343 104 77 Massachusetts Ave. 105 Cambridge, MA 02139 107 Phone: (617) 253-8091 109 EMail: tytso@mit.edu