4 Protocol Examples

The following diagram and procedural steps describe a common scenario to illustrate the function of the Digest Protocol Extensions.

Figure 1: Common use scenario for Digest Protocol Extensions

1. After the client attempts to access a protected resource (for example, ResourceA) on the server, the server returns a digest-challenge message to the client. Among other fields, the digest-challenge message includes a randomly generated nonce and the domain name of the server (via the realm field). A sample digest Challenge is shown here.

    qop="auth",algorithm=MD5-sess,
    nonce="91c121b4f47ec601a281ceefaa5d6f2b096897ea0797fdd2ea72bfeec7fd
    a64433a98d4ae57186a1",
    charset=utf-8,realm="TestDomain"
   

2. The client obtains the user name (for example, User123) and password for the user and constructs a response to the server's challenge. In the digest-response, the client proves knowledge of the user's password by performing a keyed hash over the user name, nonce, and other fields (the password is fed into the hash). A sample digest-response is shown here.

    username="User123",
    realm="TestDomain",
    qop="auth",
    algorithm="MD5-sess",
    uri="/ResourceA", 
    nonce="91c121b4f47ec601a281ceefaa5d6f2b096897ea0797fdd2ea72bfeec7fd
    a64433a98d4ae57186a1",
    nc=00000001,
    cnonce="579c5e7723ad0ef8eeb0b7427379bdd4",
    response="641b92d2d8af170329ce308832a4df13"
   

3. The server validates the digest-response message by looking up the user's password by using the user name that the client sent, recomputing the keyed hash over fields from the digest-response message, and then comparing the resulting hash value to the Response directive value sent by the client. If the values match, the client's digest-response message is valid; otherwise, the authentication request fails. The server further checks that the client sent the expected nonce and nonce-count values (and not an old, replayed value). After the digest response is validated, the client is authenticated to the server. For mutual authentication, the server has the option to send a keyed hash over the URI that the client requested and return it to the client in the Response-Auth message. Note that sending the Response-Auth message only applies to digest authentication when used as an SASL mechanism, as specified in [RFC2831]. For further information, see section 3.1.5.1.