Subject: Type 2 -- The DIGEST-MD5 digest-challenge
Author: SteveHB
In response to: DIGEST-MD5 -- Digest Authentication as a SASL Mechanism
Posted on: 06/13/2006 01:17:32 PM
Structure:
digest-challenge =
1#( realm | nonce | qop-options | stale | maxbuf | charset
algorithm | cipher-opts | auth-param )
realm = "realm" "=" <"> realm-value <">
realm-value = qdstr-val
nonce = "nonce" "=" <"> nonce-value <">
nonce-value = qdstr-val
qop-options = "qop" "=" <"> qop-list <">
qop-list = 1#qop-value
qop-value = "auth" | "auth-int" | "auth-conf" |
token
stale = "stale" "=" "true"
maxbuf = "maxbuf" "=" maxbuf-value
maxbuf-value = 1*DIGIT
charset = "charset" "=" "utf-8"
algorithm = "algorithm" "=" "md5-sess"
cipher-opts = "cipher" "=" <"> 1#cipher-value <">
cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
"rc4-56" | token
auth-param = token "=" ( token | quoted-string )
The meanings of the values of the directives used above are as follows:
realm Mechanistically, a string which can enable users to know which username and password to use, in case they might have different ones for different servers. Conceptually, it is the name of a collection of accounts that might include the user's account. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.example.com". This directive is optional; if not present, the client SHOULD solicit it from the user or be able to compute a default; a plausible default might be the realm supplied by the user when they logged in to the client system. Multiple realm directives are allowed, in which case the user or client must choose one as the realm for which to supply to username and password.
nonce A server-specified data string which MUST be different each time a digest-challenge is sent as part of initial authentication. It is recommended that this string be base64 or hexadecimal data. Note that since the string is passed as a quoted string, the double-quote character is not allowed unless escaped. The contents of the nonce are implementation dependent. The security of the implementation depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy. The nonce is opaque to the client. This directive is required and MUST appear exactly once; if not present, or if multiple instances are present, the client should abort the authentication exchange.
qop-options A quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection; the value "auth-conf" indicates authentication with integrity protection and encryption. This directive is optional; if not present it defaults to "auth". The client MUST ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange.
stale The "stale" directive is not used in initial authentication. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
maxbuf A number indicating the size of the largest buffer the server is able to receive when using "auth-int" or "auth-conf". If this directive is missing, the default value is 65536. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
charset This directive, if present, specifies that the server supports UTF-8 encoding for the username and password. If not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset). The directive is needed for backwards compatibility with HTTP Digest, which only supports ISO 8859-1. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
algorithm This directive is required for backwards compatibility with HTTP Digest., which supports other algorithms. . This directive is required and MUST appear exactly once; if not present, or if multiple instances are present, the client should abort the authentication exchange.
cipher-opts A list of ciphers that the server supports. This directive must be present exactly once if "auth-conf" is offered in the "qop-options" directive, in which case the "3des" and "des" modes are mandatory-to-implement. The client MUST ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange.
des the Data Encryption Standard (DES) cipher [FIPS] in cipher block chaining (CBC) mode with a 56 bit key.
3des the "triple DES" cipher in CBC mode with EDE with the same key for each E stage (aka "two keys mode") for a total key length of 112 bits.
rc4, rc4-40, rc4-56 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively.
auth-param This construct allows for future extensions; it may appear more than once. The client MUST ignore any unrecognized directives.
For use as a SASL mechanism, note that the following changes are made to "digest-challenge" from HTTP: the following Digest options (called "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, and MUST be ignored if received):
opaque
domain
The size of a digest-challenge MUST be less than 2048 bytes.
>
> On 06/13/2006 01:08:03 PM SteveHB wrote:
What's DIGEST-MD5?
DIGEST-MD5 is a challenge-response authentication protocol used in conjunction with SASL for digest authentication and optional establishment of a security layer. It specifies the following ciphers for use with the security layer: Triple DES, DES and RC4 (128, 56, and 40 bits).
SASL DIGEST-MD5 employs a challenge-response mechanism for authentication, in which clients are able to prove their identities without sending a password to the server. It consists of three messages, commonly referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3 (response). It basically works like this:
The client first sends a Type 1 message containing a request for DIGEST-MD5 to the server.
The server responds with a Type 2 message containing a set of flags supported or required by the server (thus enabling an agreement on the authentication algorithm and ciphers between the server and the client) and, more importantly, a random challenge -- commonly referred to as nonce.
The client uses the challenge obtained from the Type 2 message and the user's credentials to calculate the response. The calculation methods differ based on the DIGEST-MD5 algorithms and ciphers negotiated previously. The client then sends the 'digest-response' to the server in a Type 3 message.
Finally, the server receives and validates the "digest-response". The server checks that the nonce-count is "00000001". If it supports subsequent authentication, it saves the value of the nonce and the nonce-count.
References:
