The qop field may be present in all three digest headers: WWW-Authenticate, Authorization, and Authentication-Info.

The qop field lets clients and servers negotiate for different types and qualities of protection. For example, some transactions may want to sanity check the integrity of message bodies, even if that slows down transmission significantly.

The server first exports a comma-separated list of qop options in the WWW-Authenticate header. The client then selects one of the options that it supports and that meets its needs and passes it back to the server in its Authorization qop field.

Use of qop is optional, but only for backward compatibility with the older RFC 2069 specification. The qop option should be supported by all modern digest implementations.

RFC 2617 defines two initial quality of protection values: "auth," indicating authentication, and "auth-int," indicating authentication with message integrity protection. Other qop options are expected in the future.

Message Integrity Protection

If integrity protection is applied (qop="auth-int"), H (the entity body) is the hash of the entity body, not the message body. It is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded headers in each part of any multipart content type.

Digest Authentication Headers

Both the basic and digest authentication protocols contain an authorization challenge, carried by the WWW-Authenticate header, and an authorization response, carried by the Authorization header. Digest authentication adds an optional Authorization-Info header, which is sent after successful authentication, to complete a three-phase handshake and pass along the next nonce to use. The basic and digest authentication headers are shown in Table 13-8.

Table 13-8. HTTP authentication headers

Phase Basic Digest
Challenge 
WWW-Authenticate: Basic
 realm="<realm-value>"
 
WWW-Authenticate: Digest
 realm="<realm-value>"
 nonce="<nonce-value>"
 [domain="<list-of-URIs>"]
 [opaque="<opaque-token-value>"]
 [stale=<true-or-false>]
 [algorithm=<digest-algorithm>]
 [qop="<list-of-qop-values>"]
 [<extension-directive>]
Response 
Authorization: Basic 
 <base64-user:pass>
 
Authorization: Digest
 username="<username>"
 realm="<realm-value>"
 nonce="<nonce-value>"
 uri=<request-uri>
 response="<32-hex-digit-digest>"
 [algorithm=<digest-algorithm>]
 [opaque="<opaque-token-value>"]
 [cnonce="<nonce-value>"]
 [qop=<qop-value>]
 [nc=<8-hex-digit-nonce-count>]
 [<extension-directive>]
Info 
n/a
 
Authentication-Info:
 nextnonce="<nonce-value>"
 [qop="<list-of-qop-values>"]
 [rspauth="<hex-digest>"]
 [cnonce="<nonce-value>"]
 [nc=<8-hex-digit-nonce-count>]

The digest authentication headers are quite a bit more complicated. They are described in detail in Appendix F.

 

Hypertext Transfer Protocol (HTTP)