summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2946.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2946.txt')
-rw-r--r--doc/rfc/rfc2946.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2946.txt b/doc/rfc/rfc2946.txt
new file mode 100644
index 0000000..03e1437
--- /dev/null
+++ b/doc/rfc/rfc2946.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+
+
+Ts'o Standards Track [Page 1]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+ 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,
+
+
+
+Ts'o Standards Track [Page 2]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+ 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.
+
+
+
+
+Ts'o Standards Track [Page 3]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+ 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.
+
+
+
+Ts'o Standards Track [Page 4]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ts'o Standards Track [Page 5]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+ 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.
+
+
+
+Ts'o Standards Track [Page 6]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+ 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
+
+
+
+Ts'o Standards Track [Page 7]
+
+RFC 2946 Telnet Data Encryption Option September 2000
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ts'o Standards Track [Page 8]
+