idnits 2.17.1 draft-tso-telnet-enc-des-ofb-04.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 4 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: ---------------------------------------------------------------------------- == Line 147 has weird spacing: '...on type shoul...' -- 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 (September 1999) is 8983 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 107 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 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-ofb-04.txt September 1999 5 Telnet Encryption: DES 64 bit Output 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 0. Abstract 32 This document specifies how to use the DES encryption algorithm in 33 output feedback mode with the telnet encryption option. 35 1. Command Names and Codes 37 Encryption Type 39 DES_OFB64 2 41 Suboption Commands 43 OFB64_IV 1 44 OFB64_IV_OK 2 45 OFB64_IV_BAD 3 47 2. Command Meanings 49 IAC SB ENCRYPT IS DES_OFB64 OFB64_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 OFB64_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 OFB64_IV command 57 IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_OK IAC SE 58 IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_BAD IAC SE 60 The sender of these commands either accepts or rejects the initial 61 vector received in a OFB64_IV command. Only the side of the con- 62 nection that is DO ENCRYPT may send the OFB64_IV_OK and 63 OFB64_IV_BAD commands. The OFB64_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 OFB64_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 OFB64_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 DES 64 bit Output 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 OFB64_IV command. 88 If a new OFB64_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 OFB64_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 OFB64_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 OFB64_IV command. 100 4. Algorithm 102 Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit 103 vector, D[n] is the nth chunk of 64 bits of data to encrypt (de- 104 crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) 105 data, then: 107 V[0] = DES(V[i], key) 108 V[n+1] = DES(V[n], key) 109 O[n] = D[n] V[n] 111 5. Integration with the AUTHENTICATION telnet option 113 As noted in the telnet ENCRYPTION option specifications, a keyid val- 114 ue of zero indicates the default encryption key, as might be derived 115 from the telnet AUTHENTICATION option. If the default encryption key 116 negotiated as a result of the telnet AUTHENTICATION option contains 117 less than 8 bytes, then the DES_OFB64 option may not be offered or 118 used as a valid telnet encryption option. If the encryption key ne- 119 gotiated as a result of the telnet AUTHENTICATION option is greater 120 than 16 bytes the first 8 bytes of the key should be used as keyid 0 121 for data sent from the telnet server to the telnet client, and the 122 second 8 bytes of the key should be used as keyid 0 for data sent by 123 the telnet client to the telnet server. Otherwise, the first 8 bytes 124 of the encryption key is used as keyid zero for the telnet ENCRYPTION 125 option in both directions (with the client as WILL ENCRYPT and the 126 server as WILL ENCRYPT). 128 In all cases, if the key negotiated by the telnet AUTHENTICATION op- 129 tion was not a DES key, the key used by the DES_CFB64 must have its 130 parity corrected after it is detrmined using the above algorithm. 132 Note that the above algorithm assumes that it is safe to use a non- 133 DES key (or part of a non-DES key) as a DES key. This is not neces- 134 sarily true of all cipher systems, but we specify this behaviour as 135 the default since it is true for most authentication systems in popu- 136 lar use today, and for compatibility with existing implementations. 137 New telnet AUTHENTICATION mechanisms may specify althernative methods 138 for determining the keys to be used for this cipher suite in their 139 specification, if the session key negotiated by that authentication 140 mechanism is not a DES key and and where this algorithm may not be 141 safely used. 143 6. Security considerations 144 Encryption using Output Feedback does not ensure data integrity; an 145 active attacker may be able to substitute text, if he can predict the 146 clear-text that was being transmitted. For this reason, the Cipher 147 Feedback encryption type should be used instead, since it provides 148 limited detectability to data modification. Neither provides true 149 data integrity, however. 151 The tradeoff here is that adding a message authentication code (MAC) 152 will significantly increase the number of bytes needed to send a sin- 153 gle character in the telnet protocol, which will impact performance 154 on slow (i.e. dialup) links. 156 7. Acknowledgments 158 This document was originally written by Dave Borman of Cray Research 159 with the assistance of the IETF Telnet Working Group. 161 Author's Address 163 Theodore Ts'o, Editor 164 VA Linux Systems 165 43 Pleasant St. 166 Medford, MA 02155 168 Phone: (781) 391-3464 170 EMail: tytso@valinux.com