idnits 2.17.1 draft-tso-telnet-encryption-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 7) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9565 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 305 looks like a reference -- Missing reference section? '2' on line 307 looks like a reference -- Missing reference section? '3' on line 309 looks like a reference -- Missing reference section? '4' on line 311 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ts'o, Editor 3 Internet-Draft Massachusetts Institute of Technology 4 draft-tso-telnet-encryption-00.txt February 1998 6 Telnet Data Encryption Option 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Command Names and Codes 28 ENCRYPT 38 29 IS 0 30 SUPPORT 1 31 REPLY 2 33 START 3 34 END 4 35 REQUEST-START 5 36 REQUEST-END 6 38 ENC_KEYID 7 39 DEC_KEYID 8 41 NULL 0 42 DES_CFB64 1 43 DES_OFB64 2 45 2. Command Meanings 47 IAC WILL ENCRYPT 48 The sender of this command is willing to send encrypted data. 50 IAC WONT ENCRYPT 52 The sender of this command refuses to send encrypted data. 54 IAC DO ENCRYPT 56 The sender of this command is willing to receive encrypted data. 58 IAC DONT ENCRYPT 60 The sender of this command refuses to accept encrypted data. 62 IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE 64 The sender of this command is stating what types of encryption it 65 will support. Only the side of the connection that is DO ENCRYPT 66 may send the SUPPORT command. The current types of encryption are 67 listed in the current version of the Assigned Numbers document[1]. 69 IAC SB ENCRYPT IS encryption-type ... IAC SE 71 The sender of this command is stating what type of encryption to 72 use, and any initial data that is needed Only the side of the con- 73 nection that is WILL ENCRYPT may send the IS command. to initial- 74 ize the encryption-type scheme. 76 IAC SB ENCRYPT REPLY encryption-type ... IAC SE 78 The sender of this command is continuing the initial data exchange 79 that is needed to initialize the encryption-type scheme. Only the 80 side of the connection that is DO ENCRYPT may send the REPLY com- 81 mand. 83 IAC SB ENCRYPT START keyid IAC SE 85 The sender of this command is stating that at this point in the 86 data stream, all following data will be encrypted, via the previ- 87 ously negotiated method of data encryption. Only the side of the 88 connection that is WILL ENCRYPT may send the START command. 90 The keyid is a variable length field. It is my be used by various 91 encryption mechanisms to identify which encryption key is to be 92 used, when multiple encryption keys might be known on either side 93 of the connection. The keyid field is encoded with the most sig- 94 nificant byte first, and a keyid value of zero is reserved to in- 95 dicate the default encryption key (this would typically be an en- 96 cryption key derived during authentication, with the AUTHENTICA- 97 TION option). The keyid field must be at least one byte long. 99 The only valid values for "keyid" will be those that have been re- 100 ceived in a DEC_KEYID command. 102 IAC SB ENCRYPT END IAC SE 104 The sender of this command is stating that at this point in the 105 data stream, all following data will no longer be encrypted. Only 106 the side of the connection that is WILL ENCRYPT may send the END 107 command. 109 IAC SB ENCRYPT REQUEST-START keyid IAC SE 111 The sender of this command requests that the remote side begin en- 112 cryption of the telnet data stream. Only the side of the connec- 113 tion that is DO ENCRYPT may send the REQUEST-START command. The 114 keyid is only advisory, and my be omitted. 116 IAC SB ENCRYPT REQUEST-END IAC SE 118 The sender of this command requests that the remote side stop en- 119 cryption of the telnet data stream. Only the side of the connec- 120 tion that is DO ENCRYPT may send the REQUEST-END command. 122 IAC SB ENCRYPT ENC_KEYID keyid IAC SE 124 The sender of this requests that the remote side verify that "key- 125 id" maps to a valid key on the remote side; or verifies that the 126 "keyid" received in a DEC_KEYID command is valid. If keyid is om- 127 itted, it implies that there are no more known keyids, and that 128 the attempt to find a common keyid has failed. Only the side of 129 the connection that is WILL ENCRYPT may send the ENC_KEYID com- 130 mand. 132 IAC SB ENCRYPT DEC_KEYID keyid IAC SE 134 The sender of this requests that the remote side verify that "key- 135 id" maps to a valid key on the remote side; or verifies that the 136 "keyid" received in a ENC_KEYID command is valid. If keyid is om- 137 itted, it implies that there are no more known keyids, and that 138 the attempt to find a common keyid has failed. Only the side of 139 the connection that is DO ENCRYPT may send the DEC_KEYID command. 141 IAC SB ENCRYPT KEYID_OK keyid IAC SE 143 3. Default Specification 145 The default specification for this option is 146 WONT ENCRYPT 147 DONT ENCRYPT 149 meaning there will not be any encryption of the Telnet data stream. 151 4. Motivation 153 The Telnet protocol has no form of protection from some intervening 154 gateway looking at IP packets as they travel through the network. 155 This is especially dangerous when passwords are sent as clear text 156 over the network. This option provides a method for encrypting part 157 or all of the data stream. 159 An entire session could be encrypted, but many times the user doesn't 160 care that much about most of the data, and would rather not have to 161 pay the price of encrypting and decrypting all the data. In this si- 162 tuation, usually all that needs to be protected is when the user is 163 typing a password. When the ENCRYPT option used in conjunction with 164 the LINEMODE option, a very simple heuristic can be used to identify 165 many instances when passwords are being typed, and automatically en- 166 crypt the data stream for the duration of the password. If the 167 client has the LINEMODE option enabled, and the current mode is EDIT, 168 but the client is DO ECHO, then it can safely assume that something 169 is being typed that is not appearing on the screen, and should be en- 170 crypted. 172 The front end telnet should have commands to allow the user to turn 173 on and off encryption in both directions of the data stream. 175 5. Implementation Rules 177 Once the Encryption option is in effect, all data, including TELNET 178 options, are encrypted. Encryption begins with the octet of data im- 179 mediately following the "IAC SB ENCRYPT START encryption-type IAC SE" 180 command. Encryption ends after the "IAC SB ENCRYPT END IAC SE" com- 181 mand. 183 WILL and DO are used only at the beginning of the connection to ob- 184 tain and grant permission for future negotiations. If encryption is 185 needed in both directions, then the ENCRYPT option must be negotiated 186 in both directions. 188 Once the two hosts have exchanged a WILL and a DO, the sender of the 189 DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side 190 know what types of encryption it is willing to accept. In the re- 191 quest, a list of supported encryption schemes is sent. Only the 192 sender of the DO may send a list of supported encryption types (IAC 193 SB ENCRYPT SUPPORT encryption-type-list IAC SE). Only the sender of 194 the WILL may actually transmit encrypted data. This is initiated via 195 the "IAC SB ENCRYPT START IAC SE" command, and terminated via the 196 "IAC SB ENCRYPT END IAC SE" command. If a START is received, and 197 then a second START is received before receiving an END, the second 198 START is ignored. 200 If the sender of the DO would like the remote side to begin sending 201 encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE" 202 command. If the sender of the DO would like the remote side to stop 203 sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP 204 IAC SE" command. 206 The current list of encryption types are listed in the current AS- 207 SIGNED NUMBERS RFC [1]. 209 If the receiver of the SUPPORT command does not support any of the 210 encryption types listed in the SUPPORT command, it should send an 211 "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there is not a com- 212 mon encryption type. It may also send an IAC WONT ENCRYPT command to 213 turn off the ENCRYPT option. 215 The order of the encryption types in a SUPPORT command must be or- 216 dered to indicate a preference for different encryption types, the 217 first type being the most preferred, and the last type the least pre- 218 ferred. 220 If this option is used in conjunction with the LINEMODE [2] option, 221 then when the client side has EDIT mode on, and is DO ECHO, it can 222 assume that a password has been requested, and automatically start 223 encrypting the data stream until either a WONT ECHO has been re- 224 ceived, or the EDIT mode has been turned off. Because the state of 225 echoing and editing are sent in two separate telnet commands, if both 226 states are changing, the server side of the connection should take 227 care to send the WONT ECHO before it sends the the LINEMODE MODE com- 228 mand when echoing is being enabled, and when echoing is being dis- 229 abled, send the WILL ECHO after it sends the LINEMODE MODE command. 230 This will keep the client from needlessly turning on and off encryp- 231 tion when the state of both echoing and editing are being enabled or 232 disabled. 234 If the LINEMODE option is not being used, then the server side may 235 send a REQUEST-START when server side terminal driver has echo dis- 236 abled and line editing enabled, and send a REQUEST-END when the ter- 237 minal driver has either echo re-enabled, or line editing disabled. 239 If the ENCRYPT option has been enabled, and encrypted date is is be- 240 ing received, the receipt of an "IAC WONT ENCRYPT" implies the re- 241 ceipt of an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream 242 is no longer encrypted. 244 If the COMPRESSION option is used with the ENCRYPT option, the data 245 must be compressed first, and then encrypted. 247 The following is an example of use of the option: 248 Host1 Host2 250 [ Host1 requests Host2 negotiate to encrypt data that it sends to 251 Host1, and Host2 verifies that it will negotiate the encryption 252 of data that it sends to Host1. ] 253 DO ENCRYPT 254 WILL ENCRYPT 255 [ Host1 requests that Host2 enable encryption as soon as the 256 initialization is completed, and informs Host2 that is supports 257 DES_CFB64. ] 258 IAC SB ENCRYPT REQUEST-START IAC 259 SE 260 IAC SB ENCRYPT SUPPORT DES_CFB64 261 IAC SE 262 [ Host2 sends the initial feed to Host1, Host1 decrypts, 263 modifies, and returns the feed, and Host2 re-verifies the feed. 264 ] 265 IAC SB ENCRYPT IS DES_CFB64 266 FEED_INIT 144 146 63 229 237 267 148 81 143 IAC SE 268 IAC SB ENCRYPT REPLY DES_CFB64 269 FEED_VRFY 103 207 181 71 224 55 270 229 98 IAC SE 271 IAC SB ENCRYPT IS DES_CFB64 272 FEED_OK IAC SE 273 [ Host2 is now free to start sending encrypted data, and since a 274 REQUEST-START was received, it enables encryption. ] 275 IAC SB ENCRYPT START IAC SE 276 [ All data from Host2 to Host1 is now encrypted. ] 277 IAC SB ENCRYPT END IAC SE 278 [ All data from Host2 to Host1 is now in clear text again. ] 280 It is expected that any implementation that supports the Telnet EN- 281 CRYPT option will support all of this specification. 283 6. Security Issues 285 The ENCRYPT option is intended to provide protection against passive 286 attacks, not against active attacks. In other words, the ENCRYPT op- 287 tion can be used to provide protection from someone who is just 288 watching the IP packets as they pass through the network, but may not 289 from someone who is able to modify packets in flight. This is not to 290 say that the ENCRYPT option doesn't provide any protection against an 291 active attacker, but that additional code and steps would have to be 292 done in order to provide compelete protection from an active attack- 293 er. By using the authentication option and negotiating the encryp- 294 tion option within authentication messages, active attacks are not 295 possible. 297 6. Acknowledgements 299 This document was originally written by Dave Borman of Cray Research, 300 with the assistance of Theodore Ts'o of MIT and the IETF Telnet Work- 301 ing Group. 303 7. References 305 [1] Reynolds, Joyce, and Postel, Jon, "Assigned Numbers", RFC 1060, 306 ISI, March 1990. 307 [2] Internet Engineering Task Force, "Telnet Linemode Option", RFC 308 1116, D. Borman, Editor, Cray Research, Inc., August 1989. 309 [3] Internet Engineering Task Force, "Telnet Authentication Option", 310 RFC 1416, D. Borman, Editor, Cray Research, Inc., February 1993. 311 [4] Internet Engineering Task Force, "Telnet Authentication Option", 312 Internet Draft, R. Basch, Editor, Lehman Brothers, Inc., November 313 1995. 315 Author's Address 317 Theodore Ts'o, Editor 318 Massachusetts Institute of Technology 319 MIT Room E40-343 320 77 Massachusetts Ave. 321 Cambridge, MA 02139 323 Phone: (617) 253-8091 325 EMail: tytso@mit.edu