CAST-128 64 bit Output 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 16 (5) bytes, then the CAST128_OFB64　(CAST5_40_OFB64) option must not be offered or used as a valid telnet　encryption option.

　　If there are less than 32 (10) bytes of key data, the first 16 (5)　bytes of key data are used as keyid 0 in each direction. If there　are at least 32 (10) bytes of key data, the first 16 (5) bytes of key　data are used to encrypt the data sent by the telnet client to the　telnet server; the second 16 (5) bytes of key data are used to　encrypt the data sent by the telnet server to the telnet client.

　　Any extra key data is used as random data to be sent as an　initialization vector.

　　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?

　　Encryption modes using 40-bit keys are not to be considered secure.

　　The 40 bit key mode CAST5_40_OFB64 is listed here simply to document　the implementations that are already prevalent on the Internet but　have never been documented.

　　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.

　　8. References

　　[1] Adams, C., "The CAST-128 Encryption Algorithm", RFC2144, May

　　1997.

　　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.