Telnet Encryption: Telnet Data Encryption Option
A generic Telnet option that lets either side scramble its half of the conversation, leaving the choice of cipher to companion documents.
Ts'o, T., "Telnet Data Encryption Option", RFC 2946, DOI 10.17487/RFC2946, September 2000, <https://www.rfc-editor.org/info/rfc2946>.
@misc{rfc2946,
series = {Request for Comments},
number = 2946,
howpublished = {RFC 2946},
publisher = {RFC Editor},
doi = {10.17487/RFC2946},
url = {https://www.rfc-editor.org/info/rfc2946},
author = {T. Ts'o},
title = {{Telnet Data Encryption Option}},
pagetotal = 8,
year = 2000,
month = sep,
} RFC text
Contents
Network Working Group T. Ts'o
Request for Comments: 2946 VA Linux Systems
Category: Standards Track September 2000
Telnet Data Encryption Option
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes a the telnet encryption option as a generic
method of providing data confidentiality services for the telnet data
stream. While this document summarizes currently utilized encryption
types and codes, it does not define a specific encryption algorithm.
Separate documents are to be published defining implementations of
this option for each encryption algorithm.
1. Command Names and Codes
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, future encryption type numbers
will be assigned by the IANA under a First Come First Served
policy as outlined by RFC 2434 [3]. Despite the fact that
authentication type numbers are allocated out of an 8-bit number
space (as are most values in the telnet specification) it is not
anticipated that the number space is or will become in danger of
being exhausted. However, if this should become an issue, when
over 50% of the number space becomes allocated, the IANA shall
refer allocation requests to either the IESG or a designated
expert for approval.
2. Command Meanings
IAC WILL ENCRYPT
The sender of this command is willing to send encrypted data.
IAC WONT ENCRYPT
The sender of this command refuses to send encrypted data.
IAC DO ENCRYPT
The sender of this command is willing to receive encrypted data.
IAC DONT ENCRYPT
The sender of this command refuses to accept encrypted data.
IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE
The sender of this command is stating which types of encryption it
will support. Only the side of the connection that is DO ENCRYPT
may send the SUPPORT command. The current types of encryption are
listed in the current version of the Assigned Numbers document
[1].
The encryption-type-list may only include types which can actually
be supported during the current session. If ENCRYPT is negotiated
in conjunction with AUTH the SUPPORT message MUST NOT be sent
until after the session key has been determined. Otherwise,
it is impossible to know if the selected encryption type can be
properly initialized based upon the type and length of the key
that is available."
IAC SB ENCRYPT IS encryption-type ... IAC SE
The sender of this command is stating which type of encryption to
use, and any initial data that is needed. Only the side of the
connection that is WILL ENCRYPT may send the IS command to
initialize the encryption-type scheme.
IAC SB ENCRYPT REPLY encryption-type ... IAC SE
The sender of this command is continuing the initial data exchange
in order to initialize the encryption-type scheme. Only the side
of the connection that is DO ENCRYPT may send the REPLY command.
IAC SB ENCRYPT START keyid IAC SE
The sender of this command is stating that all data following the
command in the data stream will be be encrypted via the previously
negotiated method of data encryption. Only the side of the
connection that is WILL ENCRYPT may send the START command.
The keyid is a variable length field. It is used by various
encryption mechanisms to identify which encryption key is to be
used, when multiple encryption keys might be known on either side
of the connection. The keyid field is encoded with the most
significant byte first, and a keyid value of zero is reserved to
indicate the default encryption key (this would typically be an
encryption key derived during authentication, with the
AUTHENTICATION option). The keyid field must be at least one byte
long. The only valid values for "keyid" will be those that have
been received in a DEC_KEYID command.
IAC SB ENCRYPT END IAC SE
The sender of this command is stating that all data following the
command in the data stream will not be encrypted. Only the side
of the connection that is WILL ENCRYPT may send the END
IAC SB ENCRYPT REQUEST-START keyid IAC SE
The sender of this command requests that the remote side begin
encryption of the telnet data stream. Only the side of the
connection that is DO ENCRYPT may send the REQUEST-START command.
The keyid is only advisory, and my be omitted.
IAC SB ENCRYPT REQUEST-END IAC SE
The sender of this command requests that the remote side stop
encryption of the telnet data stream. Only the side of the
connection that is DO ENCRYPT may send the REQUEST-END command.
IAC SB ENCRYPT ENC_KEYID keyid IAC SE
The sender of this requests that the remote side verify that
"keyid" maps to a valid key; or verifies that the "keyid" received
in a DEC_KEYID command is valid. If keyid is omitted, it implies
that there are no more known keyids, and that the attempt to find
a common keyid has failed. Only the side of the connection that
is WILL ENCRYPT may send the ENC_KEYID command.
IAC SB ENCRYPT DEC_KEYID keyid IAC SE
The sender of this requests that the remote side verify that
"keyid" maps to a valid key on the remote side; or verifies that
the "keyid" received in a ENC_KEYID command is valid. If keyid is
omitted, it implies that there are no more known keyids, and that
the attempt to find a common keyid has failed. Only the side of
the connection that is DO ENCRYPT may send the DEC_KEYID command.
3. Default Specification
The default specification for this option is
WONT ENCRYPT
DONT ENCRYPT
meaning there will not be any encryption of the Telnet data stream.
4. Motivation
The Telnet protocol has no form of protection from some intervening
gateway looking at IP packets as they travel through the network.
This is especially dangerous when passwords are sent as clear text
over the network. This option provides a method for encrypting the
data stream.
5. Implementation Rules
Once the Encryption option is in effect, all data in the negotiated
direction, including TELNET options, is encrypted. Encryption begins
with the octet of data immediately following the "IAC SB ENCRYPT
START encryption-type IAC SE" command. Encryption ends after the
"IAC SB ENCRYPT END IAC SE" command.
WILL and DO are used only at the beginning of the connection to
obtain and grant permission for future negotiations. The ENCRYPT
option must be negotiated in both directions.
Once the two hosts have exchanged a WILL and a DO, the sender of the
DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side
know the types of encryption it is willing to accept. In the
request, a list of supported encryption schemes is sent. Only the
sender of the DO may send a list of supported encryption types (IAC
SB ENCRYPT SUPPORT encryption-type-list IAC SE). Only the sender of
the WILL may actually transmit encrypted data. This is initiated via
the "IAC SB ENCRYPT START IAC SE" command, and terminated via the
"IAC SB ENCRYPT END IAC SE" command. If a START is received, and
then a second START is received before receiving an END, the second
START is ignored.
If the sender of the DO would like the remote side to begin sending
encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE"
command. If the sender of the DO would like the remote side to stop
sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP
IAC SE" command.
If the receiver of the SUPPORT command does not support any of the
encryption types listed in the SUPPORT command, it should send an
"IAC SB ENCRYPT IS NULL IAC SE" to indicate that there are no
encryption types in common. It may also send an IAC WONT ENCRYPT
command to turn off the ENCRYPT option.
The order of the encryption types in a SUPPORT command must be
ordered to indicate a preference for different encryption types, the
first type being the most preferred, and the last type the least
preferred.
If the ENCRYPT option has been enabled, and encrypted data is being
received, the receipt of an "IAC WONT ENCRYPT" implies the receipt of
an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream is no
longer encrypted.
The following example demonstrates the use of the option:
Host1 Host2
[ Host1 requests Host2 negotiate the encryption of data that
Host2 sends to Host1. Host2 agrees to negotiate the encryption
of data that it sends to Host1. ]
DO ENCRYPT
WILL ENCRYPT
[ Host1 requests that Host2 enable encryption as soon as the
initialization is completed, and informs Host2 that is supports
DES_CFB64. ]
IAC SB ENCRYPT REQUEST-START IAC
SE
IAC SB ENCRYPT SUPPORT DES_CFB64
IAC SE
[ Host2 sends the initial feed to Host1. Host1 acknowledges
receipt of the IV. ]
IAC SB ENCRYPT IS DES_CFB64
CFB64_IV 144 146 63 229 237 148
81 143 IAC SE
IAC SB ENCRYPT REPLY DES_CFB64
CFB64_IV_OK 103 207 181 71 224
55 229 98 IAC SE
[ Host2 is now free to start sending encrypted data, and since a
REQUEST-START was received, it enables encryption. ]
IAC SB ENCRYPT START IAC SE
[ All data from Host2 to Host1 is now encrypted. ]
IAC SB ENCRYPT END IAC SE
[ All data from Host2 to Host1 is now in clear text again. ]
It is expected that any implementation that supports the Telnet
ENCRYPT option will support all of this specification.
6. Security Considerations
The ENCRYPT option used in isolation provides protection against
passive attacks, but not against active attacks. In other words, it
will provide protection from someone who is just watching the IP
packets as they pass through the network. However, an attacker who
is able to modify packets in flight could prevent the ENCRYPT option
from being negotiated.
This flaw can be remedied by using the Telnet Authentication option
alongside the ENCRYPT option. Specifically, setting
ENCRYPT_USING_TELOPT in the authentication-type-pair can be used to
force that Encryption be negotiated even in the face of active
attacks.
In addition, an active attacker can interfere with attempts to start
or restart encryption. If encryption is requested by the user, and
the client is unable to negotiate enabling or re-enabling encryption,
the client must assume that it is being attacked, and MUST
immediately terminate the telnet connection.
7. Future directions for Telnet Encryption
The specification defines a method for providing data confidentiality
to the telnet data stream. Unfortunately all of the encryption
mechanism provided under this option do not provide data integrity,
because of the complexity of specifying a protocol which provided
integrity services efficiently in a stream-oriented protocol.
The TELNET START_TLS specification provides a scheme which provides
confidentiality, integrity, and compression, and future work for
telnet encryption should closely examine using this specification.
One promising approach would use the anonymous Diffie-Hellman mode of
TLS, followed by the telnet AUTHENTICATION option where the
authentication mechanism would include the client and server finished
messages computed during the TLS negotiation.
8. Acknowledgments
This document was originally written by Dave Borman of Cray Research,
with the assistance of Theodore Ts'o of MIT and the IETF Telnet
Working Group.
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
Theodore Ts'o, Editor
VA Linux Systems
43 Pleasant St.
Medford, MA 02155
Phone: (781) 391-3464
EMail: tytso@mit.edu
11. 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.
AI ELI5
On this page
§4Why Telnet Needs Encryption
The Telnet protocol has no form of protection from an intervening gateway looking at IP packets as they travel through the network. The RFC calls this especially dangerous when passwords are sent as clear text over the network.
The ENCRYPT option is a generic method of providing data confidentiality for the Telnet data stream. It does not define a specific encryption algorithm. Separate documents are to be published defining implementations of the option for each algorithm.
Anyone standing along the road can read an open postcard. This option is a way to put the message in a locked box instead.
§1Command Names and Codes
The option itself is ENCRYPT, option code 38. Its subnegotiation commands are IS (0), SUPPORT (1), REPLY (2), START (3), END (4), REQUEST-START (5), REQUEST-END (6), ENC_KEYID (7) and DEC_KEYID (8).
The RFC also lists 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) and CAST128_OFB64 (11). Future type numbers are assigned by the IANA under a First Come First Served policy.
Each kind of message and each kind of scrambler has its own number, like a menu where you order by number instead of by name.
- 0IS — WILL side states the encryption type and initial data.
- 1SUPPORT — DO side lists the types it supports, most preferred first.
- 2REPLY — DO side continues the initial data exchange.
- 3START — Following data will be encrypted.
- 4END — Following data will not be encrypted.
- 5REQUEST-START — DO side asks the remote side to begin encrypting.
- 6REQUEST-END — DO side asks the remote side to stop encrypting.
- 7ENC_KEYID — WILL side asks the other side to verify a keyid.
- 8DEC_KEYID — DO side asks the other side to verify a keyid.
§2Who May Send What
The usual Telnet WILL, WONT, DO and DONT commands work as usual: WILL ENCRYPT says the sender is willing to send encrypted data, and DO ENCRYPT says it is willing to receive it. The option must be negotiated in both directions, and the default is WONT ENCRYPT and DONT ENCRYPT, meaning no encryption.
Each subnegotiation command is reserved for one side. Only the DO ENCRYPT side may send SUPPORT, REPLY, REQUEST-START, REQUEST-END and DEC_KEYID. Only the WILL ENCRYPT side may send IS, START, END and ENC_KEYID.
The receiver of SUPPORT lists encryption types in order of preference, most preferred first. If it supports none of them, it should send IS NULL to show there is nothing in common, and it may also send WONT ENCRYPT. If ENCRYPT is used together with AUTH, SUPPORT MUST NOT be sent until the session key has been determined.
It is like a walkie-talkie with rules: one side asks what scramblers you know, the other picks one, and each side only says the lines that belong to its part.
§5Starting and Stopping Encryption
Only the sender of WILL actually transmits encrypted data. It begins with IAC SB ENCRYPT START ... IAC SE, and encryption starts at the octet right after that command. It ends after IAC SB ENCRYPT END IAC SE. While it is on, all data in that direction, including Telnet options, is encrypted. If a second START arrives before an END, it is ignored. Receiving IAC WONT ENCRYPT while encrypted data is arriving counts as receiving END.
The DO side can ask the other side to begin with REQUEST-START or to stop with REQUEST-END.
A keyid says which key to use when several are known. It is variable length, at least one byte, sent most significant byte first, and zero is reserved for the default key, typically one derived during authentication. The only valid keyids for START are those received in a DEC_KEYID command. ENC_KEYID and DEC_KEYID let the two sides check that a keyid maps to a valid key, and omitting the keyid means no common keyid was found.
Encryption is like putting on a secret-language hat: a START message says the hat is on, and an END message says it is off again.
§5A Worked Exchange
The RFC's example has Host1 ask Host2 to encrypt what Host2 sends. Host1 sends DO ENCRYPT, Host2 answers WILL ENCRYPT, and Host1 sends REQUEST-START and a SUPPORT list naming DES_CFB64.
Host2 then sends IS DES_CFB64 CFB64_IV with the initial feed, and Host1 acknowledges with REPLY DES_CFB64 CFB64_IV_OK. Because a REQUEST-START was received, Host2 sends START and everything it sends is encrypted until it sends END, after which data is clear text again.
The RFC expects any implementation that supports the ENCRYPT option to support all of this specification.
One computer asks for a secret code, the other agrees and sends a starting puzzle piece, the first one confirms, and then the secret talking begins.
- DO ENCRYPTHost1 asks Host2 to negotiate encryption of the data Host2 sends.
- WILL ENCRYPTHost2 agrees.
- REQUEST-STARTEnable encryption as soon as initialization is complete.
- SUPPORT DES_CFB64The encryption type Host1 supports.
- IS DES_CFB64 CFB64_IVHost2 sends the initial feed.
- REPLY DES_CFB64 CFB64_IV_OKHost1 acknowledges receipt of the IV.
- STARTAll data from Host2 to Host1 is now encrypted.
- ENDData is clear text again.
§6Security Limits
Used alone, ENCRYPT protects against passive attacks, such as someone watching IP packets pass by, but not against active ones. An attacker who can modify packets in flight could prevent the option from being negotiated. Using the Telnet Authentication option (RFC 2941) alongside it fixes this: setting ENCRYPT_USING_TELOPT in the authentication-type-pair can force encryption to be negotiated even under active attack.
An active attacker can also interfere with starting or restarting encryption. If the user requested encryption and the client cannot enable or re-enable it, the client MUST assume it is under attack and immediately terminate the connection.
The lock keeps out people who only look, but a sneaky person who can change messages might stop the lock from being used, so you also need to check who you are talking to.
§7Future Directions
None of the encryption mechanisms under this option provide data integrity. The RFC says this is because of the complexity of specifying a protocol that provides integrity efficiently in a stream-oriented protocol.
The TELNET START_TLS specification gives confidentiality, integrity and compression, and the RFC says future work on Telnet encryption should examine it closely. One promising approach it describes is the anonymous Diffie-Hellman mode of TLS, followed by the Telnet AUTHENTICATION option with an authentication mechanism that includes the client and server finished messages from the TLS negotiation.
The locked box hides the message but cannot tell you if someone scribbled on it. A newer idea would add that check too.