RFC 2945 (rfc2945) - Page 2 of 8

The SRP Authentication and Key Exchange System

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