DES 64 bit Output Feedback(2)

　　V[0] = DES(V[i], key)

　　V[n+1] = DES(V[n], key)

　　O[n] = D[n] V[n]

　　5. Integration with the AUTHENTICATION telnet option

   　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 AUTHENTICATIONoption contains less than 8 bytes, then the DES_OFB64 option may not　be offered or used as a valid telnet encryption option. If the　encryption key negotiated as a result of the telnet AUTHENTICATION　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 server to the telnet　client, and the second 8 bytes of the key should be used as keyid 0　for data sent by the telnet client to the telnet server. 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 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. For this reason, the Cipher　Feedback encryption type should be used instead, since it provides　limited detectability to data modification. Neither provides true　data integrity, however.

　　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.