The Future of Secure Remote Password (SRP) Part Two: Overcoming Obstacles to Success

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.

http://www.technologyevaluation.com/research/articles/the-future-of-secure-remote-password-srp-part-two-overcoming-obstacles-to-success-16893/