Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
D. Borman, Editor
Cray Research, Inc.
February 1991
This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the telnet-ietf@cray.com mailing list.
ENCRYPT TBA
IS 0
SUPPORT 1
REPLY 2
START 3
END 4
REQUEST-START 5
REQUEST-END 6
NULL 0
KRBDES 1
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 what 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].
IAC SB ENCRYPT IS encryption-type ... IAC SE
The sender of this command is stating what 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 that is needed to initialize the encryption-type scheme. Only the side of the connection that is DO ENCRYPT may send the IS command.
IAC SB ENCRYPT START IAC SE
The sender of this command is stating that at this point in the data stream, all following data will 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.
IAC SB ENCRYPT END IAC SE
The sender of this command is stating that at this point in the data stream, all following data will no longer be encrypted. Only the side of the connection that is WILL ENCRYPT may send the END command.
IAC SB ENCRYPT REQUEST-START 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.
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.
The default specification for this option is
WONT ENCRYPT
DONT ENCRYPT
meaning there will not be any encryption of the Telnet data stream.
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 part or all of the data stream.
An entire session could be encrypted, but many times the user doesn't care that much about most of the data, and would rather not have to pay the price of encrypting and decrypting all the data. In this situation, usually all that needs to be protected is when the user is typing a password. When the ENCRYPT option used in conjunction with the LINEMODE option, a very simple heuristic can be used to identify many instances when passwords are being typed, and automatically encrypt the data stream for the duration of the password. If the client has the LINEMODE option enabled, and the current mode is EDIT, but the client is DO ECHO, then it can safely assume that something is being typed that is not appearing on the screen, and should be encrypted.
The front end telnet should have commands to allow the user to turn on and off encryption in both directions of the data stream.
FEED-INIT 1 FEED-VRFY 2 FEED-FAIL 3 FEED-OK 4 FEED-VRFY-FAIL 5
To use the ENCRYPT option with this form of DES encryption, either the AUTHENTICATION option with a type of KERBEROS_V4 or KERBEROS_V5 and the NEWKEY suboption must have been done previously, to get a unique DES encryption key. This value will be referred to as the "encrypt key" in the rest of this section. The negotiation of the feeds is to ensure that a random feed is used to prime the DES encryption, and to ensure that encryption and decryption will work before the encryption is actually enabled. This is necessary, because once encryption is enabled (especially if encryption is being done in both directions), if the receiver is unable to do decryption for some reason, encryption can never be turned off and the connection would have to be dropped.
There are two DES feed values in this description, feed0 and feed1. Feed0 is a random 8 octet value. Feed1 is gotten by doing a bitwise exclusive-or with the first six octets of feed0 with the decimal values 75, 82, 66, 68, 69, and 83. (These values correspond to the ASCII codes for the string "KRBDES".) Feed1 is used to initialize the encryption of the data.
IAC SB ENCRYPT IS FEED-INIT <encrypted feed0> IAC SE
The sender of this command generates a random feed0 value, encrypts it using the encryption key, and sends it to the other side in a FEED-INIT command. The sender should also compute the clear-text feed1 value for later use. FEED-INIT is only sent by the side of the connection that is WILL ENCRYPT.
IAC SB ENCRYPT REPLY FEED-VRFY <encrypted feed1> IAC SE
When a FEED-INIT command is received, it should be decrypted with the encrypt key to get the clear-text feed0 value. The feed1 value should then be generated from this. This feed1 value is then encrypted again using the encrypt key, and returned in the FEED-VRFY command. When the other side receives the FEED-VRFY, it then decrypts it, and makes sure that the decrypted value matches the original clear-text feed1 value.
IAC SB ENCRYPT IS FEED-FAIL [msg] IAC SE
If the results from decrypting the data in the FEED-VRFY command does not match the original feed1 value that was sent across, a FEED-FAIL command is sent to the other side to indicate that the initialization failed.
IAC SB ENCRYPT IS FEED-OK IAC SE
If the results from decrypting the data in the FEED-VRFY command successfully match the original feed1 value that was sent across, a FEED-OK command is sent to the other side to indicate that the initialization succeeded. Once this command is sent, the sender is then free to send an IAC SB ENCRYPT START IAC SE command at any time.
IAC SB ENCRYPT REPLY FEED-VRFY-FAIL [msg] IAC SE
If the receiver of the FEED-INIT is not able to decrypt the encrypted feed1 for any reason, then this command is sent to indicate that the initialization failed.
Once the Encryption option is in effect, all data, including TELNET options, are encrypted. Encryption begins with the octet of data im- mediately 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. If encryption is needed in both directions, then 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 what 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.
The current list of encryption types are listed in the current ASSIGNED NUMBERS RFC [1].
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 is not a common encryption type. 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 this option is used in conjunction with the LINEMODE [2] option, then when the client side has EDIT mode on, and is DO ECHO, it can assume that a password has been requested, and automatically start encrypting the data stream until either a WONT ECHO has been received, or the EDIT mode has been turned off.
If the LINEMODE option is not being used, then the server side may
send a REQUEST-START when server side terminal driver has echo disabled and line editing enabled, and send a REQUEST-END when the terminal driver has either echo re-enabled, or line editing disabled.
If the ENCRYPT option has been enabled, and encrypted date is 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.
If the COMPRESSION option is used with the ENCRYPT option, the data must be compressed first, and then encrypted.
The following is an example of use of the option:
Host1 Host2
[ Host1 requests Host2 negotiate to encrypt data that it sends to
Host1, and Host2 verifies that it will 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
KRBDES. ]
IAC SB ENCRYPT REQUEST-START IAC
SE
IAC SB ENCRYPT SUPPORT KRBDES
IAC SE
[ Host2 sends the initial feed to Host1, Host1 decrypts,
modifies, and returns the feed, and Host2 re-verifies the feed. ]
IAC SB ENCRYPT IS KRBDES
FEED_INIT 144 146 63 229 237
148 81 143 IAC SE
IAC SB ENCRYPT REPLY KRBDES
FEED_VRFY 103 207 181 71 224 55
229 98 IAC SE
IAC SB ENCRYPT IS KRBDES FEED_OK
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.
[1] Reynolds, Joyce, and Postel, Jon, "Assigned Numbers", RFC 1060,
ISI, March 1990
[2] Internet Engineering Task Force, "Telnet Linemode Option", RFC
1116, D. Borman, Editor, Cray Research, Inc., August 1989
David A. Borman, Editor
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55123
Phone: (612) 452-6650
Mailing List: telnet-ietf@CRAY.COM
EMail: dab@CRAY.COM