idnits 2.17.1 draft-tso-telnet-encryption-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 280 has weird spacing: '... will provi...' -- 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 (September 1999) is 8990 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) == Unused Reference: '2' is defined on line 322, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-tso-telnet-auth-enc-04 ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ts'o, Editor 2 Internet-Draft VA Linux Systems 3 draft-tso-telnet-encryption-04.txt September 1999 5 Telnet Data Encryption Option 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 0. Abstract 32 This document describes a the telnet encryption option as a generic 33 method of providing data confidentiaility services of the telnet data 34 stream. While this document summarizes currently utilized encrytion 35 types and codes, it does not define a specific encryption algorithm. 36 Separate documents are to be published defining each encryption algo- 37 rithms. 39 1. Command Names and Codes 41 ENCRYPT 38 43 Encryption Commands 44 IS 0 45 SUPPORT 1 46 REPLY 2 47 START 3 48 END 4 49 REQUEST-START 5 50 REQUEST-END 6 52 ENC_KEYID 7 53 DEC_KEYID 8 55 Encryption Types 56 NULL 0 57 DES_CFB64 1 58 DES_OFB64 2 59 DES3_CFB64 3 60 DES3_OFB64 4 61 CAST5_40_CFB64 8 62 CAST5_40_OFB64 9 63 CAST128_CFB64 10 64 CAST128_OFB64 11 66 Following historical practice, future encryption type numbers 67 will be assigned by the IANA under a First Come First Served pol- 68 icy as outlined by RFC 2434 [3]. Despite the fact that authenti- 69 cation type numbers are allocated out of an 8-bit number space 70 (as are most values in the telnet specification) it is not antic- 71 ipated that the number space is or will become in danger of being 72 exhausted. However, if this should become an issue, when over 73 50% of the number space becomes allocated, the IANA shall refer 74 allocation requests to either the IESG or a designated expert for 75 approval. 77 2. Command Meanings 79 IAC WILL ENCRYPT 81 The sender of this command is willing to send encrypted data. 83 IAC WONT ENCRYPT 85 The sender of this command refuses to send encrypted data. 87 IAC DO ENCRYPT 89 The sender of this command is willing to receive encrypted data. 91 IAC DONT ENCRYPT 93 The sender of this command refuses to accept encrypted data. 95 IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE 96 The sender of this command is stating what types of encryption it 97 will support. Only the side of the connection that is DO ENCRYPT 98 may send the SUPPORT command. The current types of encryption are 99 listed in the current version of the Assigned Numbers document[1]. 101 The encryption-type-list may only include types which can actually 102 be supported during the current session. If ENCRYPT is negotiated 103 in conjunction with AUTH the SUPPORT message MUST NOT be sent un- 104 til after the session has key has been determined. Otherwise, it 105 is impossible to know if the selected encryption type cab be prop- 106 erly initialized based upon the type and length of the key that is 107 available." 109 IAC SB ENCRYPT IS encryption-type ... IAC SE 111 The sender of this command is stating what type of encryption to 112 use, and any initial data that is needed. Only the side of the 113 connection that is WILL ENCRYPT may send the IS command. to ini- 114 tialize the encryption-type scheme. 116 IAC SB ENCRYPT REPLY encryption-type ... IAC SE 118 The sender of this command is continuing the initial data exchange 119 that is needed to initialize the encryption-type scheme. Only the 120 side of the connection that is DO ENCRYPT may send the REPLY com- 121 mand. 123 IAC SB ENCRYPT START keyid IAC SE 125 The sender of this command is stating that at this point in the 126 data stream, all following data will be encrypted, via the previ- 127 ously negotiated method of data encryption. Only the side of the 128 connection that is WILL ENCRYPT may send the START command. 130 The keyid is a variable length field. It is used by various en- 131 cryption mechanisms to identify which encryption key is to be 132 used, when multiple encryption keys might be known on either side 133 of the connection. The keyid field is encoded with the most sig- 134 nificant byte first, and a keyid value of zero is reserved to in- 135 dicate the default encryption key (this would typically be an en- 136 cryption key derived during authentication, with the AUTHENTICA- 137 TION option). The keyid field must be at least one byte long. 138 The only valid values for "keyid" will be those that have been re- 139 ceived in a DEC_KEYID command. 141 IAC SB ENCRYPT END IAC SE 143 The sender of this command is stating that at this point in the 144 data stream, all following data will no longer be encrypted. Only 145 the side of the connection that is WILL ENCRYPT may send the END 146 command. 148 IAC SB ENCRYPT REQUEST-START keyid IAC SE 150 The sender of this command requests that the remote side begin en- 151 cryption of the telnet data stream. Only the side of the connec- 152 tion that is DO ENCRYPT may send the REQUEST-START command. The 153 keyid is only advisory, and my be omitted. 155 IAC SB ENCRYPT REQUEST-END IAC SE 157 The sender of this command requests that the remote side stop en- 158 cryption of the telnet data stream. Only the side of the connec- 159 tion that is DO ENCRYPT may send the REQUEST-END command. 161 IAC SB ENCRYPT ENC_KEYID keyid IAC SE 163 The sender of this requests that the remote side verify that 164 "keyid" maps to a valid key on the remote side; or verifies that 165 the "keyid" received in a DEC_KEYID command is valid. If keyid is 166 omitted, it implies that there are no more known keyids, and that 167 the attempt to find a common keyid has failed. Only the side of 168 the connection that is WILL ENCRYPT may send the ENC_KEYID com- 169 mand. 171 IAC SB ENCRYPT DEC_KEYID keyid IAC SE 173 The sender of this requests that the remote side verify that 174 "keyid" maps to a valid key on the remote side; or verifies that 175 the "keyid" received in a ENC_KEYID command is valid. If keyid is 176 omitted, it implies that there are no more known keyids, and that 177 the attempt to find a common keyid has failed. Only the side of 178 the connection that is DO ENCRYPT may send the DEC_KEYID command. 180 3. Default Specification 182 The default specification for this option is 184 WONT ENCRYPT 185 DONT ENCRYPT 187 meaning there will not be any encryption of the Telnet data stream. 189 4. Motivation 191 The Telnet protocol has no form of protection from some intervening 192 gateway looking at IP packets as they travel through the network. 193 This is especially dangerous when passwords are sent as clear text 194 over the network. This option provides a method for encrypting the 195 data stream. 197 5. Implementation Rules 199 Once the Encryption option is in effect, all data in the negotiated 200 direction, including TELNET options, is encrypted. Encryption begins 201 with the octet of data immediately following the "IAC SB ENCRYPT 202 START encryption-type IAC SE" command. Encryption ends after the 203 "IAC SB ENCRYPT END IAC SE" command. 205 WILL and DO are used only at the beginning of the connection to ob- 206 tain and grant permission for future negotiations. The ENCRYPT op- 207 tion must be negotiated in both directions. 209 Once the two hosts have exchanged a WILL and a DO, the sender of the 210 DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side 211 know what types of encryption it is willing to accept. In the re- 212 quest, a list of supported encryption schemes is sent. Only the 213 sender of the DO may send a list of supported encryption types (IAC 214 SB ENCRYPT SUPPORT encryption-type-list IAC SE). Only the sender of 215 the WILL may actually transmit encrypted data. This is initiated via 216 the "IAC SB ENCRYPT START IAC SE" command, and terminated via the 217 "IAC SB ENCRYPT END IAC SE" command. If a START is received, and 218 then a second START is received before receiving an END, the second 219 START is ignored. 221 If the sender of the DO would like the remote side to begin sending 222 encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE" 223 command. If the sender of the DO would like the remote side to stop 224 sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP 225 IAC SE" command. 227 If the receiver of the SUPPORT command does not support any of the 228 encryption types listed in the SUPPORT command, it should send an 229 "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there is not a com- 230 mon encryption type. It may also send an IAC WONT ENCRYPT command to 231 turn off the ENCRYPT option. 233 The order of the encryption types in a SUPPORT command must be or- 234 dered to indicate a preference for different encryption types, the 235 first type being the most preferred, and the last type the least pre- 236 ferred. 238 If the ENCRYPT option has been enabled, and encrypted data is being 239 received, the receipt of an "IAC WONT ENCRYPT" implies the receipt of 240 an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream is no 241 longer encrypted. 243 The following is an example of use of the option: 244 Host1 Host2 246 [ Host1 requests Host2 negotiate to encrypt data that it sends to 247 Host1, and Host2 verifies that it will negotiate the encryption 248 of data that it sends to Host1. ] 249 DO ENCRYPT 250 WILL ENCRYPT 251 [ Host1 requests that Host2 enable encryption as soon as the 252 initialization is completed, and informs Host2 that is supports 253 DES_CFB64. ] 254 IAC SB ENCRYPT REQUEST-START IAC 255 SE 256 IAC SB ENCRYPT SUPPORT DES_CFB64 257 IAC SE 258 [ Host2 sends the initial feed to Host1, and Host1 acknowledges 259 receipt of the IV. ] 260 IAC SB ENCRYPT IS DES_CFB64 261 CFB64_IV 144 146 63 229 237 148 262 81 143 IAC SE 263 IAC SB ENCRYPT REPLY DES_CFB64 264 CFB64_IV_OK 103 207 181 71 224 265 55 229 98 IAC SE 266 [ Host2 is now free to start sending encrypted data, and since a 267 REQUEST-START was received, it enables encryption. ] 268 IAC SB ENCRYPT START IAC SE 269 [ All data from Host2 to Host1 is now encrypted. ] 270 IAC SB ENCRYPT END IAC SE 271 [ All data from Host2 to Host1 is now in clear text again. ] 273 It is expected that any implementation that supports the Telnet EN- 274 CRYPT option will support all of this specification. 276 6. Security Considerations 278 The ENCRYPT option used in isolation provides protection against pas- 279 sive attacks, but not against active attacks. In other words, it 280 will provide protection from someone who is just watching the IP 281 packets as they pass through the network. However, an attacker who 282 is able to modify packets in flight could prevent the ENCRYPT option 283 from being negotiated. 285 This flaw can be remedied by using the Telnet Authentication option 286 alongside the ENCRYPT option. Specifically, setting ENCRYPT_US- 287 ING_TELOPT in the authentication-type-pair can be used to force that 288 Encryption be negotiated even in the face of active attacks. 290 In addition, an active attacker can interfere with attempts to start 291 or restart encryption. If encryption is requested by the user, and 292 the client is unable to negotiate enabling or re-enabling encryption, 293 the client must assume that it is being attacked, and MUST immediate- 294 ly terminate the telnet connection. 296 7. Future directions for Telnet Encryption 298 The specification defines a method for providing data confidentiality 299 to the telnet data stream. Unfortunately all of the encryption mech- 300 anism provided under this option do not provide data integrity, be- 301 cause of the complexity of specifying a protocol which provided in- 302 tegrity services efficiently in a stream-oriented protocol. 304 The TELNET_OVER_TLS specification provides a scheme which provides 305 confidentiality, integrity, and compression, and future work for tel- 306 net encryption should closely examine using this specification. One 307 promising approach would use the anonymous Diffie-Hellman mode of 308 TLS, followed by the telnet AUTHENTICATION option where the authenti- 309 cation mechanism would include a signed hash of the Diffie-Hellman 310 keying material negotiated by the TLS layer. 312 8. Acknowledgments 314 This document was originally written by Dave Borman of Cray Research, 315 with the assistance of Theodore Ts'o of MIT and the IETF Telnet Work- 316 ing Group. 318 8. References 320 [1] Reynolds, Joyce, and Postel, Jon, "Telnet Protocol Specifica- 321 tion", RFC 854, May 1983. 322 [2] Internet Engineering Task Force, "Telnet Authentication", draft- 323 tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems, 324 September 1999. 325 [3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 326 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 328 Author's Address 330 Theodore Ts'o, Editor 331 VA Linux Systems 332 43 Pleasant St. 333 Medford, MA 02155 335 Phone: (781) 391-3464 337 EMail: tytso@mit.edu