Introduction
In
Part One of this article, the possibilities for The Secure
Remote Password (SRP) in today's multi-channel world, specifically how it improves
upon the inherent insecurity of password authentication was discussed. It holds
great promise as a way to strongly authenticate a user without the usual risks
of dictionary attack(s) faced by other password-based authentication schemes.
Obstacles
To Acceptance Smart Clients
A
smart' client is required to carry out the computations on the shared secret
and to manage the handshake with the server. This requires software to be installed
on the client machine. This has the biggest impact on the most prevalent channel,
HTML over HTTP. SRP authentication for web clients is only viable from a Java
applet. There is a further complication for mobile channels in that memory and
CPU usage on these devices is very valuable, however, the footprint for SRP
authentication is considerably smaller than that required for a smart card token
and its associated libraries. The need for client software is by no means a
show stopper, but rather a potential stumbling block since it requires more
work than just basic authentication, the evil path of least resistance.
Underlying
Network Protocol
The
very thing that makes SRP appealing is also what makes it difficult to embrace.
Including SRP in the protocol makes it easy to use from a client perspective,
however requires a lot of work upfront to change the network protocol, which
could take months if not years given industry standards and legacy systems.
As mentioned before, there are a growing number of Telnet, FTP, and SSH applications
that use SRP, it is in the realm of Internet protocols that this change is most
necessary.
Ideally, in order to globally enable SRP authentication for web users, the HTTP protocol needs to include a new authentication scheme for SRP type and a new attribute for the session key. The browsers would need to be on board as well and provide support for the multi-step SRP handshake, thereby requiring a change to HTML. This new' HTML tag would trigger the browser to perform the SRP calculations and manage the handshakes between the server and the browser until the authentication was complete. At such time, control would be returned to the browser user and all subsequent requests to the server would include the SRP session key in the request/response pair. Obviously, this situation requires a lot of cooperation from competing browser vendors as well as standard bodies and as such makes it difficult to foresee these changes being easily adopted.
Marketing
Believe
it or not, the largest obstacle to acceptance of SRP is the belief that the
current authentication mechanism is sufficient. Password-based authentication
is the most popular and yet the most insecure, giving users a false sense of
security. This is true for several reasons. The ease of use and simplicity for
a username/password scheme is unbeatable. Software projects are always under
tight deadlines and as a result, security is one of the first requirements to
be compromised it is simply too easy to claim that it will be addressed in
a future release. Until the market demands a more robust authentication mechanism,
companies will continue to pay the price for weak authentication. Furthermore,
companies need to embrace the multi-channel market and take responsibility for
strong authentication in these insecure channels. Other than market changes
which are not tangible, there are a number of changes that would help accelerate
acceptance of the SRP protocol as outlined in the next section.
This
is Part Two of a two-part article. Part One detailed the advantages of SRP.
This
part discusses the obstacles to be overcome for it to succeed.
Suggestions To Guarantee Acceptance
The functionality and security of the SRP protocol is exceptionally robust. Since it evolved from the original SPEKE protocol, shortcomings, both from a functional and performance perspective have been addressed, making it a mature protocol despite its young age. Having said that, there are a number of marketing tasks and suggestions that will help secure its overall success, some of which have already been started.
First of all, a patent for SRP-4 has already been acquired by Phoenix Technologies. There is a patent application pending for SRP-3 from Stanford University. It seems prudent that ownership of the protocol be transferred from the university to a suitable vendor to provide financial support and market influence. This transfer of ownership has already begun with Phoenix. Technologies.
The
following are suggestions on ways to market SRP to the different audiences.
Essentially, SRP authentication can either be embedded in a network protocol
or can be used at the higher application level enabling proprietary applications
to incorporate it. We have seen examples of both usage patterns the plethora
of Telnet and FTP applications and the inclusion of SRP into the JBossSX framework.
The following sections address both usage patterns, in an attempt to reach all
interested parties.
Make
It A Standard
This is already in progress by Phoenix Technologies and Thomas Wu among others.
Currently, the IEEE (Institute of Electrical and Electronics Engineers Inc.)
has been targeted P1363.2 is a draft version of "Standard Specifications for
Password-Based Public-Key Cryptographic Techniques" which includes the following
submissions and presentations.
-
SPEKE: Presented to IEEE in September 1996
-
The SRP Protocol: Presented to IEEE in August 1997
-
SRP-4: Presented to IEEE in May 2002
Continued
work needs to be done in this area to ensure that SRP is one of the leading
password-based authentication technologies.
Submit
Protocol Specification Change Proposals
As mentioned
several times earlier in this article, there are many open-source and commercial
implementations of FTP and Telnet available that include SRP. Now SRP should
be included by default when FTP and Telnet are installed on new machines.
The
bigger concern with protocol specification changes is with HTTP, the de-facto
standard for web, web services, voice, cell phone and PDA traffic. For SRP to
be easily accessible to all of these channels, the actual protocol needs to
be updated. This was touched on briefly in an earlier section. This requires
acceptance by W3C Consortium, which will not happen overnight. However, it is
paramount if SRP is to be an effective means of authentication for HTTP clients.
As mentioned earlier, this requires at a minimum modifications to include a
new auth-scheme type and to add the SRP session key to the HTTP header in each
request/response pair. This is merely a suggestion much more detailed work
is required to research what is required and whether or not it is achievable
within the stateless HTTP protocol.
Create
XML Specification for the SRP Handshake
An XML specification that defines the structure for transporting SRP data back
and forth between a client and a server needs to be defined. Currently, there
is a clear definition of the processing required on both the client and server
side, however the transfer of data between the two is not defined and as such
is left up to each implementation of SRP. This is a waste of effort, requiring
people to continually reinvent the wheel. Why not make it a collaborative effort
and learn from the mistakes of people who have already achieved this to determine
the best way to represent these handshakes in an XML document. A specification/standard
that filled this need would greatly increase the chances of success for SRP
within the application layer.
Target
Mobile Device Manufacturers
The creators of SRP envisioned it being used by small, resource-constrained
devices. In keeping with this vision, libraries that provide client SRP processing
(in native language and/or Java) should be created for the major mobile device
manufacturers. Assuming that modifications to the HTTP specification are accepted
and implemented, a modified HTTP network library could be included. This would
allow for a consistent interface to SRP on these disparate devices. Obviously,
these libraries would need to be developed in close conjunction with the manufacturers.
Target
Application Server Vendors
One of the leading application server vendors, JBoss, has already included an
implementation of SRP in its security framework. It is now pertinent to target
other leading vendors, such as BEA WebLogic (www.weblogic.com)
and IBM WebSphere (www.ibm.com)
to include SRP implementation in their frameworks as well. Ideally, these application
server vendors need to provide three features to fully support SRP.
-
Java API for the server verification processing
-
Java API for the persistence of verifiers
-
Java API for client processing
-
Support incoming SRP authentication requests from different network protocols
(currently only FTP/TELNET, but hopefully to include HTTP in the future based
on other recommendations in this article). This feature is a future item and
not as critical as the first three for initial adaptation.
Get
Sun On Board
To attract the audiences interested in using SRP to authenticate users at the
application level, it is important to get Sun Microsystems involved in the effort.
A standard Java API for SRP authentication should be proposed. Hopefully it
will quickly be accepted and incorporated into the Java Security package, making
it easier for application developers to use SRP authentication mechanism in
their applications.
Summary
For success, SRP authentication must meet two basic requirements. It must provide a strong alternative to the current password-based authentication mechanism in place and it must be readily available. It most definitely meets the first requirement, as stated earlier with its defense against dictionary attacks, use of temporary session keys, and non-transport of the password. However, there remains plenty of work to fulfill the second requirement. The previous section highlighted a large number of suggestions and tasks to help advertise SRP and these suggestions are by no means simple nor short-lived, but with perseverance and determination, can be achieved.
The area in which SRP holds true promise, as identified by its founding fathers, is in the realm of mobile, or disconnected devices cell phones, set top boxes, diskless workstations, roaming users, kiosk users, etc. The list of applications will continue to grow. Due to its proliferation in the market, the web channel could really benefit from SRP, although it was not originally identified as a potential candidate due to difficulties in supplying a smart' client.
All in all, Phoenix Technologies and Stanford University are taking the right steps to acquire patents and include SRP in various network protocols. Unfortunately, I fear that until the market acknowledges the need for strong password-based authentication, all these efforts will be in vain unless the founding fathers have the will to persevere and see SRP to its rightful home in the spotlight of password-based authentication schemes.
About the Author
Brenda
Coulson is a Software Architect at Cysive, Inc. where
she works in Product Development on the Cymbio Interaction Server.
Brenda is a Sun Certified Java Programmer and Java Developer,
and holds a BS degree from James Madison University.
Brenda may be reached
at bcoulson@cysive.com.
References
Glossary
-
Dictionary Attack is a term used to describe an attack on
the password storage. Typically, the attacker sniffs the encrypted password
from storage or the network and then tries to guess the associated plain-text
password by trying all permutations (something easily done today by a computer
program).
-
EKE is Encrypted Key Exchange developed by Steve Bellovin
and Michael Merritt of Bell Labs in 1992.
-
A-EKE is an augmented version of EKE
-
B-EKE is the second augmented version of EKE
-
DH-EKE Diffie-Hellman Encrypted Key Exchange
-
SRP is Secure Remote Password
-
SPEKE is Simple Password Exponential Key Exchange
-
ZKPP Zero Knowledge Password Proof