RFC 2948

Telnet Encryption: DES3 64 bit Output Feedback

📅 published September 2000, from ietf

RFC 2948: Telnet Encryption: DES3 64 bit Output Feedback 🎀

okay bestie, let's get into this one 💅

  • Number: RFC 2948
  • Author: Jeffrey Altman (J. Altman), Columbia University 🎓
  • Category: Standards Track 🔥
  • Date: September 2000 🍓
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates

Status of this Memo 📜

This is a Standards Track protocol spec for the Internet community, and the authors are literally asking for your thoughts and suggestions 🫶 For where it stands in the official standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). The memo can be distributed without any limits.

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

Abstract ✨

This doc explains how to run Triple-DES (the data encryption standard) in output feedback mode with the telnet encryption option. It's giving cipher glow-up 🦋

1. Command Names and Codes 💜

Here are the names and numbers you'll be working with:

Encryption Type

   DES3_OFB64       4

Suboption Commands

   OFB64_IV         1
   OFB64_IV_OK      2
   OFB64_IV_BAD     3

2. Command Meanings 🧚

Okay so this is where the commands actually do stuff. Here's the first one:

IAC SB ENCRYPT IS DES3_OFB64 OFB64_IV <initial vector> IAC SE

The sender makes a random 8 byte initial vector and ships it to the other side using OFB64_IV. The initial vector goes over in clear text, so it's not hidden 👀 Only the side that is WILL ENCRYPT is allowed to send OFB64_IV.

Now for the replies:

IAC SB ENCRYPT REPLY DES3_OFB64 OFB64_IV_OK IAC SE
IAC SB ENCRYPT REPLY DES3_OFB64 OFB64_IV_BAD IAC SE

The sender uses these to either accept or reject the initial vector it got in OFB64_IV. Only the side that is DO ENCRYPT can send OFB64_IV_OK and OFB64_IV_BAD. Here's the main thing: OFB64_IV_OK MUST be sent for backwards compatibility with existing implementations 🙏 OFB64_IV_BAD honestly has no real reason to show up, except when someone's violating the protocol and the IV wasn't the right length (that's 8 bytes, btw).

3. Implementation Rules 🛠️

Once an OFB64_IV_OK has been received, the WILL ENCRYPT side should start keyid negotiation using the ENC_KEYID command. After that negotiation successfully agrees on a common keyid, the WILL ENCRYPT side can send START and END commands. Data then gets encrypted with the DES3 64 bit Output Feedback algorithm 🔐

Some edge cases, because we love a good edge case:

  • If encryption (decryption) gets turned off and back on again, 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 START command ends. It uses the new key and the initial vector from the last OFB64_IV command.
  • If a new OFB64_IV command is sent (received) and encryption (decryption) is enabled, the machine must be re-initialized right after the OFB64_IV command ends. It uses the new initial vector and the keyid from the last START command.
  • If encryption (decryption) isn't enabled when an OFB64_IV command is sent (received), the machine must be re-initialized after the next START command. It uses the keyid from that START and the initial vector from this OFB64_IV.

4. Algorithm 🧮

This is the DES3 64 bit Output Feedback algorithm. Here's the vibe check:

DES3 64 bit Output Feedback


               key1       key2       key3
                |          |          |
                v          v          v
            +-------+  +-------+  +-------+
         +->| DES-e |->| DES-d |->| DES-e |-- +
         |  +-------+  +-------+  +-------+   |
         +------------------------------------+
                                             v
INPUT ------------------------------------->(+) ----> DATA

Here's what each piece means:

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

And the math, which is giving pure precision:

V0 = DES-e(DES-d(DES-e(iV, key1),key2),key3)
V(n+1) = DES-e(DES-d(DES-e(Vn, key1),key2),key3)
On = Dn ^ Vn

5. Integration with the AUTHENTICATION telnet option 🔑

As the telnet ENCRYPTION option specs already say, a keyid of zero means "use the default encryption key." That default might come from the telnet AUTHENTICATION option. If the default key from AUTHENTICATION has less than 16 bytes, then DES3_OFB64 must not be offered or used as a valid telnet encryption option 🚫

Next, here's how to make three DES keys from whatever key data you've got:

keys_to_use = bytes of key data / DES block size (8 bytes)

The keys are named "key1" through "key6." key1 is the first 8 bytes, key2 is the second 8 bytes, and so on up to key6 (the sixth 8 bytes, if there are that many).

Now the fun part, which depends on how many keys you have:

  • Two keys: data from the server is encrypted with key1, decrypted with key2, then encrypted with key1. Data from the client is encrypted with key2, decrypted with key1, then encrypted with key2.
  • Three keys: data from the server is encrypted with key1, decrypted with key2, then encrypted with key3. Data from the client is encrypted with key2, decrypted with key3, then encrypted with key1.
  • Four keys: data from the server is encrypted with key1, decrypted with key2, then encrypted with key3. Data from the client is encrypted with key2, decrypted with key4, then encrypted with key1.
  • Five keys: data from the server is encrypted with key1, decrypted with key2, then encrypted with key3. Data from the client is encrypted with key2, decrypted with key4, then encrypted with key5.
  • Six keys: data from the server is encrypted with key1, decrypted with key2, then encrypted with key3. Data from the client is encrypted with key4, decrypted with key5, then encrypted with key6.

In every case, the DES3_OFB64 keys need their parity corrected after the algorithm above picks them 🧼

Heads up: this whole approach assumes it's safe to treat a non-DES key (or part of one) as a DES key. That's not true for every cipher system! It's the default here because it holds for most authentication systems people use today, and because it keeps existing implementations working. New telnet AUTHENTICATION mechanisms can define their own way of picking keys for this cipher suite, if their session key isn't a DES key and this method wouldn't be safe.

6. Security Considerations 🚨

Okay, serious moment. Encryption using Output Feedback does not ensure data integrity. An active attacker may be able to substitute text if they can predict the clear text being sent 😱

There's a tradeoff here too. Adding a message authentication code (MAC) would significantly increase the number of bytes needed to send a single character over telnet, which hurts performance on slow links (like dialup) 🐌

This option was first drafted back when CPUs weren't necessarily fast enough to allow CFB mode. CPUs have gotten way faster since then. Given the inherent weaknesses of Output Feedback mode, maybe it should be deprecated in favor of the CFB modes? 🤔

7. Acknowledgments 🫶

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

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

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 made, copied, published, and distributed, in whole or in part, with no restrictions at all. The one condition is that the above copyright notice and this paragraph must be included on all copies and derivative works. However, this 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 copyright procedures in the Internet Standards process must be followed, or when it's translated into languages other than English.

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 💖

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

📦 where this page comes from