From: http://www.ietf.org/rfc/rfc2831.txt
2 Authentication
The following sections describe how to use Digest as a SASL
authentication mechanism.
2.1 Initial Authentication
If the client has not recently authenticated to the server, then it
must perform "initial authentication", as defined in this section. If
it has recently authenticated, then a more efficient form is
available, defined in the next section.
2.1.1 Step One
The server starts by sending a challenge. The data encoded in the
challenge contains a string formatted according to the rules for a
"digest-challenge" defined as follows:
Leach & Newman Standards Track [Page 3]
RFC 2831 Digest SASL Mechanism May 2000
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 (see section
7.2). The contents of the nonce are implementation dependent. The
Leach & Newman Standards Track [Page 4]
RFC 2831 Digest SASL Mechanism May 2000
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. See
the next section for its use in subsequent authentications. 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.
Leach & Newman Standards Track [Page 5]
RFC 2831 Digest SASL Mechanism May 2000
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.
2.1.2 Step Two
The client makes note of the "digest-challenge" and then responds
with a string formatted and computed according to the rules for a
"digest-response" defined as follows:
Leach & Newman Standards Track [Page 6]
RFC 2831 Digest SASL Mechanism May 2000
digest-response = 1#( username | realm | nonce | cnonce |
nonce-count | qop | digest-uri | response |
maxbuf | charset | cipher | authzid |
auth-param )
username = "username" "=" <"> username-value <">
username-value = qdstr-val
cnonce = "cnonce" "=" <"> cnonce-value <">
cnonce-value = qdstr-val
nonce-count = "nc" "=" nc-value
nc-value = 8LHEX
qop = "qop" "=" qop-value
digest-uri = "digest-uri" "=" <"> digest-uri-value <">
digest-uri-value = serv-type "/" host [ "/" serv-name ]
serv-type = 1*ALPHA
host = 1*( ALPHA | DIGIT | "-" | "." )
serv-name = host
response = "response" "=" response-value
response-value = 32LHEX
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
cipher = "cipher" "=" cipher-value
authzid = "authzid" "=" <"> authzid-value <">
authzid-value = qdstr-val
username
The user's name in the specified realm, encoded according to the
value of the "charset" directive. This directive is required and
MUST be present exactly once; otherwise, authentication fails.
realm
The realm containing the user's account. This directive is
required if the server provided any realms in the
"digest-challenge", in which case it may appear exactly once and
its value SHOULD be one of those realms. If the directive is
missing, "realm-value" will set to the empty string when computing
A1 (see below for details).
nonce
The server-specified data string received in the preceding
digest-challenge. This directive is required and MUST be present
exactly once; otherwise, authentication fails.
Leach & Newman Standards Track [Page 7]
RFC 2831 Digest SASL Mechanism May 2000
cnonce
A client-specified data string which MUST be different each time a
digest-response is sent as part of initial authentication. The
cnonce-value is an opaque quoted string value provided by the
client and used by both client and server to avoid chosen
plaintext attacks, and to provide mutual authentication. The
security of the implementation depends on a good choice. It is
RECOMMENDED that it contain at least 64 bits of entropy. This
directive is required and MUST be present exactly once; otherwise,
authentication fails.
nonce-count
The nc-value is the hexadecimal count of the number of requests
(including the current request) that the client has sent with the
nonce value in this request. For example, in the first request
sent in response to a given nonce value, the client sends
"nc=00000001". The purpose of this directive is to allow the
server to detect request replays by maintaining its own copy of
this count - if the same nc-value is seen twice, then the request
is a replay. See the description below of the construction of
the response value. This directive may appear at most once; if
multiple instances are present, the client should abort the
authentication exchange.
qop
Indicates what "quality of protection" the client accepted. If
present, it may appear exactly once and its value MUST be one of
the alternatives in qop-options. If not present, it defaults to
"auth". These values affect the computation of the response. Note
that this is a single token, not a quoted list of alternatives.
serv-type
Indicates the type of service, such as "www" for web service,
"ftp" for FTP service, "smtp" for mail delivery service, etc. The
service name as defined in the SASL profile for the protocol see
section 4 of [RFC 2222], registered in the IANA registry of
"service" elements for the GSSAPI host-based service name form
[RFC 2078].
host
The DNS host name or IP address for the service requested. The
DNS host name must be the fully-qualified canonical name of the
host. The DNS host name is the preferred form; see notes on server
processing of the digest-uri.
Leach & Newman Standards Track [Page 8]
RFC 2831 Digest SASL Mechanism May 2000
serv-name
Indicates the name of the service if it is replicated. The service
is considered to be replicated if the client's service-location
process involves resolution using standard DNS lookup operations,
and if these operations involve DNS records (such as SRV, or MX)
which resolve one DNS name into a set of other DNS names. In this
case, the initial name used by the client is the "serv-name", and
the final name is the "host" component. For example, the incoming
mail service for "example.com" may be replicated through the use
of MX records stored in the DNS, one of which points at an SMTP
server called "mail3.example.com"; it's "serv-name" would be
"example.com", it's "host" would be "mail3.example.com". If the
service is not replicated, or the serv-name is identical to the
host, then the serv-name component MUST be omitted.
digest-uri
Indicates the principal name of the service with which the client
wishes to connect, formed from the serv-type, host, and serv-name.
For example, the FTP service on "ftp.example.com" would have a
"digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
the example above would have a "digest-uri" value of
"smtp/mail3.example.com/example.com".
Servers SHOULD check that the supplied value is correct. This will
detect accidental connection to the incorrect server. It is also so
that clients will be trained to provide values that will work with
implementations that use a shared back-end authentication service
that can provide server authentication.
The serv-type component should match the service being offered. The
host component should match one of the host names of the host on
which the service is running, or it's IP address. Servers SHOULD NOT
normally support the IP address form, because server authentication
by IP address is not very useful; they should only do so if the DNS
is unavailable or unreliable. The serv-name component should match
one of the service's configured service names.
This directive may appear at most once; if multiple instances are
present, the client should abort the authentication exchange.
Note: In the HTTP use of Digest authentication, the digest-uri is the
URI (usually a URL) of the resource requested -- hence the name of
the directive.
response
A string of 32 hex digits computed as defined below, which proves
that the user knows a password. This directive is required and
MUST be present exactly once; otherwise, authentication fails.
Leach & Newman Standards Track [Page 9]
RFC 2831 Digest SASL Mechanism May 2000
maxbuf
A number indicating the size of the largest buffer the client is
able to receive. If this directive is missing, the default value
is 65536. This directive may appear at most once; if multiple
instances are present, the server should abort the authentication
exchange.
charset
This directive, if present, specifies that the client has used
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 client should send this directive only
if the server has indicated it supports UTF-8. The directive is
needed for backwards compatibility with HTTP Digest, which only
supports ISO 8859-1.
LHEX
32 hex digits, where the alphabetic characters MUST be lower case,
because MD5 is not case insensitive.
cipher
The cipher chosen by the client. This directive MUST appear
exactly once if "auth-conf" is negotiated; if required and not
present, authentication fails.
authzid
The "authorization ID" as per RFC 2222, encoded in UTF-8. This
directive is optional. If present, and the authenticating user has
sufficient privilege, and the server supports it, then after
authentication the server will use this identity for making all
accesses and access checks. If the client specifies it, and the
server does not support it, then the response-value will be
incorrect, and authentication will fail.
The size of a digest-response MUST be less than 4096 bytes.
2.1.2.1 Response-value
The definition of "response-value" above indicates the encoding for
its value -- 32 lower case hex characters. The following definitions
show how the value is computed.
Although qop-value and components of digest-uri-value may be
case-insensitive, the case which the client supplies in step two is
preserved for the purpose of computing and verifying the
response-value.
response-value =
Leach & Newman Standards Track [Page 10]
RFC 2831 Digest SASL Mechanism May 2000
HEX( KD ( HEX(H(A1)),
{ nonce-value, ":" nc-value, ":",
cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
If authzid is specified, then A1 is
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value, ":", authzid-value }
If authzid is not specified, then A1 is
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value }
where
passwd = *OCTET
The "username-value", "realm-value" and "passwd" are encoded
according to the value of the "charset" directive. If "charset=UTF-8"
is present, and all the characters of either "username-value" or
"passwd" are in the ISO 8859-1 character set, then it must be
converted to ISO 8859-1 before being hashed. This is so that
authentication databases that store the hashed username, realm and
password (which is common) can be shared compatibly with HTTP, which
specifies ISO 8859-1. A sample implementation of this conversion is
in section 8.
If the "qop" directive's value is "auth", then A2 is:
A2 = { "AUTHENTICATE:", digest-uri-value }
If the "qop" value is "auth-int" or "auth-conf" then A2 is:
A2 = { "AUTHENTICATE:", digest-uri-value,
":00000000000000000000000000000000" }
Note that "AUTHENTICATE:" must be in upper case, and the second
string constant is a string with a colon followed by 32 zeros.
These apparently strange values of A2 are for compatibility with
HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
the hash of the entity body to zero in the HTTP digest calculation of
A2.
Also, in the HTTP usage of Digest, several directives in the
Leach & Newman Standards Track [Page 11]
RFC 2831 Digest SASL Mechanism May 2000
"digest-challenge" sent by the server have to be returned by the
client in the "digest-response". These are:
opaque
algorithm
These directives are not needed when Digest is used as a SASL
mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
2.1.3 Step Three
The server receives and validates the "digest-response". The server
checks that the nonce-count is "00000001". If it supports subsequent
authentication (see section 2.2), it saves the value of the nonce and
the nonce-count. It sends a message formatted as follows:
response-auth = "rspauth" "=" response-value
where response-value is calculated as above, using the values sent in
step two, except that if qop is "auth", then A2 is
A2 = { ":", digest-uri-value }
And if qop is "auth-int" or "auth-conf" then A2 is
A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
Compared to its use in HTTP, the following Digest directives in the
"digest-response" are unused:
nextnonce
qop
cnonce
nonce-count