RFC 2952

1. Command Names and Codes ✨

okay so first, the lineup 💅 Encryption type gets one code, and the suboption commands are the three IV vibes:

Encryption Type

   DES_CFB64        1

Suboption Commands

   CFB64_IV         1
   CFB64_IV_OK      2
   CFB64_IV_BAD     3

2. Command Meanings 🎀

Here's how each command hits the wire 🫶

IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

The sender makes a random 8 byte initial vector and ships it over with CFB64_IV. The IV goes out in clear text 🙈 and only the side that is WILL ENCRYPT is allowed to send CFB64_IV. Bestie, that's the rule.

IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK IAC SE
IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE

Now the reply side. The sender says yes or no to the IV it got in CFB64_IV. Only the side that is DO ENCRYPT can send CFB64_IV_OK and CFB64_IV_BAD. CFB64_IV_OK MUST be sent for backwards compatibility with existing implementations 😭 CFB64_IV_BAD basically has no reason to show up, except when someone breaks the protocol and the IV wasn't the right length (8 bytes). ngl that's the only real case 💀

3. Implementation Rules 🌸

Once a CFB64_IV_OK has been received, the WILL ENCRYPT side should run keyid negotiation with the ENC_KEYID command. After the keyid negotiation finds a common keyid, the WILL ENCRYPT side is the one that can send START and END commands. And then the data gets encrypted with DES 64 bit Cipher Feedback. Iconic ✨

If encryption (decryption) gets turned off and then back on, and the same keyid is used to restart it, the clear text in between must not change the state of the encryption (decryption) machine. Main character energy: the machine just keeps going 🧚

If a START command is sent (received) with a different keyid, the encryption (decryption) machine must be re-initialized right after the END of the START command, using the new key and the initial vector 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 the CFB64_IV command, with 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. It uses the keyid from that START command and the initial vector from this CFB64_IV command 🦋

4. Algorithm 🧮

Okay, the math, but make it cute 🍓 V[i] is the starting 64 bit vector, V[n] is the nth 64 bit vector, D[n] is the nth 64 bit chunk of data to encrypt (decrypt), and O[n] is the nth 64 bit chunk of encrypted (decrypted) data. Then:

   V[0] = DES(V[i], key)
   O[n] = D[n] <exclusive or> V[n]
   V[n+1] = DES(O[n], key)

5. Integration with the AUTHENTICATION telnet option 🔐

So the ENCRYPTION option specs say a keyid value of zero means the default encryption key. That key might come from the telnet AUTHENTICATION option, and this part is where things get spicy 🌶️

If the default key that comes out of AUTHENTICATION is less than 8 bytes, then DES_CFB64 must not be offered or used as a valid telnet encryption option. Not okay, not allowed.

If the key from AUTHENTICATION is more than 16 bytes, the first 8 bytes should be used as keyid 0 for data going from the telnet client to the telnet server. The second 8 bytes should be used as keyid 0 for data going from the server to the client.

Otherwise, the first 8 bytes of the key become keyid zero for the ENCRYPTION option in both directions, with the client as WILL ENCRYPT and the server as WILL ENCRYPT 💜

In every case, if the AUTHENTICATION key wasn't a DES key, the key DES_CFB64 uses has to have its parity corrected after you figure it out with the algorithm above 🫠

Real talk: this algorithm assumes it's safe to use a non-DES key (or part of one) as a DES key. That's not necessarily true for every cipher system. We're making it the default anyway, because it works for most authentication systems people use today and because existing implementations already do it. New telnet AUTHENTICATION mechanisms can specify other ways to pick the keys for this cipher suite, if the session key from that mechanism isn't a DES key and this algorithm might not be safe to use 🔥

6. Security Considerations 🚨

Cipher Feedback encryption does not ensure data integrity. An active attacker has a limited ability to modify text, if he can predict the clear-text that was being transmitted. The limits on the attacker (only 8 bytes can be modified at a time, and the following 8-byte block of data will be corrupted, which makes detection likely) are significant, but an active attacker might still be able to exploit this weakness. 😱

The tradeoff: adding a message authentication code (MAC) would greatly increase the number of bytes needed to send a single character in the telnet protocol. That hurts performance on slow (i.e. dialup) links 📞💀

7. Acknowledgments 🙏

This document was originally written by Dave Borman of Cray Research, with help from the IETF Telnet Working Group 🫶

---

Abstract 📝

This document explains how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option ✨

Status of This Memo 📌

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice ©️

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

Author's Address 💌

   Theodore Ts'o, Editor
   VA Linux Systems
   43 Pleasant St.
   Medford, MA 02155

   Phone: (781) 391-3464
   EMail: tytso@mit.edu

Full Copyright Statement ⚖️

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is 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.