TELNET Authentication Using KEA and SKIPJACK(3)

　　<-- IAC SB AUTHENTICATION REPLY

KEA_SJ_INTEG

AUTH_CLIENT_TO_SERVER |

AUTH_HOW_MUTUAL |

ENCRYPT_AFTER_EXCHANGE |

INI_CRED_FWD_OFF

KEA_RESPONSEA

Encrypt( NonceA XOR 0x0D12 )

IAC SE

<　　KEA_SJ_INTEG

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_MUTUAL |

　　ENCRYPT_AFTER_EXCHANGE |

　　INI_CRED_FWD_OFF

　　KEA_RESPONSEA

　　Encrypt( NonceA XOR 0x0D12 )

　　IAC SE

　　---------------------------------------------------------------------

　　Figure 2

　　4.0. Security Considerations

　　This entire memo is about security mechanisms. For KEA to provide　the authentication discussed, the implementation must protect the　private key from disclosure. Likewise, the SKIPJACK keys must be　protected from disclosure.

　　Implementations must randomly generate KEA private keys,　initialization vectors (IVs), and nonces. The use of inadequate　pseudo-random number generators (PRNGs) to generate cryptographic　keys can result in little or no security. An attacker may find it　much easier to reproduce the PRNG environment that produced the keys,　searching the resulting small set of possibilities, rather than brute　force searching the whole key space. The generation of quality　random numbers is difficult. RFC1750[8] offers important guidance　in this area, and Appendix 3 of FIPS Pub 186 [9] provides one quality　PRNG technique.

　　By linking the enabling of encryption as a side effect of successful　authentication, protection is provided against an active attacker.

　　If encryption were enabled as a separate negotiation, it would　provide a window of vulnerability from when the authentication　completes, up to and including the negotiation to turn on encryption.

　　The only safe way to restart encryption, if it is turned off, is to repeat the entire authentication process.

　　5. IANA Considerations

　　The authentication types KEA_SJ and KEA_SJ_INTEG and their associated　suboption values are registered with IANA. Any suboption values used　to extend the protocol as described in this document must be　registered with IANA before use. IANA is instructed not to issue new　suboption values without submission of documentation of their use.

　　6.0. Acknowledgements

　　We would like to thank William Nace for support during implementation　of this specification.

　　7.0. References

　　[1] Postel, J. and J. Reynolds, "TELNET Protocol Specification", ASTD　8, RFC854, May 1983.

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

　　[3] Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.

　　[4] "SKIPJACK and KEA Algorithm Specification", Version 2.0, May 29,　1998. Available from http://csrc.nist.gov/encryption/skipjack-kea.htm

　　[5] Postel, J. and J. Reynolds, "TELNET Option Specifications", STD　8, RFC855, May 1983.

　　[6] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509　Public Key Infrastructure: X.509 Certificate and CRL Profile",　RFC2459, January 1999.

　　[7] Housley, R. and W. Polk, "Internet X.509 Public Key　Infrastructure - Representation of Key Exchange Algorithm (KEA)　Keys in Internet X.509 Public Key Infrastructure Certificates",　RFC2528, March 1999.

　　[8] Eastlake, D., Crocker, S. and J. Schiller, "Randomness　Recommendations for Security", RFC1750, December 1994.

　　[9) National Institute of Standards and Technology. FIPS Pub 186:　Digital Signature Standard. 19 May 1994.

　　8.0. Authors' Addresses

　　Russell Housley

　　SPYRUS

　　381 Elden Street, Suite 1120

　　Herndon, VA 20170

　　USA

　　EMail: housley@spyrus.com

　　Todd Horting

　　SPYRUS

　　381 Elden Street, Suite 1120

　　Herndon, VA 20170

　　USA

　　EMail: thorting@spyrus.com

　　Peter Yee

　　SPYRUS

　　5303 Betsy Ross Drive

　　Santa Clara, CA 95054

　　USA

　　EMail: yee@spyrus.com

　　9. 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.