rfc2945.txt

RFC 的详细文档！

Network Working Group                                              T. Wu
Request for Comments: 2945                           Stanford University
Category: Standards Track                                 September 2000


             The SRP Authentication and Key Exchange System

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 describes a cryptographically strong network
   authentication mechanism known as the Secure Remote Password (SRP)
   protocol.  This mechanism is suitable for negotiating secure
   connections using a user-supplied password, while eliminating the
   security problems traditionally associated with reusable passwords.
   This system also performs a secure key exchange in the process of
   authentication, allowing security layers (privacy and/or integrity
   protection) to be enabled during the session.  Trusted key servers
   and certificate infrastructures are not required, and clients are not
   required to store or manage any long-term keys.  SRP offers both
   security and deployment advantages over existing challenge-response
   techniques, making it an ideal drop-in replacement where secure
   password authentication is needed.

1. Introduction

   The lack of a secure authentication mechanism that is also easy to
   use has been a long-standing problem with the vast majority of
   Internet protocols currently in use.  The problem is two-fold: Users
   like to use passwords that they can remember, but most password-based
   authentication systems offer little protection against even passive
   attackers, especially if weak and easily-guessed passwords are used.

   Eavesdropping on a TCP/IP network can be carried out very easily and
   very effectively against protocols that transmit passwords in the
   clear.  Even so-called "challenge-response" techniques like the one
   described in [RFC 2095] and [RFC 1760], which are designed to defeat



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


   simple sniffing attacks, can be compromised by what is known as a
   "dictionary attack".  This occurs when an attacker captures the
   messages exchanged during a legitimate run of the protocol and uses
   that information to verify a series of guessed passwords taken from a
   precompiled "dictionary" of common passwords.  This works because
   users often choose simple, easy-to-remember passwords, which
   invariably are also easy to guess.

   Many existing mechanisms also require the password database on the
   host to be kept secret because the password P or some private hash
   h(P) is stored there and would compromise security if revealed.  That
   approach often degenerates into "security through obscurity" and goes
   against the UNIX convention of keeping a "public" password file whose
   contents can be revealed without destroying system security.

   SRP meets the strictest requirements laid down in [RFC 1704] for a
   non-disclosing authentication protocol.  It offers complete
   protection against both passive and active attacks, and accomplishes
   this efficiently using a single Diffie-Hellman-style round of
   computation, making it feasible to use in both interactive and non-
   interactive authentication for a wide range of Internet protocols.
   Since it retains its security when used with low-entropy passwords,
   it can be seamlessly integrated into existing user applications.

2. Conventions and Terminology

   The protocol described by this document is sometimes referred to as
   "SRP-3" for historical purposes.  This particular protocol is
   described in [SRP] and is believed to have very good logical and
   cryptographic resistance to both eavesdropping and active attacks.

   This document does not attempt to describe SRP in the context of any
   particular Internet protocol; instead it describes an abstract
   protocol that can be easily fitted to a particular application.  For
   example, the specific format of messages (including padding) is not
   specified.  Those issues have been left to the protocol implementor
   to decide.

   The one implementation issue worth specifying here is the mapping
   between strings and integers.  Internet protocols are byte-oriented,
   while SRP performs algebraic operations on its messages, so it is
   logical to define at least one method by which integers can be
   converted into a string of bytes and vice versa.

   An n-byte string S can be converted to an integer as follows:

   i = S[n-1] + 256 * S[n-2] + 256^2 * S[n-3] + ... + 256^(n-1) * S[0]




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


   where i is the integer and S[x] is the value of the x'th byte of S.
   In human terms, the string of bytes is the integer expressed in base
   256, with the most significant digit first.  When converting back to
   a string, S[0] must be non-zero (padding is considered to be a
   separate, independent process).  This conversion method is suitable
   for file storage, in-memory representation, and network transmission
   of large integer values.  Unless otherwise specified, this mapping
   will be assumed.

   If implementations require padding a string that represents an
   integer value, it is recommended that they use zero bytes and add
   them to the beginning of the string.  The conversion back to integer
   automatically discards leading zero bytes, making this padding scheme
   less prone to error.

   The SHA hash function, when used in this document, refers to the
   SHA-1 message digest algorithm described in [SHA1].

3. The SRP-SHA1 mechanism

   This section describes an implementation of the SRP authentication
   and key-exchange protocol that employs the SHA hash function to
   generate session keys and authentication proofs.

   The host stores user passwords as triplets of the form

        { <username>, <password verifier>, <salt> }

   Password entries are generated as follows:

        <salt> = random()
        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
        <password verifier> = v = g^x % N

   The | symbol indicates string concatenation, the ^ operator is the
   exponentiation operation, and the % operator is the integer remainder
   operation.  Most implementations perform the exponentiation and
   remainder in a single stage to avoid generating unwieldy intermediate
   results.  Note that the 160-bit output of SHA is implicitly converted
   to an integer before it is operated upon.

   Authentication is generally initiated by the client.

      Client                             Host
     --------                           ------
      U = <username>              -->
                                     <--    s = <salt from passwd file>




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


   Upon identifying himself to the host, the client will receive the
   salt stored on the host under his username.

      a = random()
      A = g^a % N                 -->
                                         v = <stored password verifier>
                                         b = random()
                                  <--    B = (v + g^b) % N

      p = <raw password>
      x = SHA(s | SHA(U | ":" | p))

      S = (B - g^x) ^ (a + u * x) % N    S = (A * v^u) ^ b % N
      K = SHA_Interleave(S)              K = SHA_Interleave(S)
      (this function is described
       in the next section)

   The client generates a random number, raises g to that power modulo
   the field prime, and sends the result to the host.  The host does the
   same thing and also adds the public verifier before sending it to the
   client.  Both sides then construct the shared session key based on
   the respective formulae.

   The parameter u is a 32-bit unsigned integer which takes its value
   from the first 32 bits of the SHA1 hash of B, MSB first.

   The client MUST abort authentication if B % N is zero.

   The host MUST abort the authentication attempt if A % N is zero.  The
   host MUST send B after receiving A from the client, never before.

   At this point, the client and server should have a common session key
   that is secure (i.e. not known to an outside party).  To finish
   authentication, they must prove to each other that their keys are
   identical.

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

   The server will calculate M using its own K and compare it against
   the client's response.  If they do not match, the server MUST abort
   and signal an error before it attempts to answer the client's
   challenge.  Not doing so could compromise the security of the user's
   password.






Wu                          Standards Track                     [Page 4]