doc: Add RFC documents

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]
+