[8875] in bugtraq
SRP
daemon@ATHENA.MIT.EDU (Pete Gonzalez)
Thu Dec 31 13:47:26 1998
Date: Wed, 30 Dec 1998 13:14:55 -0500
Reply-To: Pete Gonzalez <gonz@JEFFERSON.ML.ORG>
From: Pete Gonzalez <gonz@JEFFERSON.ML.ORG>
To: BUGTRAQ@NETSPACE.ORG
There is a secure protocol called "SRP" developed by some folks at
Stanford. Their web page (http://srp.stanford.edu/srp) speaks very
positively about this protocol, citing some seemingly significant
advantages over ssh and kerberos. But other than the information on their
web page, I've found very little mention of it anywhere on the net, even
though SRP has been in active use on the Stanford campus since summer
of 1997.
Has anyone used SRP? Is there some fatal flaw which is preventing its
widespread acceptance?
Pete Gonzalez
Jefferson Systems
gonz@jefferson.ml.org
P.S. I've attached some relevant text, since their web server currently
seems to be down...
-----------------------------------------------------------------------------
Abstract from the original proposal
-----------------------------------------------------------------------------
This paper presents a new password authentication and key-exchange
protocol suitable for authenticating users and exchanging keys over an
untrusted network. The new protocol resists dictionary attacks mounted by
either passive or active network intruders, allowing, in principle, even
weak passphrases to be used safely. It also offers perfect forward
secrecy, which protects past sessions and passwords against future
compromises. Finally, user passwords are stored in a form that is not
plaintext-equivalent to the password itself, so an attacker who captures
the password database cannot use it directly to compromise security and
gain immediate access to the host. This new protocol combines techniques
of zero-knowledge proofs with asymmetric key exchange protocols and offers
significantly improved performance over comparably strong extended methods
that resist stolen-verifier attacks such as Augmented EKE or B-SPEKE.
-----------------------------------------------------------------------------
http://srp.stanford.edu/srp/advantages.html
-----------------------------------------------------------------------------
Advantages and Benefits of SRP
Although SRP's main claim to fame is its improved security relative to
existing password authentication mechanisms, SRP actually offers
advantages in several other areas as well. First, though, we discuss
the security implications.
_________________________________________________________________
Security Advantages
In a nutshell, here are some of the properties that make SRP a strong
authentication protocol:
1. SRP is safe against snooping. The password is never passed over
the network, either in the clear or encrypted.
2. SRP is immune to replay attacks. None of the information exchanged
during authentication can be re-used to gain access to a server
using SRP.
3. SRP exchanges a session key in the process of authentication. This
key can be used to encrypt the user's login session and protect it
from both snooping and malicious active attack.
4. SRP can provide mutual authentication. This requires both sides to
keep their secrets secure, obviously.
5. SRP resists the dreaded off-line dictionary attack based on
exchanged messages. The traffic exchanged over the network is
insufficient to verify a guess of a user's password.
6. SRP offers perfect forward secrecy. A compromised password will
not allow an intruder to decrypt past sessions. A compromised
session key will not allow an intruder to find out a password.
This includes resistance to the infamous Denning-Sacco attack; a
compromised session key will not permit an attacker to mount a
dictionary attack against the password.
7. SRP can tolerate a compromise of the verifier database on the
host. Although such a compromise may enable some attacks against
the system (dictionary attack, host impersonation), it is not
necessarily catastrophic, because the password entries can only be
used for verification of a user's password (i.e. they are not
plaintext-equivalent to the actual passwords). They can not be
used by an intruder to gain direct access to a host.
The last three issues are what I call the "Big-3" of password
authentication, and they are discussed in greater detail on a
[1]separate page. They are, as a rule, difficult constraints to
satisfy. If one considers only protocols that resist dictionary
attacks (the first constraint), one is left with the EKE family of
protocols and a few other public-key assisted protocols. If one also
requires perfect forward secrecy, that leaves only the strongest of
the EKE family protocols, like DH-EKE and SPEKE. When one throws in
the final requirement for non plaintext-equivalence, one is left
finally with the null set.
Until now, that is. SRP has been demonstrated to satisfy all three of
the "Big-3" requirements. To date, protocols that satisfy even two of
the three requirements are considered rare, especially if
non-plaintext-equivalence is one of the two. SRP's security advantages
make it uniquely suited for use in a wide variety of environments,
especially those where vulnerability to any one of the "Big-3" attacks
would have been problematic.
In a nutshell, SRP-3 is the "right" way to do password authentication.
All other known direct authentication mechanisms are demonstratably
inferior to it, either by being less secure, less convenient, or
slower. It gives the maximum possible security obtainable with a
simple password, and it can be easily layered on top of other security
services to create a more bulletproof security model.
_________________________________________________________________
Technical Advantages
Aside from purely security-related benefits, SRP has a number of
technical and practical advantages that make it an versatile protocol.
1. SRP is a fairly simple protocol. SRP involves little more than
exponentiation, addition, multiplication, and hashing, all of
which are easily understood and implemented.
2. SRP is fast. It is a commonly accepted article of faith that
strong authentication protocols must perform some form of slow
public-key computation during authentication. SRP runs as quickly
as a conventional, anonymous Diffie-Hellman key exchange, and many
of the optimizations that work with D-H can be applied to SRP,
e.g. parallelizing operations to minimize user-visible delay.
Typical unoptimized implementations have been shown to take under
a second to complete authentication.
3. SRP is easy to standardize, implement, and debug. Since SRP is
based on a set of simple operations, it is fairly easy to find
existing code that performs the component functions and integrate
it into any client application. Also, since SRP is fairly
economical with respect to network traffic, it is fairly easy to
specify and standardize for widespread use. The messages are all
easy to characterize and are fairly specific in nature.
Practical prototypes of networked utilities that support SRP have
already been built and tested. Because of SRP's relative simplicity,
the prototypes have proven to be robust and fairly bug-free, not to
mention fast. SRP is at or near the most of the theoretical limits of
strong authentication protocols. It is believed that three messages is
the absolute minimum number of messages required for strong
authentication; SRP uses four (not counting the identity and parameter
messages in either case), but the last one is required only if mutual
authentication is desired.
An SRP API library consisting of simple file and session manipulation
primitives has been written, and the current prototypes have been
built using it. SRP lends itself readily to small implementations and
short, compact technical specifications. Internet drafts for the
Telnet and FTP protocol extensions have already been written.
Organizations and standards bodies should find SRP fairly easy to
adopt and integrate into existing specifications and code.
_________________________________________________________________
Political Advantages
While the security of a protocol should be the primary concern of
anyone who is considering its use, legal and policy issues should not
be overlooked. In this area, SRP also has some appealing advantages
for potential users.
1. SRP is free for non-commercial use. As the inventor of SRP, I have
decided to make it free for all non-commercial implementations.
Most of the other strong protocols discussed previously are
protected by patents held by various large corporations, most of
whom are more interested in collecting license fees than
encouraging the spread of strong password authentication.
2. SRP does not use encryption to perform authentication. This is an
important distinction in SRP's favor. While protocols in the EKE
family, for example, depend on symmetric ciphers, SRP requires
only modular arithmetic and one-way hash functions. Since no
encryption is employed, SRP is not affected by U.S. export
regulations and can be freely transferred in and out of the U.S.
3. SRP does not use RSA or any other RSADSI intellectual property. In
fact, SRP does not use any public-key cryptosystems or digital
signature schemes at all. It is based entirely on arithmetic and
hashing, both of which can be done with freely-available code and
algorithms. Thus, entirely free implementations of SRP can and
have been written.
Patents, trademarks, and export regulations have all conspired to make
the creation and distribution of cryptographic products more difficult
than they should be. SRP is my attempt at opening up access to secure
password authentication systems and allowing them to become more
widespread. A simple, secure authentication mechanism that is clear of
RSADSI intellectual property, not export regulated by the U.S.
Commerce Department, and free for non-commercial use would be ideal
for free software makers, who have long been at a disadvantage
relative to large companies who could generally afford the steep
licensing fees and the overhead of obtaining export approval.
_________________________________________________________________
[2]Back
References
1. http://srp.stanford.edu/srp/issues.html
2. http://srp.stanford.edu/srp/index.html
