RFC 2950

RFC 2950: Telnet Encryption: CAST-128 64 bit Cipher Feedback 🎀

• Network Working Group 🌸
• Author: J. Altman, Columbia University 💅
• Category: Standards Track ⭐
• Date: September 2000 🦋
• Obsoletes: none listed
• Updates: none listed

---

Status of This Memo 🫶

okay so this doc is an Internet standards track protocol for the whole Internet community, and the authors are literally begging for your discussion and suggestions for improvements 🙏. for the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨. and distribution of this memo is unlimited, so share it with everyone 💖.

Copyright Notice 💜

Copyright (C) The Internet Society (2000). All Rights Reserved. 🌈

Abstract 🦋

this doc explains how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option 🔐. two key sizes are defined: 40 bit and 128 bit 🍓.

1. Command Names and Codes ✨

Encryption Type

   CAST5_40_CFB64   8
   CAST128_CFB64   10

Suboption Commands

   CFB64_IV         1
   CFB64_IV_OK      2
   CFB64_IV_BAD     3

2. Command Meanings 💅

these are the command lines, and yes they're giving very specific 🙈:

IAC SB ENCRYPT IS CAST5_40_CFB64 CFB64_IV <initial vector> IAC SE
IAC SB ENCRYPT IS CAST128_CFB64 CFB64_IV <initial vector> IAC SE

the sender of this command makes a random 8 byte initial vector and sends it to the other side with the CFB64_IV command 🎲. the initial vector goes over in clear text, no hiding it lol 🙃. only the side that is WILL ENCRYPT is allowed to send CFB64_IV 🚫.

IAC SB ENCRYPT REPLY CAST5_40_CFB64 CFB64_IV_OK IAC SE
IAC SB ENCRYPT REPLY CAST128_CFB64 CFB64_IV_OK IAC SE
IAC SB ENCRYPT REPLY CAST5_40_CFB64 CFB64_IV_BAD IAC SE
IAC SB ENCRYPT REPLY CAST128_CFB64 CFB64_IV_BAD IAC SE

the sender of these replies either accepts or rejects the initial vector it got in a CFB64_IV command ✅❌. only the side that is DO ENCRYPT can send CFB64_IV_OK and CFB64_IV_BAD 💌. CFB64_IV_OK MUST be sent, because it's there for backwards compatibility with existing implementations 🫶. honestly there's no real reason to send CFB64_IV_BAD unless there's a protocol violation, like the IV wasn't the right length (aka 8 bytes) 😭.

3. Implementation Rules 🔥

once CFB64_IV_OK has been received, the WILL ENCRYPT side should do keyid negotiation with the ENC_KEYID command 🗝️. after keyid negotiation successfully finds a common keyid, the WILL ENCRYPT side can send START and END commands 🚀. the data then gets encrypted with the CAST128 64 bit Cipher Feedback algorithm 🔐✨.

if encryption (decryption) gets turned off and then back on, and the same keyid is used when restarting, the clear text in between must not change the state of the encryption (decryption) machine 🧠.

if a START command is sent (received) with a different keyid, the encryption (decryption) machine must be re-initialized right after the END of that START command, using the new key and the initial vector that was sent (received) in the last CFB64_IV command 🔄.

if a new CFB64_IV command is sent (received) and encryption (decryption) is enabled, the machine must be re-initialized right after the end of that CFB64_IV command, using the new initial vector and the keyid sent (received) in the last START command 🌈.

if encryption (decryption) is not enabled when a CFB64_IV command is sent (received), the machine must be re-initialized after the next START command, using the keyid sent (received) in that START command and the initial vector sent (received) in this CFB64_IV command 🎀.

4. Algorithm 🧚

this is the CAST 64 bit Cipher Feedback diagram, and it's a whole vibe 🦋:

   CAST 64 bit Cipher Feedback

       key --->+------+
            +->| CAST |--+
            |  +------+  |
            |            v
    INPUT --(---------->(+)+---> DATA
            |              |
        +--------------+

here's what everything means 🧮:

• iV is the initial vector, 64 bits (8 bytes) long 🎲.
• Dn is the nth chunk of 64 bits (8 bytes) of data to encrypt (decrypt) 📦.
• On is the nth chunk of 64 bits (8 bytes) of encrypted (decrypted) output 🔓.

and the math is:

   V0 = CAST(iV, key)
   On = Dn ^ Vn
   V(n+1) = CAST(On, key)

5. Integration with the AUTHENTICATION telnet option 🔑

okay so the telnet ENCRYPTION option specs say a keyid value of zero means the default encryption key, the kind you might derive from the telnet AUTHENTICATION option 🗝️. if that default key from AUTHENTICATION has less than 16 (5) bytes, then CAST128_CFB64 (CAST5_40_CFB64) must not be offered or used as a valid telnet encryption option 🚫.

if there are less than 32 (10) bytes of key data, the first 16 (5) bytes are used as keyid 0 in each direction 🔁. if there are at least 32 (10) bytes, the first 16 (5) bytes encrypt the data the telnet client sends to the telnet server, and the second 16 (5) bytes encrypt the data the telnet server sends to the client 💫.

any extra key data gets used as random data to be sent as an initialization vector 🎲✨.

6. Security Considerations 💀

the main thing to know: Cipher Feedback does NOT ensure data integrity 😭. an active attacker can modify text to some extent, but only if they can predict the clear text being transmitted 👀.

the limits on the attacker are pretty strong: only 8 bytes can be modified at a time, and the following 8-byte block of data gets corrupted, which makes detection likely 🚨. still, the doc says an active attacker might be able to exploit this weakness anyway, so don't get too comfy 🙈.

the tradeoff is that adding a message authentication code (MAC) would really increase how many bytes it takes to send one single character over telnet 🐢. that hurts performance on slow links, like dialup 📞.

encryption modes using 40-bit keys are NOT to be considered secure 🚫🔓. CAST5_40_CFB64 is only listed here to document the implementations already out in the wild that have never been written down 💔.

7. Acknowledgments 🫶

this doc was based on the "Telnet Encryption: DES 64 bit Cipher Feedback" document, originally written by Dave Borman of Cray Research, with help from the IETF Telnet Working Group 👑.

8. References 📚

   [1] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May
       1997.

Author's Address 📮

   Jeffrey Altman, Editor
   Columbia University
   612 West 115th Street Room 716
   New York NY 10025 USA

   Phone: +1 (212) 854-1344
   EMail: jaltman@columbia.edu

---

Full Copyright Statement 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved.

this document and translations of it can be copied and handed out to others 💕. derivative works that comment on or explain it, or help with implementing it, can be written, copied, published, and distributed, in whole or in part, with no restrictions at all 🎉, as long as the copyright notice and this paragraph are included on every copy and derivative 📋. however, the document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅. the exceptions are when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures have to be followed, or when it's translated into a language other than English 🌍.

the permissions above are perpetual and the Internet Society (or its successors or assigns) won't revoke them 💜.

this document and the info in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙏.

Acknowledgement 💖

funding for the RFC Editor function is currently provided by the Internet Society ✨.