RFC 2946

Telnet Data Encryption Option

📅 published September 2000, from ietf

RFC 2946: Telnet Data Encryption Option 🎀

Title block, bestie 💖

Network Working Group, Request for Comments: 2946. The author is T. Ts'o from VA Linux Systems. It's on the Standards Track, dated September 2000. The title block doesn't list any RFCs that it obsoletes or updates. 🦋

Status of This Memo ✨

Okay so this is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 💅. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🌸.

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

Abstract

This doc describes the telnet encryption option as a generic way to provide data confidentiality services for the telnet data stream 🔐. It summarizes the encryption types and codes that are used today, but it does not define a specific encryption algorithm 🙈. Separate documents are going to be published that define how this option gets implemented for each encryption algorithm, so keep an eye out for those 👀.

1. Command Names and Codes ✨

So here's the full lineup of ENCRYPT command codes and encryption types. The ENCRYPT option itself is number 38 💖.

ENCRYPT         38

    Encryption Commands
    IS               0
    SUPPORT          1
    REPLY            2
    START            3
    END              4
    REQUEST-START    5
    REQUEST-END      6
    ENC_KEYID        7
    DEC_KEYID        8

    Encryption Types
    NULL             0
    DES_CFB64        1
    DES_OFB64        2
    DES3_CFB64       3
    DES3_OFB64       4
    CAST5_40_CFB64   8
    CAST5_40_OFB64   9
    CAST128_CFB64   10
    CAST128_OFB64   11

Following historical practice, new encryption type numbers will be handed out by IANA under a First Come First Served policy, as laid out in RFC 2434 [3] 📋. Now, authentication type numbers come from an 8-bit number space (just like most values in the telnet spec), and that space isn't expected to run out. Still, if it ever becomes a problem, once more than 50% of the number space is allocated, IANA shall refer allocation requests to either the IESG or a designated expert for approval 🫶.

2. Command Meanings 💅

Here's what each command actually means. Pay attention, because the "who's allowed to send what" details are super important 🔥.

WILL ENCRYPT

IAC WILL ENCRYPT

The sender is willing to send encrypted data 💖.

WONT ENCRYPT

IAC WONT ENCRYPT

The sender refuses to send encrypted data 🙅‍♀️.

DO ENCRYPT

IAC DO ENCRYPT

The sender is willing to receive encrypted data ✨.

DONT ENCRYPT

IAC DONT ENCRYPT

The sender refuses to accept encrypted data 💀.

SUPPORT

IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE

This one's how the sender says which encryption types it can handle 💜. Only the side that's DO ENCRYPT may send SUPPORT. The current types are listed in the current version of the Assigned Numbers document [1] 📚.

The encryption-type-list may only include types that can actually be supported during the current session 🎯. If ENCRYPT is negotiated together with AUTH, the SUPPORT message MUST NOT be sent until after the session key has been determined. Otherwise, it's impossible to know whether the selected encryption type can be properly initialized, based on the type and length of the key that's available 🔑.

IS

IAC SB ENCRYPT IS encryption-type ... IAC SE

This is how the sender says which encryption type to use, plus any initial data that's needed 🎀. Only the side that's WILL ENCRYPT may send IS, because that's how the encryption-type scheme gets initialized 🧚.

REPLY

IAC SB ENCRYPT REPLY encryption-type ... IAC SE

The sender is continuing the initial data exchange so the encryption-type scheme can be initialized 🔄. Only the side that's DO ENCRYPT may send REPLY.

START

IAC SB ENCRYPT START keyid IAC SE

The sender is saying that all data following this command in the data stream will be encrypted using the previously negotiated method 🔐. Only the side that's WILL ENCRYPT may send START.

The keyid is a variable length field 📏. Different encryption mechanisms use it to figure out which key to use, in case several keys are known on either side of the connection. The keyid field is encoded with the most significant byte first 🔢. A keyid value of zero is reserved for the default encryption key. That's typically a key derived during authentication, using the AUTHENTICATION option 🗝️. The keyid field must be at least one byte long. The only valid values for keyid are the ones that have been received in a DEC_KEYID command 💅.

END

IAC SB ENCRYPT END IAC SE

The sender is saying that all data following this command in the data stream will not be encrypted 🫠. Only the side that's WILL ENCRYPT may send END.

REQUEST-START

IAC SB ENCRYPT REQUEST-START keyid IAC SE

The sender is asking the remote side to start encrypting the telnet data stream 🙏. Only the side that's DO ENCRYPT may send REQUEST-START. The keyid is only advisory, so it may be omitted 🌈.

REQUEST-END

IAC SB ENCRYPT REQUEST-END IAC SE

The sender is asking the remote side to stop encrypting the telnet data stream 🛑. Only the side that's DO ENCRYPT may send REQUEST-END.

ENC_KEYID

IAC SB ENCRYPT ENC_KEYID keyid IAC SE

The sender is asking the remote side to check that keyid maps to a valid key, or to confirm that the keyid it received in a DEC_KEYID command is valid 🕵️‍♀️. If keyid is omitted, that means there are no more known keyids, so the attempt to find a common keyid has failed 😭. Only the side that's WILL ENCRYPT may send ENC_KEYID.

DEC_KEYID

IAC SB ENCRYPT DEC_KEYID keyid IAC SE

The sender is asking the remote side to check that keyid maps to a valid key on the remote side, or to confirm that the keyid it received in an ENC_KEYID command is valid 🔍. If keyid is omitted, that means there are no more known keyids, so the attempt to find a common keyid has failed 🥲. Only the side that's DO ENCRYPT may send DEC_KEYID.

Part 1 of 2 ends here. Part 2 picks up with Section 3 (Default Specification) and carries on through the rest of the doc, References and all 🧚💖

6. Security Considerations ✨

okay bestie, security is where things get spicy 🌶️🔥. the ENCRYPT option on its own only protects against passive attacks 👀. that means it keeps a nosy person who's just watching the IP packets go by from reading your stuff. but an active attacker who can change packets in flight could stop ENCRYPT from ever getting negotiated 💀. not me letting that happen!!

the fix is to pair it with the Telnet Authentication option 🎀. specifically, putting ENCRYPT_USING_TELOPT in the authentication-type-pair can force Encryption to be negotiated even when someone's actively messing with the connection. iykyk 🫶

there's also another sneaky move. an active attacker can interfere with attempts to start or restart encryption 😤. so if the user asked for encryption, and the client can't get enabling or re-enabling encryption to work, the client must assume it's being attacked 🚨 and it MUST immediately terminate the telnet connection. no hesitation, bestie, just bounce 💅

7. Future directions for Telnet Encryption

okay so this spec gives us a way to keep the telnet data stream confidential 🔐. the tea is that none of the encryption mechanisms under this option provide data integrity 😭. that's because designing a protocol that gives integrity services efficiently in a stream-oriented protocol is genuinely hard 🥲

BUT the TELNET START_TLS specification gives you confidentiality, integrity, and compression 👑. future telnet encryption work should really look closely at using it. one promising approach would be to use the anonymous Diffie-Hellman mode of TLS, followed by the telnet AUTHENTICATION option, where the authentication mechanism includes the client and server finished messages computed during the TLS negotiation 🧚✨. big brain energy, periodt 🧠💜

8. Acknowledgments

big thank-yous 🫶🌸 to Dave Borman of Cray Research, who originally wrote this document. he got help from Theodore Ts'o of MIT and the IETF Telnet Working Group. the squad really came through 💖

9. References

  • [1] Reynolds, J. and J. Postel, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
  • [2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
  • [3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

10. Author's Address

the editor of this one is Theodore Ts'o 🍓. here's where to find them:

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

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

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

the vibe here is basically: you're free to copy and share this document, and to write derivative works that comment on or explain it or help with implementing it 💖. you can publish and distribute those too, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on all copies and derivative works 📜. 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 developing Internet standards (in which case the Internet Standards process copyright procedures must be followed) or translating it into languages other than English 🌈.

these limited permissions are perpetual, and the Internet Society or its successors or assigns won't revoke them 🫶.

and the legal bit, which I'm keeping word for word 📜💅:

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 coming from the Internet Society 🌸✨

📦 where this page comes from