DES 64 bit Cipher Feedback(2)

　　As noted in the telnet ENCRYPTION option specifications, a keyid　value of zero indicates the default encryption key, as might be　derived from the telnet AUTHENTICATION option. If the default　encryption key negotiated as a result of the telnet AUTHENTICATION　option contains less than 8 bytes, then the DES_CFB64 option must not　be offered or used as a valid telnet encryption option. If the　encryption key negotiated as a result of the telnet UTHENTICATION　option is greater than 16 bytes the first 8 bytes of the key should　be used as keyid 0 for data sent from the telnet client to the telnet　server, and the second 8 bytes of the key should be used as keyid 0　for data sent by the telnet server to the telnet client. Otherwise,　the first 8 bytes of the encryption key is used as keyid zero for the　telnet ENCRYPTION option in both directions (with the client as WILL　ENCRYPT and the server as WILL ENCRYPT).

　　In all cases, if the key negotiated by the telnet AUTHENTICATION　option was not a DES key, the key used by the DES_CFB64 must have its　parity corrected after it is 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 Cipher Feedback does not ensure data integrity; the　active attacker has a limited ability to modify text, if he can　predict the clear-text that was being transmitted. The limitations　faced by the attacker (that only 8 bytes can be modified at a time,　and the following 8-byte block of data will be corrupted, thus making　detection likely) are significant, but it is possible that an active　attacker still might be able to exploit this weakness.

　　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.

　　7. Acknowledgments

　　This document was originally written by Dave Borman of Cray Research　with the assistance of the IETF Telnet Working Group.

　　Author's Address

　　Theodore Ts'o, Editor

　　VA Linux Systems

　　43 Pleasant St.

　　Medford, MA 02155

　　Phone: (781) 391-3464

　　EMail: tytso@mit.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.