The Secure Remote Password (SRP) Protocol


The SRP protocol is an implementation of a public key exchange handshake described in the Internet Standards Working Group RFC 2945. The RFC 2945 abstract states the following:

This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords. This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge-response techniques, making it an ideal drop-in replacement where secure password authentication is needed.

Note

You can obtain the complete RFC 2945 specification from www.rfc-editor.org/rfc.html. Additional information on the SRP algorithm and its history can be found at http://srp.stanford.edu/.


SRP is similar in concept and security to other public key exchange algorithms, such as Diffie-Hellman and RSA. SRP is based on simple string passwords in a way that does not require a clear-text password to exist on the server. This is in contrast to other public keybased algorithms that require client certificates and the corresponding certificate management infrastructure.

Algorithms such as Diffie-Hellman and RSA are known as public key exchange algorithms. The concept of public key algorithms is that there are two keys: one that is public and is available to everyone and one that is private and known only to you. When someone wants to send encrypted information to you, that person encrypts the information using your public key. Only you are able to decrypt the information using your private key. This contrasts with the more traditional shared passwordbased encryption schemes that require the sender and receiver to know the shared password. Public key algorithms eliminate the need to share passwords.

The JBossSX framework includes an implementation of SRP that consists of the following elements:

  • An implementation of the SRP handshake protocol that is independent of any particular client/server protocol

  • An RMI implementation of the handshake protocol as the default client/server SRP implementation

  • A client-side JAAS LoginModule implementation that uses the RMI implementation for use in authenticating clients in a secure fashion

  • A JMX MBean for managing the RMI server implementation. The MBean allows the RMI server implementation to be plugged into a JMX framework and externalizes the configuration of the verification information store. It also establishes an authentication cache that is bound into the JBoss server JNDI namespace.

  • A server-side JAAS LoginModule implementation that uses the authentication cache managed by the SRP JMX MBean.

Figure 8.14 shows a diagram of the key components involved in the JBossSX implementation of the SRP client/server framework.

Figure 8.14. The JBossSX components of the SRP client/server framework.


On the client side, SRP shows up as a custom JAAS LoginModule implementation that communicates to the authentication server through an org.jboss.security.srp.SRPServerInterface proxy. A client enables authentication using SRP by creating a login configuration entry that includes the org.jboss.security.srp.jaas.SRPLoginModule. This module supports the following configuration options:

  • principalClassName This option is no longer supported. The principal class is now always org.jboss.security.srp.jaas.SRPPrincipal.

  • srpServerJndiName This option specifies the JNDI name of the SRPServerInterface object to use for communicating with the SRP authentication server. If both srpServerJndiName and srpServerRmiUrl options are specified, the srpServerJndiName is tried before srpServerRmiUrl.

  • srpServerRmiUrl This option specifies the RMI protocol URL string for the location of the SRPServerInterface proxy to use for communicating with the SRP authentication server.

  • externalRandomA This option is a true/false flag that indicates whether the random component of client public key A should come from the user callback. This can be used to input a strong cryptographic random number that comes from a hardware token, for example.

  • hasAuxChallenge This option is a TRue/false flag that indicates whether a string will be sent to the server as an additional challenge for the server to validate. If the client session supports an encryption cipher, then a temporary cipher is created, using the session private key and the challenge object, sent as a javax.crypto.SealedObject.

  • multipleSessions This option is a true/false flag that indicates whether a given client may have multiple SRP login sessions active simultaneously.

Any other options that are passed in and do not match one of the previously named options is treated as a JNDI property to use for the environment passed to the InitialContext constructor. This is useful if the SRP server interface is not available from the default InitialContext.

The SRPLoginModule needs to be configured along with the standard ClientLoginModule to allow the SRP authentication credentials to be used for validation of access to security J2EE components. The following is an example of a login configuration entry that demonstrates such a setup:

 srp {     org.jboss.security.srp.jaas.SRPLoginModule required     srpServerJndiName="SRPServerInterface"     ;     org.jboss.security.ClientLoginModule required     password-stacking="useFirstPass"     ; }; 

On the JBoss server side, two MBeans manage the objects that collectively make up the SRP server: org.jboss.security.srp.SRPService and org.jboss.security.srpSRPVerifierStoreService. The primary service is the org.jboss.security.srp.SRPService MBean, and it is responsible for exposing an RMI-accessible version of the SRPServerInterface as well as updating the SRP authentication session cache. The configurable SRPService MBean attributes include the following:

  • JndiName The JNDI name from which the SRPServerInterface proxy should be available. This is the location where the SRPService binds the serializable dynamic proxy to the SRPServerInterface. If not specified, it defaults to srp/SRPServerInterface.

  • VerifierSourceJndiName The JNDI name of the SRPVerifierSource implementation that should be used by the SRPService. If not set, it defaults to srp/DefaultVerifierSource.

  • AuthenticationCacheJndiName The JNDI name under which the authentication org.jboss.util.CachePolicy implementation to be used for caching authentication information is bound. The SRP session cache is made available for use through this binding. If not specified, it defaults to srp/AuthenticationCache.

  • ServerPort The RMI port for the SRPRemoteServerInterface. If not specified, it defaults to 10099.

  • ClientSocketFactory An optional custom java.rmi.server.RMIClientSocketFactory implementation classname that is used during the export of the SRPServerInterface. If not specified, the default RMIClientSocketFactory is used.

  • ServerSocketFactory An optional custom java.rmi.server.RMIServerSocketFactory implementation classname that is used during the export of the SRPServerInterface. If not specified, the default RMIServerSocketFactory is used.

  • AuthenticationCacheTimeout The timed cache policy timeout, in seconds. If not specified, this defaults to 1800 (30 minutes).

  • AuthenticationCacheResolution The timed cache policy resolution, in seconds. This controls the interval between checks for timeouts. If not specified, this defaults to 60 (1 minute).

  • RequireAuxChallenge An option that, when set, causes the client to supply an auxiliary challenge as part of the verify phase. This gives control over whether the SRPLoginModule configuration used by the client must have the useAuxChallenge option enabled.

  • OverwriteSessions A flag that indicates whether a successful user authentication for an existing session should overwrite the current session. This controls the behavior of the server SRP session cache when clients have not enabled the multiple-sessions-per-user mode. The default is false, which means that the second attempt by a user to authentication will succeed but the resulting SRP session will not overwrite the previous SRP session state.

The one input setting is the VerifierSourceJndiName attribute. This is the location of the SRP password information store implementation that must be provided and made available through JNDI. The org.jboss.security.srpSRPVerifierStoreService is an example of an MBean service that binds an implementation of the SRPVerifierStore interface that uses a file of serialized objects as the persistent store. Although this MBean is not realistic for a production environment, it does allow for testing of the SRP protocol and provides an example of the requirements for an SRPVerifierStore service. The configurable SRPVerifierStoreService MBean attributes include the following:

  • JndiName The JNDI name from which the SRPVerifierStore implementation should be available. If not specified, it defaults to srp/DefaultVerifierSource.

  • StoreFile The location of the user password verifier serialized object store file. This can be either a URL or a resource name to be found in the classpath. If not specified, it defaults to SRPVerifierStore.ser.

The SRPVerifierStoreService MBean also supports addUser and delUser operations for addition and deletion of users. These are the signatures:

 public void addUser(String username, String password)      throws IOException; public void delUser(String username) \      throws IOException; 

Providing Password Information for SRP

The default implementation of the SRPVerifierStore interface is not likely to be suitable for your production security environment because it requires all password hash information to be available as a file of serialized objects. You need to provide an MBean service that provides an implementation of the SRPVerifierStore interface that integrates with your existing security information stores. The SRPVerifierStore interface is shown in Listing 8.12.

Listing 8.12. The SRPVerifierStore Interface
 package org.jboss.security.srp; import java.io.IOException; import java.io.Serializable; import java.security.KeyException; public interface SRPVerifierStore {     public static class VerifierInfo implements Serializable     {         /**          * The username the information applies to. Perhaps redundant          * but it makes the object self contained.          */         public String username;         /** The SRP password verifier hash */         public byte[] verifier;         /** The random password salt originally used to verify the password */         public byte[] salt;         /** The SRP algorithm primitive generator */         public byte[] g;         /** The algorithm safe-prime modulus */         public byte[] N;     }     /**      *  Get the indicated user's password verifier information.      */     public VerifierInfo getUserVerifier(String username)         throws KeyException, IOException;     /**      *  Set the indicated users' password verifier information. This      *  is equivalent to changing a user's password and should      *  generally invalidate any existing SRP sessions and caches.      */     public void setUserVerifier(String username, VerifierInfo info)         throws IOException;     /**      * Verify an optional auxiliary challenge sent from the client to      * the server. The auxChallenge object will have been decrypted      * if it was sent encrypted from the client. An example of an      * auxiliary challenge would be the validation of a hardware token      * (SafeWord, SecureID, iButton) that the server validates to      * further strengthen the SRP password exchange.      */     public void verifyUserChallenge(String username, Object auxChallenge)         throws SecurityException; } 

The primary function of a SRPVerifierStore implementation is to provide access to the SRPVerifier-Store.VerifierInfo object for a given username. SRPService calls the getUserVerifier(String) method at that start of a user SRP session to obtain the parameters needed by the SRP algorithm. The elements of the VerifierInfo objects are as follows:

  • username The user's name or ID that is used to log in.

  • verifier The one-way hash of the password or PIN the user enters as proof of his or her identity. The org.jboss.security.Util class has a calculateVerifier method that performs that password-hashing algorithm. The output password is H(salt | H(username | ':' | password)), as defined in RFC 2945. Here H is the SHA secure hash function. The username is converted from a string to a byte[], using UTF-8 encoding.

  • salt A random number that is used to increase the difficulty of a brute-force dictionary attack on the verifier password database in the event that the database is compromised. It is a value that should be generated from a cryptographically strong random number algorithm when the user's existing clear-text password is hashed.

  • g The SRP algorithm primitive generator. In general, this can be a well-known fixed parameter rather than a per-user setting. The org.jboss.security.srp.SRPConf utility class provides several settings for g, including a good default that you can obtain via SRPConf.getDefaultParams().g().

  • N The SRP algorithm safe-prime modulus. In general, this can be a well-known fixed parameter rather than a per-user setting. The org.jboss.security.srp.SRPConf utility class provides several settings for N, including a good default that you can obtain via SRPConf.getDefaultParams().N().

These are the steps in integrating your existing password store:

1.

Create a hashed version of the password information. If your passwords are already stored in an irreversible hashed form, then you can do this step only on a peruser basis (as part of an upgrade procedure, for example). Note that the setUserVerifier (String, VerifierInfo) method is not used by the current SRPService and may be implemented as a no-op method or even as one that throws an exception stating that the store is read-only.

2.

Create the custom SRPVerifierStore interface implementation that knows how to obtain the VerifierInfo from the store you created in step 1. The verifyUserChallenge(String, Object) method of the interface is called only if the client SRPLoginModule configuration specifies the hasAuxChallenge option. This can be used to integrate existing hardware token-based schemes such as SafeWord or Radius into the SRP algorithm.

3.

Create an MBean that makes the step 2 implementation of the SRPVerifierStore interface available via JNDI and exposes any configurable parameters you need. In addition to the default org.jboss.security.srp.SRPVerifierStoreService example, the SRP example presented later in this chapter provides a Java properties filebased SRPVerifierStore implementation. Between the two examples, you should have enough to integrate your security store.

Inside the SRP Algorithm

The appeal of the SRP algorithm is that is allows for mutual authentication of the client and server, using simple text passwords without a secure communication channel. You might be wondering how this is done. If you want the complete details and theory behind the algorithm, refer to http://srp.stanford.edu. Six steps are performed to complete authentication:

1.

The client-side SRPLoginModule retrieves the SRPServerInterface instance for the remote authentication server from the naming service.

2.

The client-side SRPLoginModule requests the SRP parameters associated with the username that is attempting the login. You must choose a number of parameters that are involved in the SRP algorithm when the user password is first transformed into the verifier form used by the SRP algorithm. Rather than hard-coding the parameters (which you could do with minimal security risk), the JBossSX implementation allows you to retrieve this information as part of the exchange protocol, by using the getSRPParameters(username) call.

3.

The client-side SRPLoginModule begins an SRP session by creating an SRPClientSession object, using the login username, clear-text password, and SRP parameters obtained in step 2. The client then creates a random number A that will be used to build the private SRP session key. The client then initializes the server side of the SRP session by invoking the SRPServerInterface.init method and passes in the username and client-generated random number A. The server returns its own random number B. This step corresponds to the exchange of public keys.

4.

The client-side SRPLoginModule obtains the private SRP session key that has been generated as a result of the previous message exchanges. This is saved as a private credential in the login Subject. The server challenge response M2 from step 4 is verified by invoking the SRPClientSession.verify method. If it succeeds, mutual authentication of the client to the server and of the server to the client have been completed. The client-side SRPLogin-Module next creates a challenge M1 to the server by invoking SRPClientSession.response method, passing the server random number B as an argument. This challenge is sent to the server via the SRPServerInterface.verify method, and the server's response is saved as M2. This step corresponds to an exchange of challenges. At this point, the server has verified that the user is who he or she claims to be.

5.

The client-side SRPLoginModule saves the login username and M1 challenge into the LoginModule sharedState map. The standard JBoss ClientLoginModule uses this as the Principal name and credentials. The M1 challenge is used in place of the password as proof of identity on any method invocations on J2EE components. The M1 challenge is a cryptographically strong hash associated with the SRP session. Its interception via a third party cannot be used to obtain the user's password.

6.

At the end of this authentication protocol, the SRPServerSession is placed into the SRPService authentication cache for subsequent use by the SRPCacheLoginModule.

Although SRP has many interesting properties, it is still an evolving component in the JBossSX framework and has some limitations of which you should be aware. Issues of note include the following:

  • Because of how JBoss detaches the method transport protocol from the component container where authentication is performed, an unauthorized user could snoop the SRP M1 challenge and effectively use the challenge to make requests under the associated username. You can use custom interceptors that encrypt the challenge via the SRP session key to prevent this issue.

  • The SRPService maintains a cache of SRP sessions that time out after a configurable period. After they time out, any subsequent J2EE component access will fail because at the time, there is no mechanism for transparently renegotiating the SRP authentication credentials. You must either set the authentication cache timeout very long (up to 2,147,483,647 seconds, or approximately 68 years) or handle reauthentication in your code on failure.

  • By default, there can be only one SRP session for a given username. Because the negotiated SRP session produces a private session key that can be used for encryption/decryption between the client and server, the session is effectively a stateful one. JBoss supports multiple SRP sessions per user, but you cannot encrypt data with one session key and then decrypt it with another.

To use end-to-end SRP authentication for J2EE component calls, you need to configure the security domain under which the components are secured to use the org.jboss.security.srp.jaas.SRPCacheLoginModule. The SRPCacheLoginModule has a single configuration option named cacheJndiName that sets the JNDI location of the SRP authentication CachePolicy instance. This must correspond to the AuthenticationCacheJndiName attribute value of the SRPService MBean. The SRPCacheLoginModule authenticates user credentials by obtaining the client challenge from the SRPServerSession object in the authentication cache and comparing this to the challenge passed as the user credentials. Figure 8.15 illustrates the operation of the SRPCacheLoginModule.login method implementation.

Figure 8.15. A sequence diagram that illustrates the interaction of the SRPCacheLoginModule with the SRP session cache.


An SRP Example

This chapter has covered quite a bit of material on SRP, and now it is time to demonstrate SRP in practice with an example. This example demonstrates client-side authentication of the user via SRP as well as subsequent secured access to a simple EJB, using the SRP session challenge as the user credential. The test code deploys an EJB JAR that includes a SAR for the configuration of the server-side login module configuration and SRP services. As in the previous examples, in this example you will dynamically install the server-side login module configuration by using the SecurityConfig MBean. This example also uses a custom implementation of the SRPVerifierStore interface that uses an in-memory store that is seeded from a Java properties file rather than a serialized object store, as used by the SRPVerifierStoreService. This custom service is org.jboss.chap8.ex3.service.PropertiesVerifierStore. The following shows the contents of the JAR that contains the sample EJB and SRP services:

 [examples]$ java -cp output/classes ListJar output/chap8/chap8-ex3.jar output/chap8/chap8-ex3.jar +- META-INF/MANIFEST.MF +- META-INF/ejb-jar.xml +- META-INF/jboss.xml +- org/jboss/chap8/ex3/Echo.class +- org/jboss/chap8/ex3/EchoBean.class +- org/jboss/chap8/ex3/EchoHome.class +- roles.properties +- users.properties +- chap8-ex3.sar (archive) | +- META-INF/MANIFEST.MF | +- META-INF/jboss-service.xml | +- META-INF/login-config.xml | +- org/jboss/chap8/ex3/service/PropertiesVerifierStore$1.class | +- org/jboss/chap8/ex3/service/PropertiesVerifierStore.class | +- org/jboss/chap8/ex3/service/PropertiesVerifierStoreMBean.class | +- org/jboss/chap8/service/SecurityConfig.class | +- org/jboss/chap8/service/SecurityConfigMBean.class 

The key SRP-related items in this example are the SRP MBean services configuration and the SRP login module configurations. The jboss-service.xml descriptor of chap8-ex3.sar is shown in Listing 8.13, and Listing 8.14 and Listing 8.15 show the sample client-side and server-side login module configurations.

Listing 8.13. The chap8-ex3.sar jboss-service.xml Descriptor for the SRP Services
 <server>     <!-- The custom JAAS login configuration that installs          a Configuration capable of dynamically updating the          config settings -->     <mbean code="org.jboss.chap8.service.SecurityConfig"            name="jboss.docs.chap8:service=LoginConfig-EX3">         <attribute name="AuthConfig">META-INF/login-config.xml</attribute>         <attribute name="SecurityConfigName">jboss.security:name=SecurityConfig</attribute>     </mbean>     <!-- The SRP service that provides the SRP RMI server and server side          authentication cache -->     <mbean code="org.jboss.security.srp.SRPService"            name="jboss.docs.chap8:service=SRPService">         <attribute name="VerifierSourceJndiName">srp-test/chap8-ex3</attribute>         <attribute name="JndiName">srp-test/SRPServerInterface</attribute>         <attribute name="AuthenticationCacheJndiName">srp-test/AuthenticationCache</attribute>         <attribute name="ServerPort">0</attribute>         <depends>jboss.docs.chap8:service=PropertiesVerifierStore</depends>     </mbean>     <!-- The SRP store handler service that provides the user password verifier          information -->     <mbean code="org.jboss.chap8.ex3.service.PropertiesVerifierStore"            name="jboss.docs.chap8:service=PropertiesVerifierStore">         <attribute name="JndiName">srp-test/chap8-ex3</attribute>     </mbean> </server> 

Listing 8.14. The Client-Side Standard JAAS Configuration
 srp {     org.jboss.security.srp.jaas.SRPLoginModule required     srpServerJndiName="srp-test/SRPServerInterface"     ;     org.jboss.security.ClientLoginModule required     password-stacking="useFirstPass"     ; }; 

Listing 8.15. The Server-Side XMLLoginConfig Configuration
 <application-policy name="chap8-ex3">     <authentication>         <login-module code="org.jboss.security.srp.jaas.SRPCacheLoginModule"                       flag = "required">             <module-option name="cacheJndiName">srp-test/AuthenticationCache</module-option>         </login-module>         <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"                       flag = "required">             <module-option name="password-stacking">useFirstPass</module-option>         </login-module>     </authentication> </application-policy> 

The sample services are ServiceConfig and the PropertiesVerifierStore and SRPService MBeans. Note that the JndiName attribute of PropertiesVerifierStore is equal to the VerifierSourceJndiName attribute of SRPService and that SRPService depends on PropertiesVerifierStore. This is required because SRPService needs an implementation of the SRPVerifierStore interface for accessing user password verification information.

The client-side login module configuration makes use of SRPLoginModule with a srpServerJndiName option value that corresponds to the JBoss server component SRPService JndiName attribute value (srptest/SRPServerInterface). Also needed is ClientLoginModule, configured with the password-stacking="useFirstPass" value to propagate the user authentication credentials generated by the SRPLoginModule to the EJB invocation layer.

There are two issues to note about the server-side login module configuration. First, note that the cacheJndiName=srp-test/AuthenticationCache configuration option tells SRPCacheLoginModule the location of the CachePolicy that contains the SRPServerSession for users who have authenticated against the SRPService. This value corresponds to the SRPService AuthenticationCacheJndiName attribute value. Second, the configuration includes a UsersRolesLoginModule with the password-stacking=useFirstPass configuration option. You need to use a second login module with the SRPCacheLoginModule because SRP is only an authentication technology. You need to configure a second login module that accepts the authentication credentials validated by the SRPCacheLoginModule to set the principal's roles to determine the principal's permissions. The UsersRolesLoginModule augments the SRP authentication with properties filebased authorization. The user's roles are coming from the roles.properties file included in the EJB JAR.

Now, you can run the client by executing the following command from the book examples directory:

  [examples]$ ant -Dchap=chap8 -Dex=3 run-example ... run-example3:      [copy] Copying 1 file to /tmp/jboss-4.0.1/server/default/deploy      [echo] Waiting for 5 seconds for deploy...      [java] Logging in using the 'srp' configuration      [java] Created Echo      [java] Echo.echo()#1 = This is call 1      [java] Echo.echo()#2 = This is call 2 

In the examples/logs directory is a file called ex3-trace.log. This is a detailed trace of the client side of the SRP algorithm. Such traces show step-by-step the construction of the public keys, challenges, session key, and verification.

Note that the client in this example takes a long time to run relative to the other simple examples. The reason for this is the construction of the client's public key, which involves the creation of a cryptographically strong random number; this process takes quite a bit of time the first time it occurs. If you were to log out and log in again within the same VM, the process would be much faster. Also note that Echo.echo()#2 fails with an authentication exception. The client code sleeps for 15 seconds after making the first call to demonstrate the behavior of the SRPService cache expiration. The SRPService cache policy timeout is set to a mere 10 seconds to force this issue. As stated earlier, you need to make the cache timeout very long or handle re-authentication on failure.



JBoss 4. 0(c) The Official Guide
JBoss 4.0 - The Official Guide
ISBN: B003D7JU58
EAN: N/A
Year: 2006
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net