rfc2946.txt

RFC 的详细文档！


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: [phone]
   EMail: [e-mail]



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]