idnits 2.17.1 draft-altman-telnet-enc-cast128-cfb-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 9199 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 173, 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-cfb-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_CFB64 8 41 CAST128_CFB64 10 43 Suboption Commands 45 CFB64_IV 1 46 CFB64_IV_OK 2 47 CFB64_IV_BAD 3 49 2. Command Meanings 51 IAC SB ENCRYPT IS CAST5_40_CFB64 CFB64_IV IAC SE 52 IAC SB ENCRYPT IS CAST128_CFB64 CFB64_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 CFB64_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 CFB64_IV command. 60 IAC SB ENCRYPT REPLY CAST5_40_CFB64 CFB64_IV_OK IAC SE 61 IAC SB ENCRYPT REPLY CAST128_CFB64 CFB64_IV_OK IAC SE 62 IAC SB ENCRYPT REPLY CAST5_40_CFB64 CFB64_IV_BAD IAC SE 63 IAC SB ENCRYPT REPLY CAST128_CFB64 CFB64_IV_BAD IAC SE 65 The sender of these commands either accepts or rejects the initial 66 vector received in a CFB64_IV command. Only the side of the con- 67 nection that is DO ENCRYPT may send the CFB64_IV_OK and 68 CFB64_IV_BAD commands. The CFB64_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 CFB64_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 CFB64_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 CFB64_IV command. 93 If a new CFB64_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 CFB64_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 CFB64_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 CFB64_IV command. 105 4. Algorithm 107 CAST 64 bit Cipher Feedback 109 key --->+------+ 110 +->| CAST |--+ 111 | +------+ | 112 | v 113 INPUT --(---------->(+)+---> DATA 114 | | 115 +--------------+ 117 Given: 118 iV: Initial vector, 64 bits (8 bytes) long. 119 Dn: the nth chunk of 64 bits (8 bytes) of data to encrypt (decrypt). 120 On: the nth chunk of 64 bits (8 bytes) of encrypted (decrypted) output. 122 V0 = CAST(iV, key) 123 On = Dn ^ Vn 124 V(n+1) = CAST(On, key) 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_CFB64 (CAST5_40_CFB64) 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 Cipher Feedback does not ensure data integrity; the 148 active attacker has a limited ability to modify text, if he can 149 predict the clear-text that was being transmitted. The limitations 150 faced by the attacker (that only 8 bytes can be modified at a time, 151 and the following 8-byte block of data will be corrupted, thus making 152 detection likely) are significant, but it is possible that an active 153 attacker still might be able to exploit this weakness. 155 The tradeoff here is that adding a message authentication code (MAC) 156 will significantly increase the number of bytes needed to send a sin- 157 gle character in the telnet protocol, which will impact performance 158 on slow (i.e. dialup) links. 160 Encryption modes using 40-bit keys are not to be considered secure. 161 The 40 bit key mode CAST5_40_CFB64 is listed here simply to document 162 the implementations that are already prevalent on the Internet but 163 have never been documented. 165 7. Acknowledgments 167 This document was based on the "Telnet Encryption: DES 64 bit Cipher 168 Feedback" draft originally written by Dave Borman of Cray Research 169 with the assistance of the IETF Telnet Working Group. 171 8. References 173 [1] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 174 1997. 176 Author's Address 178 Jeffrey Altman, ditor 179 Columbia Univrsity 180 612 West 115th Street Room 716 181 New York NY 10025 USA 183 Phone: +1 (212) 854-1344 185 EMail: jaltman@columbia.edu 187 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 188 The Kermit Project * Columbia University 189 612 West 115th St #716 * New York, NY * 10025 190 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org