summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2944.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2944.txt')
-rw-r--r--doc/rfc/rfc2944.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2944.txt b/doc/rfc/rfc2944.txt
new file mode 100644
index 0000000..afa1f2e
--- /dev/null
+++ b/doc/rfc/rfc2944.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group T. Wu
+Request for Comments: 2944 Standford University
+Category: Standards Track September 2000
+
+
+ Telnet Authentication: SRP
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document specifies an authentication scheme for the Telnet
+ protocol under the framework described in [RFC2941], using the Secure
+ Remote Password Protocol (SRP) authentication mechanism. The
+ specific mechanism, SRP-SHA1, is described in [RFC2945].
+
+1. Command Names and Codes
+
+ Authentication Types
+
+ SRP 5
+
+ Suboption Commands
+
+ AUTH 0
+ REJECT 1
+ ACCEPT 2
+ CHALLENGE 3
+ RESPONSE 4
+
+ EXP 8
+ PARAMS 9
+
+
+
+
+
+
+
+
+
+Wu Standards Track [Page 1]
+
+RFC 2944 Telnet Authentication: SRP September 2000
+
+
+2. Command Meanings
+
+ IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH IAC SE
+
+ This command indicates that the client has supplied the
+ username and is ready to receive that user's field parameters.
+ There is no authentication information to be sent to the remote
+ side of the connection yet. This should only be sent after the
+ IAC SB AUTHENTICATION NAME command has been issued. If the
+ modifier byte (second byte of the authentication-type-pair)
+ has any bits other than AUTH_WHO_MASK or AUTH_HOW_MASK set,
+ both bytes are included in the session key hash described later.
+ This ensures that the authentication type pair was correctly
+ negotiated, while maintaining backward-compatibility with existing
+ software.
+
+ IAC SB AUTHENTICATION REPLY <authentication-type-pair> PARAMS <values
+ of modulus, generator, and salt> IAC SE
+
+ This command is used to pass the three parameter values used
+ in the exponentiation to the client. These values are often
+ called n, g, and s.
+
+ IAC SB AUTHENTICATION IS <authentication-type-pair> EXP <client's
+ exponential residue> IAC SE
+
+ This command is used to pass the client's exponential residue,
+ otherwise known as A, computed against the parameters exchanged
+ earlier.
+
+ IAC SB AUTHENTICATION REPLY <authentication-type-pair> CHALLENGE
+ <server's exponential residue> IAC SE
+
+ This command is used to pass the server's exponential residue,
+ computed against the same parameters. This quantity is actually
+ the sum of two residues, i.e. g^x + g^b. For details see [SRP]
+ and [RFC2945].
+
+ IAC SB AUTHENTICATION IS <authentication-type-pair> RESPONSE
+ <response from client> IAC SE
+
+ This command gives the server proof of the client's authenticity
+ with a 160-bit (20 byte) response.
+
+
+
+
+
+
+
+
+Wu Standards Track [Page 2]
+
+RFC 2944 Telnet Authentication: SRP September 2000
+
+
+ IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
+ <server's response> IAC SE
+
+ This command indicates that the authentication was successful.
+ The server will construct its own proof of authenticity and
+ include it as sub-option data.
+
+ IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
+ <optional reason for rejection> IAC SE
+
+ This command indicates that the authentication was not successful,
+ and if there is any more data in the sub-option, it is an ASCII
+ text message of the reason for the rejection.
+
+ For the PARAMS command, since three pieces of data are being
+ transmitted, each parameter is preceded by a 16-bit (two byte) length
+ specifier in network byte order. The EXP commands do not have a
+ count in front of the data because there is only one piece of data in
+ that suboption. The CHALLENGE, RESPONSE, and ACCEPT data also do not
+ have a count because they are all fixed in size.
+
+3. Implementation Rules
+
+ Currently, only AUTH_CLIENT_TO_SERVER mode is supported. Although
+ the SRP protocol effectively performs implicit mutual authentication
+ as a result of the two-way proofs, only the AUTH_HOW_ONE_WAY
+ authentication mode is currently defined. The AUTH_HOW_MUTUAL
+ setting is being reserved for an explicit mutual-authentication
+ variant of the SRP protocol to be defined in future specifications.
+
+ All large number data sent in the arguments of the PARAMS and EXP
+ commands must be in network byte order, i.e. most significant byte
+ first. No padding is used.
+
+ The SRP-SHA1 mechanism, as described in [RFC2945] generates a 40-byte
+ session key, which allows implementations to use different keys for
+ incoming and outgoing traffic, increasing the security of the
+ encrypted session. It is recommended that the Telnet ENCRYPT method,
+ if it is used, be able to take advantage of the longer session keys.
+
+4. Examples
+
+ User "tjw" may wish to log in on machine "foo". The client would
+ send IAC SB AUTHENTICATION NAME "tjw" IAC SE IAC SB AUTHENTICATION IS
+ SRP AUTH IAC SE. The server would look up the field and salt
+ parameters for "tjw" from its password file and send them back to the
+ client. Client and server would then exchange exponential residues
+ and calculate their session keys (after the client prompted "tjw" for
+
+
+
+Wu Standards Track [Page 3]
+
+RFC 2944 Telnet Authentication: SRP September 2000
+
+
+ his password). Then, the client would send the server its proof that
+ it knows the session key. The server would either send back an
+ ACCEPT or a REJECT. If the server accepts authentication, it also
+ sends its own proof that it knows the session key to the client.
+
+ Client Server
+ IAC DO AUTHENTICATION
+ IAC WILL AUTHENTICATION
+
+ [ The server is now free to request authentication information.
+ ]
+ 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
+
+
+
+
+
+
+
+Wu Standards Track [Page 4]
+
+RFC 2944 Telnet Authentication: SRP September 2000
+
+
+ [ 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
+
+
+
+
+
+
+
+
+
+
+
+Wu Standards Track [Page 5]
+
+RFC 2944 Telnet Authentication: SRP September 2000
+
+
+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",
+ RFC 2941, September 2000.
+
+ [SRP] T. Wu, "The Secure Remote Password Protocol", In
+ Proceedings of the 1998 ISOC Network and Distributed
+ System Security Symposium, San Diego, CA, pp. 97-111.
+
+ [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
+ RFC 2945, September 2000.
+
+8. Author's Address
+
+ Thomas Wu
+ Stanford University
+ Stanford, CA 94305
+
+ EMail: tjw@cs.Stanford.EDU
+
+
+
+
+
+
+
+Wu Standards Track [Page 6]
+
+RFC 2944 Telnet Authentication: SRP September 2000
+
+
+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 RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu Standards Track [Page 7]
+