advantages.html
93bad854f3079578826714bdf973f0f980659db1d311e1285ac863f119cb9990<html>
<head>
<title>SRP: Advantages and Benefits</title>
</head>
<body fgcolor="#000000" bgcolor="#FFFFFF">
<h1>Advantages and Benefits of SRP</h1>
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.
<p>
<hr>
<a name="security"><h2>Security Advantages</h2></a>
In a nutshell, here are some of the properties that make SRP a
strong authentication protocol:
<ol>
<li>SRP is safe against snooping. The password is never passed
over the network, either in the clear or encrypted.
<li>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.
<li>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.
<li>SRP can provide mutual authentication.
This requires both sides to keep their secrets secure, obviously.
<li>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.
<li>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 <i>Denning-Sacco</i>
attack; a compromised session key will not permit an attacker
to mount a dictionary attack against the password.
<li>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.
</ol>
The last three issues are what I call the "Big-3" of password
authentication, and they are discussed in greater detail on a
<a href="issues.html">separate page</a>.
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.
<p>
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.
<p>
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.
<p>
<hr>
<a name="technical"><h2>Technical Advantages</h2></a>
Aside from purely security-related benefits, SRP has a number of
technical and practical advantages that make it an versatile protocol.
<ol>
<li>SRP is a fairly simple protocol.
SRP involves little more than exponentiation, addition,
multiplication, and hashing, all of which are easily
understood and implemented.
<li>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.
<li>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.
</ol>
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.
<p>
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.
<p>
<hr>
<a name="political"><h2>Political Advantages</h2></a>
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.
<ol>
<li>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.
<li>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.
<li>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.
</ol>
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.
<p>
<hr>
<a href="index.html">Back</a>
</body>
</html>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed