doc: Add RFC documents

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]
+