Network Working Group T. Ts'o, Editor Internet-Draft Massachusetts Institute of Technology draft-tso-telnet-encryption-01.txt November 1998 Telnet Data Encryption Option Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Command Names and Codes ENCRYPT 38 IS 0 SUPPORT 1 REPLY 2 START 3 END 4 REQUEST-START 5 REQUEST-END 6 ENC_KEYID 7 DEC_KEYID 8 NULL 0 DES_CFB64 1 DES_OFB64 2 2. Command Meanings IAC WILL ENCRYPT Expires May 1999 [Page 1]
Internet-Draft Telnet Data Encryption Option November 1998 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 con- nection that is WILL ENCRYPT may send the IS command. to initial- ize 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 REPLY com- mand. IAC SB ENCRYPT START keyid 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 previ- ously 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 my be 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 sig- nificant byte first, and a keyid value of zero is reserved to in- dicate the default encryption key (this would typically be an en- cryption key derived during authentication, with the AUTHENTICA- TION option). The keyid field must be at least one byte long. Expires May 1999 [Page 2]
Internet-Draft Telnet Data Encryption Option November 1998 The only valid values for "keyid" will be those that have been re- ceived in a DEC_KEYID 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 keyid IAC SE The sender of this command requests that the remote side begin en- cryption of the telnet data stream. Only the side of the connec- tion 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 en- cryption of the telnet data stream. Only the side of the connec- tion 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 "key- id" maps to a valid key on the remote side; or verifies that the "keyid" received in a DEC_KEYID command is valid. If keyid is om- itted, 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 com- mand. IAC SB ENCRYPT DEC_KEYID keyid IAC SE The sender of this requests that the remote side verify that "key- id" 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 om- itted, 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. IAC SB ENCRYPT KEYID_OK keyid IAC SE 3. Default Specification The default specification for this option is Expires May 1999 [Page 3]
Internet-Draft Telnet Data Encryption Option November 1998 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 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 si- tuation, 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 en- crypt 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 en- crypted. The front end telnet should have commands to allow the user to turn on and off encryption in both directions of the data stream. 5. Implementation Rules 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" com- mand. WILL and DO are used only at the beginning of the connection to ob- tain 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 re- quest, 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 Expires May 1999 [Page 4]
Internet-Draft Telnet Data Encryption Option November 1998 "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 AS- SIGNED 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 com- mon 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 or- dered to indicate a preference for different encryption types, the first type being the most preferred, and the last type the least pre- ferred. 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 re- ceived, or the EDIT mode has been turned off. Because the state of echoing and editing are sent in two separate telnet commands, if both states are changing, the server side of the connection should take care to send the WONT ECHO before it sends the the LINEMODE MODE com- mand when echoing is being enabled, and when echoing is being dis- abled, send the WILL ECHO after it sends the LINEMODE MODE command. This will keep the client from needlessly turning on and off encryp- tion when the state of both echoing and editing are being enabled or disabled. If the LINEMODE option is not being used, then the server side may send a REQUEST-START when server side terminal driver has echo dis- abled and line editing enabled, and send a REQUEST-END when the ter- minal driver has either echo re-enabled, or line editing disabled. If the ENCRYPT option has been enabled, and encrypted date is is be- ing received, the receipt of an "IAC WONT ENCRYPT" implies the re- ceipt 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. Expires May 1999 [Page 5]
Internet-Draft Telnet Data Encryption Option November 1998 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 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 decrypts, modifies, and returns the feed, and Host2 re-verifies the feed. ] IAC SB ENCRYPT IS DES_CFB64 FEED_INIT 144 146 63 229 237 148 81 143 IAC SE IAC SB ENCRYPT REPLY DES_CFB64 FEED_VRFY 103 207 181 71 224 55 229 98 IAC SE IAC SB ENCRYPT IS DES_CFB64 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 EN- CRYPT option will support all of this specification. 6. Security Considerations The ENCRYPT option used in isolation provides protection against pas- sive 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, the ENCRYPT_ON bit in the authentication-type-pair can be used to force that Encryption be negotiated even in the face of active attacks. Expires May 1999 [Page 6]
Internet-Draft Telnet Data Encryption Option November 1998 6. 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 Work- ing Group. 7. References [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. [3] Internet Engineering Task Force, "Telnet Authentication Option", RFC 1416, D. Borman, Editor, Cray Research, Inc., February 1993. [4] Internet Engineering Task Force, "Telnet Authentication Option", Internet Draft, T. Ts'o, Editor, MIT, November 1998. Author's Address Theodore Ts'o, Editor Massachusetts Institute of Technology MIT Room E40-343 77 Massachusetts Ave. Cambridge, MA 02139 Phone: (617) 253-8091 EMail: tytso@mit.edu [Page 7]