TELNET Authentication Using DSA(4)

　　CertData ::= SEQUENCE {

　　certPath [0] CertificationPath } -- see X.509

　　EntityName ::= SEQUENCE OF CHOICE { -- only allow one!

　　directoryName [4] Name } -- see X.501

　　RandomNumber ::= INTEGER -- 20 octets

　　TokenId ::= SEQUENCE {

　　tokenType INTEGER, -- see table below

　　protoVerNo INTEGER } -- always 0x0001

　　TimeStamp ::= GeneralizedTime

　　The TokenId.TokenType is used to distinguish the message type and the　authentication type (either unilateral or mutual). The following　table provides the values needed to implement this specification:

　　Message Type Authentication Type TokenId.TokenType

　　MessageBA Unilateral 0x0001

　　Mutual 0x0011

　　MessageAB Unilateral 0x0002

　　Mutual 0x0012

　　MessageBA Mutual 0x0013

　　5. Security Considerations

　　This entire memo is about security mechanisms. For DSA to provide　the authentication discussed, the implementation must protect the　private key from disclosure.

　　Implementations must randomly generate DSS private keys, 'k' values　used in DSS signatures, and nonces. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic values can　result in little or no security. An attacker may find it much easier　to reproduce the PRNG environment that produced the values, searching　the resulting small set of possibilities, rather than using a brute　force search. The generation of quality random numbers is difficult.

    　RFC1750[RFC1750] offers important guidance in this area, and　Appendix 3 of FIPS PUB 186 [FIPS186] provides one quality PRNG　technique.

　　6. Acknowledgements

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

　　7. IANA Considerations

　　The authentication type DSS and its 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.

　　8. References

　　FIPS180-1 Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.

　　FIPS186 Digital Signature Standard (DSS). FIPS Pub 186. May 19,

　　1994.

　　FIPS196 Standard for Entity Authentication Using Public Key

　　Cryptography. FIPS Pub 196. February 18, 1997.

　　RFC1750Eastlake, 3rd, D., Crocker, S. and J. Schiller, "Randomness

　　Recommendations for Security", RFC1750, December 1994.

　　RFC2459Housley, R., Ford, W., Polk, W. and D. Solo, "Internet

　　X.509 Public Key Infrastructure: X.509 Certificate and CRL

　　Profile", RFC2459, January 1999.

　　RFC2941T'so, T. and J. Altman, "Telnet Authentication Option", RFC

　　2941, September 2000.

　　X.208 CCITT. Recommendation X.208: Specification of Abstract

　　Syntax Notation One (ASN.1). 1988.

　　X.501 CCITT. Recommendation X.501: The Directory - Models. 1988.

　　X.509 CCITT. Recommendation X.509: The Directory -

　　Authentication Framework. 1988.

　　9. Authors' Addresses

　　Russell Housley

　　SPYRUS

　　381 Elden Street, Suite 1120

　　Herndon, VA 20172

　　USA

　　EMail: housley@spyrus.com

　　Todd Horting

　　SPYRUS

　　381 Elden Street, Suite 1120

　　Herndon, VA 20172

　　USA

　　EMail: thorting@spyrus.com

　　Peter Yee

　　SPYRUS

　　5303 Betsy Ross Drive

　　Santa Clara, CA 95054

　　USA

　　EMail: yee@spyrus.com

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