DES3 64 bit Output Feedback(2)

　　When two keys are available:

　. data sent from the server is encrypted with key1, decrypted with　key2, and encrypted with key1;

　　. data sent from the client is encrypted with key2, decrypted with　key1, and encrypted with key2

　　When three keys are available:

　　. data sent from the server is encrypted with key1, decrypted with　key2, and encrypted with key3;

　　. data sent from the client is encrypted with key2, decrypted with　key3, and encrypted with key1

　　When four keys are available:

　　. data sent from the server is encrypted with key1, decrypted with　key2, and encrypted with key3;

　　. data sent from the client is encrypted with key2, decrypted with　key4, and encrypted with key1

　　When five keys are available:

　　. data sent from the server is encrypted with key1, decrypted with　key2, and encrypted with key3;

　　. data sent from the client is encrypted with key2, decrypted with　key4, and encrypted with key5

　　When six keys are available:

　　. data sent from the server is encrypted with key1, decrypted with　key2, and encrypted with key3;

　　. data sent from the client is encrypted with key4, decrypted with　key5, and encrypted with key6

　　In all cases, the keys used by DES3_OFB64 must have their parity　corrected after they are determined using the above algorithm.

　　Note that the above algorithm assumes that it is safe to use a non-DES key (or part of a non-DES key) as a DES key. This is not　necessarily true of all cipher systems, but we specify this behaviour　as the default since it is true for most authentication systems in　popular use today, and for compatibility with existing

　　implementations. New telnet AUTHENTICATION mechanisms may specify　alternative methods for determining the keys to be used for this　cipher suite in their specification, if the session key negotiated by　that authentication mechanism is not a DES key and and where this　algorithm may not be safely used.

　　6. Security Considerations

　　Encryption using Output Feedback does not ensure data integrity; an　active attacker may be able to substitute text, if he can predict the　clear-text that was being transmitted.

　　The tradeoff here is that adding a message authentication code (MAC)　will significantly increase the number of bytes needed to send a　single character in the telnet protocol, which will impact　performance on slow (i.e. dialup) links.

　　This option was originally drafted back when CPUspeeds where not　necessarily fast enough to do allow use of CFB. Since then, CPU's　have gotten much faster. Given the inherent weaknesses in Output　Feedback mode, perhaps it should be deprecated in favor of CFB modes?

　　7. Acknowledgments

　　This document was based on the "Telnet Encryption: DES 64 bit Output　Feedback" document originally written by Dave Borman of Cray Research　with the assistance of the IETF Telnet Working Group.

　　Author's Address

   　Jeffrey Altman, Editor

　　Columbia University

　　612 West 115th Street Room 716

　　New York NY 10025 USA

　　Phone: +1 (212) 854-1344

　　EMail: jaltman@columbia.edu

　　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.