Telnet Authentication: SRP(2)

　　IAC SB AUTHENTICATION SEND

　　SRP CLIENT|ONE_WAY|

　　ENCRYPT_USING_TELOPT

　　SRP CLIENT|ONE_WAY

　　IAC SE

　　[ The server has requested SRP authentication. It has indicated　a preference for ENCRYPT_USING_TELOPT, which requires the　Telnet ENCRYPT option to be negotiated once authentication　succeeds. If the client does not support this, the server　is willing to fall back to an encryption-optional mode.　The client will now respond with the name of the　user that it wants to log in as. ]

　　IAC SB AUTHENTICATION NAME

　　"tjw" IAC SE

　　IAC SB AUTHENTICATION IS

　　SRP CLIENT|ONE_WAY|ENCRYPT_USING_TELOPT AUTH

　　IAC SE

　　[ The server looks up the appropriate information for "tjw" and　sends back the parameters in a PARAMS command. The parameters　consist of the values N, g, and s, each preceded with a two-byte size parameter. ]

　　IAC SB AUTHENTICATION REPLY

　　SRP CLIENT|ONE_WAY|

　　ENCRYPT_USING_TELOPT PARAMS

　　ss ss nn nn nn nn ...

　　ss ss gg gg gg gg ...

　　ss ss tt tt tt tt ...

　　IAC SE

　　[ Both sides send their exponential residues. The client　sends its value A and the server sends its value B. In SRP,　the CHALLENGE message may be computed but not sent before　the EXP command. ]

　　IAC SB AUTHENTICATION IS

　　SRP CLIENT|ONE_WAY|ENCRYPT_USING_TELOPT EXP

　　aa aa aa aa aa aa aa aa ...

　　IAC SE

　　IAC SB AUTHENTICATION REPLY

　　SRP CLIENT|ONE_WAY|

　　ENCRYPT_USING_TELOPT CHALLENGE

　　bb bb bb bb bb bb bb bb ...

　　IAC SE

　　[ The client sends its response to the server. This is the　message M in the SRP protocol, which proves possession of　the session key by the client.　Since ENCRYPT_USING_TELOPT is specified, the two octets　of the authentication-type-pair are appended to the　session key K before the hash for M is computed. If　the client and server had agreed upon a mode without　the encryption flag set, nothing would be appended to K.　Both this message and the server's response are as long as　the output of the hash; the length is 20 bytes for SHA-1. ]

　　IAC SB AUTHENTICATION IS

　　SRP CLIENT|ONE_WAY|ENCRYPT_USING_TELOPT RESPONSE

　　xx xx xx xx xx xx xx xx ...

　　IAC SE

　　[ The server accepts the response and sends its own proof. ]

　　IAC SB AUTHENTICATION REPLY

　　SRP CLIENT|ONE_WAY|

　　ENCRYPT_USING_TELOPT ACCEPT

　　yy yy yy yy yy yy yy yy ...

　　IAC SE

　　5. Security Considerations

　　The ability to negotiate a common authentication mechanism between　client and server is a feature of the authentication option that　should be used with caution. When the negotiation is performed, no　authentication has yet occurred. Therefore, each system has no way　of knowing whether or not it is talking to the system it intends. An　intruder could attempt to negotiate the use of an authentication　system which is either weak, or already compromised by the intruder.

　　Since SRP relies on the security of the underlying public-key　cryptosystem, the modulus "n" should be large enough to resist　brute-force attack. A length of at least 1024 bits is recommended,　and implementations should reject attempts to use moduli that are　shorter than 512 bits, or attempts to use invalid moduli and　generator parameters (non-safe-prime "n" or non-primitive "g").

　　6. IANA Considerations

　　The authentication type SRP 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.

　　7. References

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

　　RFC2941, September 2000.

　　[SRP] T. Wu, "The Secure Remote Password Protocol", In

　　Proceedings of the 1998 ISOC Network and Distributed

　　System Security Symposium, SanDiego, CA, pp. 97-111.

　　[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",

　　RFC2945, September 2000.

　　8. Author's Address

　　Thomas Wu

　　Stanford University

　　Stanford, CA 94305

　　EMail: tjw@cs.Stanford.EDU

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