idnits 2.17.1 draft-altman-telnet-enc-cast128-ofb-00.txt: 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: ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 192 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 1999) is 9203 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) == Unused Reference: '1' is defined on line 174, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. '1') Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jeffrey Altman 2 Internet-Draft Columbia University 3 draft-altman-telnet-enc-cast128-ofb-00.txt February 1999 5 Telnet Encryption: CAST-128 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 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 Abstract 32 This document specifies how to use the CAST-128 encryption algorithm 33 in cipher feedback mode with the telnet encryption option. Two key 34 sizes are defined: 40 bit and 128 bit. 36 1. Command Names and Codes 38 Encryption Type 40 CAST5_40_OFB64 9 41 CAST128_OFB64 11 43 Suboption Commands 45 OFB64_IV 1 46 OFB64_IV_OK 2 47 OFB64_IV_BAD 3 49 2. Command Meanings 51 IAC SB ENCRYPT IS CAST5_40_OFB64 OFB64_IV IAC SE 52 IAC SB ENCRYPT IS CAST128_OFB64 OFB64_IV IAC SE 54 The sender of this command generates a random 8 byte initial vec- 55 tor, and sends it to the other side of the connection using the 56 OFB64_IV command. The initial vector is sent in clear text. Only 57 the side of the connection that is WILL ENCRYPT may send the 58 OFB64_IV command. 60 IAC SB ENCRYPT REPLY CAST5_40_OFB64 OFB64_IV_OK IAC SE 61 IAC SB ENCRYPT REPLY CAST128_OFB64 OFB64_IV_OK IAC SE 62 IAC SB ENCRYPT REPLY CAST5_40_OFB64 OFB64_IV_BAD IAC SE 63 IAC SB ENCRYPT REPLY CAST128_OFB64 OFB64_IV_BAD IAC SE 65 The sender of these commands either accepts or rejects the initial 66 vector received in a OFB64_IV command. Only the side of the con- 67 nection that is DO ENCRYPT may send the OFB64_IV_OK and 68 OFB64_IV_BAD commands. The OFB64_IV_OK command MUST be sent for 69 backwards compatibility with existing implementations; there real- 70 ly isn't any reason why a sender would need to send the 71 OFB64_IV_BAD command except in the case of a protocol violation 72 where the IV sent was not of the correct length (i.e., 8 bytes). 74 3. Implementation Rules 76 Once a OFB64_IV_OK command has been received, the WILL ENCRYPT side 77 of the connection should do keyid negotiation using the ENC_KEYID 78 command. Once the keyid negotiation has successfully identified a 79 common keyid, then START and END commands may be sent by the side of 80 the connection that is WILL ENCRYPT. Data will be encrypted using 81 the CAST128 64 bit Cipher Feedback algorithm. 83 If encryption (decryption) is turned off and back on again, and the 84 same keyid is used when re-starting the encryption (decryption), the 85 intervening clear text must not change the state of the encryption 86 (decryption) machine. 88 If a START command is sent (received) with a different keyid, the en- 89 cryption (decryption) machine must be re-initialized immediately fol- 90 lowing the end of the START command with the new key and the initial 91 vector sent (received) in the last OFB64_IV command. 93 If a new OFB64_IV command is sent (received), and encryption (decryp- 94 tion) is enabled, the encryption (decryption) machine must be re-ini 95 tialized immediately following the end of the OFB64_IV command with 96 the new initial vector, and the keyid sent (received) in the last 97 START command. 99 If encryption (decryption) is not enabled when a OFB64_IV command is 100 sent (received), the encryption (decryption) machine must be re-ini 101 tialized after the next START command, with the keyid sent (received) 102 in that START command, and the initial vector sent (received) in this 103 OFB64_IV command. 105 4. Algorithm 107 CAST 64 bit Output Feedback 109 key --->+------+ 110 +->| CAST |--+ 111 | +------+ | 112 +------------+ 113 v 114 INPUT --------->(+) ----> DATA 116 Given: 117 iV: Initial vector, 64 bits (8 bytes) long. 118 Dn: the nth chunk of 64 bits (8 bytes) of data to encrypt (decrypt). 119 On: the nth chunk of 64 bits (8 bytes) of encrypted (decrypted) 120 output. 122 V0 = CAST(iV, key) 123 V(n+1) = CAST(Vn, key) 124 On = Dn ^ Vn 126 5. Integration with the AUTHENTICATION telnet option 128 As noted in the telnet ENCRYPTION option specifications, a keyid val- 129 ue of zero indicates the default encryption key, as might be derived 130 from the telnet AUTHENTICATION option. If the default encryption key 131 negotiated as a result of the telnet AUTHENTICATION option contains 132 less than 16 (5) bytes, then the CAST128_OFB64 (CAST5_40_OFB64) 133 option must not be offered or used as a valid telnet encryption option. 135 If there are less than 32 (10) bytes of key data, the first 16 (5) 136 bytes of key data are used as keyid 0 in each direction. If there 137 are at least 32 (10) bytes of key data, the first 16 (5) bytes of 138 key data are used to encrypt the data sent by the telnet client to 139 the telnet server; the second 16 (5) bytes of key data are used to 140 encrypt the data sent by the telnet server to the telnet client. 142 Any extra key data is used as random data to be sent as an 143 initialization vector. 145 6. Security considerations 147 Encryption using Output Feedback does not ensure data integrity; an 148 active attacker may be able to substitute text, if he can predict the 149 clear-text that was being transmitted. 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 This option was originally drafted back when CPU speeds where not 157 necessarily fast enough to do allow use of CFB. Since then, CPU's 158 have gotten much faster. Given the inherent weaknesses in Output 159 Feedback mode, perhaps it should be deprecated in favor of CFB modes? 161 Encryption modes using 40-bit keys are not to be considered secure. 162 The 40 bit key mode CAST5_40_OFB64 is listed here simply to document 163 the implementations that are already prevalent on the Internet but 164 have never been documented. 166 7. Acknowledgments 168 This document was based on the "Telnet Encryption: DES 64 bit Cipher 169 Feedback" draft originally written by Dave Borman of Cray Research 170 with the assistance of the IETF Telnet Working Group. 172 8. References 174 [1] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 175 1997. 177 Author's Address 179 Jeffrey Altman, ditor 180 Columbia Univrsity 181 612 West 115th Street Room 716 182 New York NY 10025 USA 184 Phone: +1 (212) 854-1344 186 EMail: jaltman@columbia.edu 188 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 189 The Kermit Project * Columbia University 190 612 West 115th St #716 * New York, NY * 10025 191 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org