RFC 2953

RFC 2953: Telnet Encryption: DES 64 bit Output Feedback 🎀

okay bestie, let's talk about RFC 2953 🦋 It's an Informational RFC from September 2000, so it's not a standard, it's just sharing info for the Internet community 💅 It was written by Theodore Ts'o (the editor) of VA Linux Systems, with the original work by Dave Borman of Cray Research and help from the IETF Telnet Working Group 🫶 The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or changed here ✨

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.

Abstract 💜

This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option.

1. Command Names and Codes 🍓

Here are the names and numbers you'll need. The encryption type is DES_OFB64 with value 2, and the suboption commands are OFB64_IV (1), OFB64_IV_OK (2), and OFB64_IV_BAD (3):

Encryption Type

   DES_OFB64        2

Suboption Commands

   OFB64_IV         1
   OFB64_IV_OK      2
   OFB64_IV_BAD     3

2. Command Meanings 🧚

Now for what each command actually does, bestie 👑

Here's the first message, which carries the initial vector (IV):

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

The sender makes a random 8 byte initial vector and sends it over using OFB64_IV. The IV goes out in clear text, no hiding it 🙈 Only the side that is WILL ENCRYPT is allowed to send OFB64_IV.

The replies look like this:

IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_OK IAC SE
IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_BAD IAC SE

The sender uses these to either accept or reject the IV it got in OFB64_IV. Only the side that is DO ENCRYPT can send OFB64_IV_OK and OFB64_IV_BAD. Here's the lowkey important part: OFB64_IV_OK MUST be sent for backwards compatibility with existing implementations 💅 Honestly, there isn't really a reason to send OFB64_IV_BAD unless there's a protocol violation, like the IV not being the right length (exactly 8 bytes) 💀

3. Implementation Rules 🔥

Okay, these are the rules for keeping your state machine in check 🌈

Once an OFB64_IV_OK has been received, the WILL ENCRYPT side should do keyid negotiation using the ENC_KEYID command. After the keyid negotiation finds a common keyid, the WILL ENCRYPT side can send START and END commands. Data then gets encrypted with the DES 64 bit Output Feedback algorithm ✨

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. Don't let the in-between chatter mess with your vibe 🫶

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. It uses the new key and the initial vector from the last OFB64_IV command sent (received) 🦋

If a new OFB64_IV command is sent (received) and encryption (decryption) is enabled, the machine must be re-initialized right after the end of the OFB64_IV command. It uses the new initial vector and the keyid from the last START command sent (received) 🎀

If encryption (decryption) is not 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 command and the initial vector from this OFB64_IV command 🌸

4. Algorithm 💖

Here's the math, nerd style 🤓 V[i] is the initial 64 bit vector, V[n] is the nth 64 bit vector, D[n] is the nth chunk of 64 bits of data to encrypt (decrypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) data. Then:

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

5. Integration with the AUTHENTICATION telnet option 🔐

Remember how the telnet ENCRYPTION option specs say a keyid value of zero means the default encryption key? That key might come from the telnet AUTHENTICATION option 👀 If that default key is less than 8 bytes, then DES_OFB64 may not be offered or used as a valid telnet encryption option, no exceptions 💀

If the encryption key from the AUTHENTICATION option is greater than 16 bytes, the first 8 bytes should be used as keyid 0 for data going from the telnet server to the telnet client. The second 8 bytes should be used as keyid 0 for data going from the client to the server ⭐ Otherwise, the first 8 bytes of the key are used as keyid zero for the ENCRYPTION option in both directions, with the client as WILL ENCRYPT and the server as WILL ENCRYPT too 🧚

No matter what, if the key from the AUTHENTICATION option wasn't a DES key, the key used by DES_CFB64 has to have its parity corrected after you figure it out with the algorithm above 🫧

Here's the tea ☕ The algorithm above assumes it's safe to use a non-DES key (or part of one) as a DES key. That isn't true for every cipher system, but this is set as the default because it works for most authentication systems people use today, and it keeps things compatible with existing implementations 🌈 New telnet AUTHENTICATION mechanisms can specify other ways to pick the keys for this cipher suite. They should do that when their session key isn't a DES key and this algorithm can't be used safely 💜

6. Security Considerations 🚨

Okay, this section is serious, so read it twice 😭

Output Feedback encryption does not ensure data integrity. An active attacker may be able to substitute text if he can predict the clear text that was being transmitted. Because of that, the Cipher Feedback encryption type should be used instead, since it gives limited detectability of data modification. Neither one provides true data integrity, though 💀

The tradeoff is that adding a message authentication code (MAC) would really increase the number of bytes needed to send a single character in telnet. That hurts performance on slow links, like dialup 🐢

7. Acknowledgments 🫶

This document was originally written by Dave Borman of Cray Research with the assistance of the IETF Telnet Working Group. Thank you, legends 👑

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.