rfc2945.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2945        SRP Authentication & Key Exchange System  September 2000


   If the server receives a correct response, it issues its own proof to
   the client.  The client will compute the expected response using its
   own K to verify the authenticity of the server.  If the client
   responded correctly, the server MUST respond with its hash value.

   The transactions in this protocol description do not necessarily have
   a one-to-one correspondence with actual protocol messages.  This
   description is only intended to illustrate the relationships between
   the different parameters and how they are computed.  It is possible,
   for example, for an implementation of the SRP-SHA1 mechanism to
   consolidate some of the flows as follows:

        Client                             Host
       --------                           ------
        U, A                        -->
                                    <--    s, B
        H(H(N) XOR H(g) | H(U) | s | A | B | K)
                                    -->
                                    <--    H(A | M | K)

   The values of N and g used in this protocol must be agreed upon by
   the two parties in question.  They can be set in advance, or the host
   can supply them to the client.  In the latter case, the host should
   send the parameters in the first message along with the salt.  For
   maximum security, N should be a safe prime (i.e. a number of the form
   N = 2q + 1, where q is also prime).  Also, g should be a generator
   modulo N (see [SRP] for details), which means that for any X where 0
   < X < N, there exists a value x for which g^x % N == X.

3.1.  Interleaved SHA

   The SHA_Interleave function used in SRP-SHA1 is used to generate a
   session key that is twice as long as the 160-bit output of SHA1.  To
   compute this function, remove all leading zero bytes from the input.
   If the length of the resulting string is odd, also remove the first
   byte.  Call the resulting string T.  Extract the even-numbered bytes
   into a string E and the odd-numbered bytes into a string F, i.e.

     E = T[0] | T[2] | T[4] | ...
     F = T[1] | T[3] | T[5] | ...

   Both E and F should be exactly half the length of T.  Hash each one
   with regular SHA1, i.e.

     G = SHA(E)
     H = SHA(F)





Wu                          Standards Track                     [Page 5]

RFC 2945        SRP Authentication & Key Exchange System  September 2000


   Interleave the two hashes back together to form the output, i.e.

     result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19]

   The result will be 40 bytes (320 bits) long.

3.2.  Other Hash Algorithms

   SRP can be used with hash functions other than SHA.  If the hash
   function produces an output of a different length than SHA (20
   bytes), it may change the length of some of the messages in the
   protocol, but the fundamental operation will be unaffected.

   Earlier versions of the SRP mechanism used the MD5 hash function,
   described in [RFC 1321].  Keyed hash transforms are also recommended
   for use with SRP; one possible construction uses HMAC [RFC 2104],
   using K to key the hash in each direction instead of concatenating it
   with the other parameters.

   Any hash function used with SRP should produce an output of at least
   16 bytes and have the property that small changes in the input cause
   significant nonlinear changes in the output.  [SRP] covers these
   issues in more depth.

4. Security Considerations

   This entire memo discusses an authentication and key-exchange system
   that protects passwords and exchanges keys across an untrusted
   network.  This system improves security by eliminating the need to
   send cleartext passwords over the network and by enabling encryption
   through its secure key-exchange mechanism.

   The private values for a and b correspond roughly to the private
   values in a Diffie-Hellman exchange and have similar constraints of
   length and entropy.  Implementations may choose to increase the
   length of the parameter u, as long as both client and server agree,
   but it is not recommended that it be shorter than 32 bits.

   SRP has been designed not only to counter the threat of casual
   password-sniffing, but also to prevent a determined attacker equipped
   with a dictionary of passwords from guessing at passwords using
   captured network traffic.  The SRP protocol itself also resists
   active network attacks, and implementations can use the securely
   exchanged keys to protect the session against hijacking and provide
   confidentiality.






Wu                          Standards Track                     [Page 6]

RFC 2945        SRP Authentication & Key Exchange System  September 2000


   SRP also has the added advantage of permitting the host to store
   passwords in a form that is not directly useful to an attacker.  Even
   if the host's password database were publicly revealed, the attacker
   would still need an expensive dictionary search to obtain any
   passwords.  The exponential computation required to validate a guess
   in this case is much more time-consuming than the hash currently used
   by most UNIX systems.  Hosts are still advised, though, to try their
   best to keep their password files secure.

5. References

   [RFC 1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

   [RFC 1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
               RFC 1704, October 1994.

   [RFC 1760]  Haller, N., "The S/Key One-Time Password System", RFC
               1760, Feburary 1995.

   [RFC 2095]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
               AUTHorize Extension for Simple Challenge/Response", RFC
               2095, January 1997.

   [RFC 2104]  Krawczyk, H., Bellare, M. and  R. Canetti, "HMAC: Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

   [SHA1]      National Institute of Standards and Technology (NIST),
               "Announcing the Secure Hash Standard", FIPS 180-1, U.S.
               Department of Commerce, April 1995.

   [SRP]       T. Wu, "The Secure Remote Password Protocol", In
               Proceedings of the 1998 Internet Society Symposium on
               Network and Distributed Systems Security, San Diego, CA,
               pp. 97-111.

6. Author's Address

   Thomas Wu
   Stanford University
   Stanford, CA 94305

   EMail: [e-mail]







Wu                          Standards Track                     [Page 7]

RFC 2945        SRP Authentication & Key Exchange System  September 2000


7.  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 8]