Telnet Data Encryption Option(3)

　　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.

　　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, RFC854, May 1983.

　　[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC2941,

　　September 2000.

　　[3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA

　　Considerations Section in RFCs", BCP 26, RFC2434, 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

　　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 RFCEditor function is currently provided by the　Internet Society.