As per Relevance of the word mechanism, we have this rfc below:
Network Working Group P.
Request for Comments: 2831
Category: Standards Track C.
May 2000
Using Digest Authentication as a SASL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This specification defines how HTTP Digest Authentication [Digest
can be used as a SASL [RFC 2222] mechanism for any protocol that
a SASL profile. It is intended both as an improvement over CRAM-MD
[RFC 2195] and as a convenient way to support a single
mechanism for web, mail, LDAP, and other protocols
Table of
1 INTRODUCTION.....................................................2
1.1 CONVENTIONS AND NOTATION......................................2
1.2 REQUIREMENTS..................................................3
2 AUTHENTICATION...................................................3
2.1 INITIAL AUTHENTICATION........................................3
2.1.1 Step One...................................................3
2.1.2 Step Two...................................................6
2.1.3 Step Three................................................12
2.2 SUBSEQUENT AUTHENTICATION....................................12
2.2.1 Step one..................................................13
2.2.2 Step Two..................................................13
2.3 INTEGRITY PROTECTION.........................................13
2.4 CONFIDENTIALITY PROTECTION...................................14
3 SECURITY CONSIDERATIONS.........................................15
3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........15
3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................16
3.3 REPLAY ATTACKS...............................................16
Leach & Newman Standards Track [Page 1]
RFC 2831 Digest SASL Mechanism May 2000
3.4 ONLINE DICTIONARY ATTACKS....................................16
3.5 OFFLINE DICTIONARY ATTACKS...................................16
3.6 MAN IN THE MIDDLE............................................17
3.7 CHOSEN PLAINTEXT ATTACKS.....................................17
3.8 SPOOFING BY COUNTERFEIT SERVERS..............................17
3.9 STORING PASSWORDS............................................17
3.10 MULTIPLE REALMS.............................................18
3.11 SUMMARY.....................................................18
4 EXAMPLE.........................................................18
5 REFERENCES......................................................20
6 AUTHORS' ADDRESSES..............................................21
7 ABNF............................................................21
7.1 AUGMENTED BNF................................................21
7.2 BASIC RULES..................................................23
8 SAMPLE CODE.....................................................25
9 FULL COPYRIGHT STATEMENT........................................27
1
This specification describes the use of HTTP Digest
Authentication as a SASL mechanism. The authentication
associated with the Digest SASL mechanism is "DIGEST-MD5".
This specification is intended to be upward compatible with
"md5-sess" algorithm of HTTP/1.1 Digest Access
specified in [Digest]. The only difference in the "md5-sess
algorithm is that some directives not needed in a SASL mechanism
had their values defaulted
There is one new feature for use as a SASL mechanism:
protection on application protocol messages after an
exchange
Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen
attacks, and permits the use of third party authentication servers
mutual authentication, and optimized reauthentication if a client
recently authenticated to a server
1.1 Conventions and
This specification uses the same ABNF notation and
conventions as HTTP/1.1 specification; see appendix A
Let { a, b, ... } be the concatenation of the octet strings a, b, ...
Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s
Leach & Newman Standards Track [Page 2]
RFC 2831 Digest SASL Mechanism May 2000
Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the
k, a colon and the string s
Let HEX(n) be the representation of the 16 octet MD5 hash n as
string of 32 hex digits (with alphabetic characters always in
case, since MD5 is case sensitive).
Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the
string s using the octet string k as a key
The value of a quoted string constant as an octet string does
include any terminating null character
1.2
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC 2119].
An implementation is not compliant if it fails to satisfy one or
of the MUST level requirements for the protocols it implements.
implementation that satisfies all the MUST level and all the
level requirements for its protocols is said to be "
compliant"; one that satisfies all the MUST level requirements
not all the SHOULD level requirements for its protocols is said to
"conditionally compliant."
2
The following sections describe how to use Digest as a
authentication mechanism
2.1 Initial
If the client has not recently authenticated to the server, then
must perform "initial authentication", as defined in this section.
it has recently authenticated, then a more efficient form
available, defined in the next section
2.1.1 Step
The server starts by sending a challenge. The data encoded in
challenge contains a string formatted according to the rules for
"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 |
algorithm | cipher-opts | auth-param )
realm = "realm" "=" <"> realm-value <">
realm-value = qdstr-
nonce = "nonce" "=" <"> nonce-value <">
nonce-value = qdstr-
qop-options = "qop" "=" <"> qop-list <">
qop-list = 1#qop-
qop-value = "auth" | "auth-int" | "auth-conf" |
stale = "stale" "=" "true
maxbuf = "maxbuf" "=" maxbuf-
maxbuf-value = 1*
charset = "charset" "=" "utf-8"
algorithm = "algorithm" "=" "md5-sess
cipher-opts = "cipher" "=" <"> 1#cipher-value <">
cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
"rc4-56" |
auth-param = token "=" ( token | quoted-string )
The meanings of the values of the directives used above are
follows
Mechanistically, a string which can enable users to know
username and password to use, in case they might have
ones for different servers. Conceptually, it is the name of
collection of accounts that might include the user's account.
string should contain at least the name of the host performing
authentication and might additionally indicate the collection
users who might have access. An example might
"registered_users@gotham.news.example.com". This directive
optional; if not present, the client SHOULD solicit it from
user or be able to compute a default; a plausible default might
the realm supplied by the user when they logged in to the
system. Multiple realm directives are allowed, in which case
user or client must choose one as the realm for which to supply
username and password
A server-specified data string which MUST be different each time
digest-challenge is sent as part of initial authentication. It
recommended that this string be base64 or hexadecimal data.
that since the string is passed as a quoted string,
double-quote character is not allowed unless escaped (see
7.2). The contents of the nonce are implementation dependent.
Leach & Newman Standards Track [Page 4]
RFC 2831 Digest SASL Mechanism May 2000
security of the implementation depends on a good choice. It
RECOMMENDED that it contain at least 64 bits of entropy. The
is opaque to the client. This directive is required and
appear exactly once; if not present, or if multiple instances
present, the client should abort the authentication exchange
qop-
A quoted string of one or more tokens indicating the "quality
protection" values supported by the server. The value "auth
indicates authentication; the value "auth-int"
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
recognizes no option, it should abort the authentication exchange
The "stale" directive is not used in initial authentication.
the next section for its use in subsequent authentications.
directive may appear at most once; if multiple instances
present, the client should abort the authentication exchange
A number indicating the size of the largest buffer the server
able to receive when using "auth-int" or "auth-conf". If
directive is missing, the default value is 65536. This
may appear at most once; if multiple instances are present,
client should abort the authentication exchange
This directive, if present, specifies that the server
UTF-8 encoding for the username and password. If not present,
username and password must be encoded in ISO 8859-1 (of
US-ASCII is a subset). The directive is needed for
compatibility with HTTP Digest, which only supports ISO 8859-1.
This directive may appear at most once; if multiple instances
present, the client should abort the authentication exchange
This directive is required for backwards compatibility with
Digest., which supports other algorithms. . This directive
required and MUST appear exactly once; if not present, or
multiple instances are present, the client should abort
authentication exchange
Leach & Newman Standards Track [Page 5]
RFC 2831 Digest SASL Mechanism May 2000
cipher-
A list of ciphers that the server supports. This directive must
present exactly once if "auth-conf" is offered in
"qop-options" directive, in which case the "3des" and "des"
are mandatory-to-implement. The client MUST ignore
options; if the client recognizes no option, it should abort
authentication exchange
the Data Encryption Standard (DES) cipher [FIPS] in
block chaining (CBC) mode with a 56 bit key
3
the "triple DES" cipher in CBC mode with EDE with the same
for each E stage (aka "two keys mode") for a total key
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
more than once. The client MUST ignore any
directives
For use as a SASL mechanism, note that the following changes are
to "digest-challenge" from HTTP: the following Digest options (
"directives" in HTTP terminology) are unused (i.e., MUST NOT be sent
and MUST be ignored if received):
The size of a digest-challenge MUST be less than 2048 bytes
2.1.2 Step
The client makes note of the "digest-challenge" and then
with a string formatted and computed according to the rules for
"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-
cnonce = "cnonce" "=" <"> cnonce-value <">
cnonce-value = qdstr-
nonce-count = "nc" "=" nc-
nc-value = 8
qop = "qop" "=" qop-
digest-uri = "digest-uri" "=" <"> digest-uri-value <">
digest-uri-value = serv-type "/" host [ "/" serv-name ]
serv-type = 1*
host = 1*( ALPHA | DIGIT | "-" | "." )
serv-name =
response = "response" "=" response-
response-value = 32
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f
cipher = "cipher" "=" cipher-
authzid = "authzid" "=" <"> authzid-value <">
authzid-value = qdstr-
The user's name in the specified realm, encoded according to
value of the "charset" directive. This directive is required
MUST be present exactly once; otherwise, authentication fails
The realm containing the user's account. This directive
required if the server provided any realms in
"digest-challenge", in which case it may appear exactly once
its value SHOULD be one of those realms. If the directive
missing, "realm-value" will set to the empty string when
A1 (see below for details).
The server-specified data string received in the
digest-challenge. This directive is required and MUST be
exactly once; otherwise, authentication fails
Leach & Newman Standards Track [Page 7]
RFC 2831 Digest SASL Mechanism May 2000
A client-specified data string which MUST be different each time
digest-response is sent as part of initial authentication.
cnonce-value is an opaque quoted string value provided by
client and used by both client and server to avoid
plaintext attacks, and to provide mutual authentication.
security of the implementation depends on a good choice. It
RECOMMENDED that it contain at least 64 bits of entropy.
directive is required and MUST be present exactly once; otherwise
authentication fails
nonce-
The nc-value is the hexadecimal count of the number of
(including the current request) that the client has sent with
nonce value in this request. For example, in the first
sent in response to a given nonce value, the client
"nc=00000001". The purpose of this directive is to allow
server to detect request replays by maintaining its own copy
this count - if the same nc-value is seen twice, then the
is a replay. See the description below of the construction
the response value. This directive may appear at most once;
multiple instances are present, the client should abort
authentication exchange
Indicates what "quality of protection" the client accepted.
present, it may appear exactly once and its value MUST be one
the alternatives in qop-options. If not present, it defaults
"auth". These values affect the computation of the response.
that this is a single token, not a quoted list of alternatives
serv-
Indicates the type of service, such as "www" for web service
"ftp" for FTP service, "smtp" for mail delivery service, etc.
service name as defined in the SASL profile for the protocol
section 4 of [RFC 2222], registered in the IANA registry
"service" elements for the GSSAPI host-based service name
[RFC 2078].
The DNS host name or IP address for the service requested.
DNS host name must be the fully-qualified canonical name of
host. The DNS host name is the preferred form; see notes on
processing of the digest-uri
Leach & Newman Standards Track [Page 8]
RFC 2831 Digest SASL Mechanism May 2000
serv-
Indicates the name of the service if it is replicated. The
is considered to be replicated if the client's service-
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
case, the initial name used by the client is the "serv-name",
the final name is the "host" component. For example, the
mail service for "example.com" may be replicated through the
of MX records stored in the DNS, one of which points at an
server called "mail3.example.com"; it's "serv-name" would
"example.com", it's "host" would be "mail3.example.com". If
service is not replicated, or the serv-name is identical to
host, then the serv-name component MUST be omitted
digest-
Indicates the principal name of the service with which the
wishes to connect, formed from the serv-type, host, and serv-name
For example, the FTP service on "ftp.example.com" would have
"digest-uri" value of "ftp/ftp.example.com"; the SMTP server
the example above would have a "digest-uri" value
"smtp/mail3.example.com/example.com".
Servers SHOULD check that the supplied value is correct. This
detect accidental connection to the incorrect server. It is also
that clients will be trained to provide values that will work
implementations that use a shared back-end authentication
that can provide server authentication
The serv-type component should match the service being offered.
host component should match one of the host names of the host
which the service is running, or it's IP address. Servers SHOULD
normally support the IP address form, because server
by IP address is not very useful; they should only do so if the
is unavailable or unreliable. The serv-name component should
one of the service's configured service names
This directive may appear at most once; if multiple instances
present, the client should abort the authentication exchange
Note: In the HTTP use of Digest authentication, the digest-uri is
URI (usually a URL) of the resource requested -- hence the name
the directive
A string of 32 hex digits computed as defined below, which
that the user knows a password. This directive is required
MUST be present exactly once; otherwise, authentication fails
Leach & Newman Standards Track [Page 9]
RFC 2831 Digest SASL Mechanism May 2000
A number indicating the size of the largest buffer the client
able to receive. If this directive is missing, the default
is 65536. This directive may appear at most once; if
instances are present, the server should abort the
exchange
This directive, if present, specifies that the client has
UTF-8 encoding for the username and password. If not present,
username and password must be encoded in ISO 8859-1 (of
US-ASCII is a subset). The client should send this directive
if the server has indicated it supports UTF-8. The directive
needed for backwards compatibility with HTTP Digest, which
supports ISO 8859-1.
32 hex digits, where the alphabetic characters MUST be lower case
because MD5 is not case insensitive
The cipher chosen by the client. This directive MUST
exactly once if "auth-conf" is negotiated; if required and
present, authentication fails
The "authorization ID" as per RFC 2222, encoded in UTF-8.
directive is optional. If present, and the authenticating user
sufficient privilege, and the server supports it, then
authentication the server will use this identity for making
accesses and access checks. If the client specifies it, and
server does not support it, then the response-value will
incorrect, and authentication will fail
The size of a digest-response MUST be less than 4096 bytes
2.1.2.1 Response-
The definition of "response-value" above indicates the encoding
its value -- 32 lower case hex characters. The following
show how the value is computed
Although qop-value and components of digest-uri-value may
case-insensitive, the case which the client supplies in step two
preserved for the purpose of computing and verifying
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
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value, ":", authzid-value }
If authzid is not specified, then A1
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value }
passwd = *
The "username-value", "realm-value" and "passwd" are
according to the value of the "charset" directive. If "charset=UTF-8"
is present, and all the characters of either "username-value"
"passwd" are in the ISO 8859-1 character set, then it must
converted to ISO 8859-1 before being hashed. This is so
authentication databases that store the hashed username, realm
password (which is common) can be shared compatibly with HTTP,
specifies ISO 8859-1. A sample implementation of this conversion
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
string constant is a string with a colon followed by 32 zeros
These apparently strange values of A2 are for compatibility
HTTP; they were arrived at by setting "Method" to "AUTHENTICATE"
the hash of the entity body to zero in the HTTP digest calculation
A2.
Also, in the HTTP usage of Digest, several directives in
Leach & Newman Standards Track [Page 11]
RFC 2831 Digest SASL Mechanism May 2000
"digest-challenge" sent by the server have to be returned by
client in the "digest-response". These are
These directives are not needed when Digest is used as a
mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
2.1.3 Step
The server receives and validates the "digest-response". The
checks that the nonce-count is "00000001". If it supports
authentication (see section 2.2), it saves the value of the nonce
the nonce-count. It sends a message formatted as follows
response-auth = "rspauth" "=" response-
where response-value is calculated as above, using the values sent
step two, except that if qop is "auth", then A2
A2 = { ":", digest-uri-value }
And if qop is "auth-int" or "auth-conf" then A2
A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
Compared to its use in HTTP, the following Digest directives in
"digest-response" are unused
nonce-
2.2 Subsequent
If the client has previously authenticated to the server,
remembers the values of username, realm, nonce, nonce-count, cnonce
and qop that it used in that authentication, and the SASL profile
a protocol permits an initial client response, then it MAY
"subsequent authentication", as defined in this section
Leach & Newman Standards Track [Page 12]
RFC 2831 Digest SASL Mechanism May 2000
2.2.1 Step
The client uses the values from the previous authentication and
an initial response with a string formatted and computed according
the rules for a "digest-response", as defined above, but with
nonce-count one greater than used in the last "digest-response".
2.2.2 Step
The server receives the "digest-response". If the server does
support subsequent authentication, then it sends
"digest-challenge", and authentication proceeds as in
authentication. If the server has no saved nonce and nonce-count
a previous authentication, then it sends a "digest-challenge",
authentication proceeds as in initial authentication. Otherwise,
server validates the "digest-response", checks that the nonce-
is one greater than that used in the previous authentication
that nonce, and saves the new value of nonce-count
If the response is invalid, then the server sends
"digest-challenge", and authentication proceeds as in
authentication (and should be configurable to log an
failure in some sort of security audit log, since the failure may
a symptom of an attack). The nonce-count MUST NOT be incremented
this case: to do so would allow a denial of service attack by
an out-of-order nonce-count
If the response is valid, the server MAY choose to deem
authentication has succeeded. However, if it has been too long
the previous authentication, or for any other reason, the server
send a new "digest-challenge" with a new value for nonce.
challenge MAY contain a "stale" directive with value "true",
says that the client may respond to the challenge using the
it used in the previous response; otherwise, the client must
the password anew from the user. This permits the server to make
that the user has presented their password recently. (The
name refers to the previous nonce being stale, not to the last use
the password.) Except for the handling of "stale", after sending
"digest-challenge" authentication proceeds as in the case of
authentication
2.3 Integrity
If the server offered "qop=auth-int" and the client
"qop=auth-int", then subsequent messages, up to but not including
next subsequent authentication, between the client and the
Leach & Newman Standards Track [Page 13]
RFC 2831 Digest SASL Mechanism May 2000
MUST be integrity protected. Using as a base session key the value
H(A1) as defined above the client and server calculate a pair
message integrity keys as follows
The key for integrity protecting messages from client to server is
Kic = MD5({H(A1),
"Digest session key to client-to-server signing key magic constant"})
The key for integrity protecting messages from server to client is
Kis = MD5({H(A1),
"Digest session key to server-to-client signing key magic constant"})
where MD5 is as specified in [RFC 1321]. If message integrity
negotiated, a MAC block for each message is appended to the message
The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [
2104] of the message, a 2-byte message type number in network
order with value 1, and the 4-byte sequence number in network
order. The message type is to allow for future extensions such
rekeying
MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
SeqNum
where Ki is Kic for messages sent by the client and Kis for
sent by the server. The sequence number is initialized to zero,
incremented by one for each message sent
Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with
received value; the message is discarded if they differ
2.4 Confidentiality
If the server sent a "cipher-opts" directive and the client
with a "cipher" directive, then subsequent messages between
client and the server MUST be confidentiality protected. Using as
base session key the value of H(A1) as defined above the client
server calculate a pair of message integrity keys as follows
The key for confidentiality protecting messages from client to
is
Kcc = MD5({H(A1)[0..n],
"Digest H(A1) to client-to-server sealing key magic constant"})
The key for confidentiality protecting messages from server to
is
Leach & Newman Standards Track [Page 14]
RFC 2831 Digest SASL Mechanism May 2000
Kcs = MD5({H(A1)[0..n],
"Digest H(A1) to server-to-client sealing key magic constant"})
where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*"
ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the
7 bytes; the key for "3des" is the first 14 bytes. The IV for "des
and "3des" is the last 8 bytes of Kcc or Kcs
If message confidentiality is negotiated, each message is
with the chosen cipher and a MAC block is appended to the message
The MAC block is a variable length padding prefix followed by 16
bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [
2104] of the message, a 2-byte message type number in network
order with value 1, and the 4-byte sequence number in network
order. If the blocksize of the chosen cipher is not 1 byte,
padding prefix is one or more octets each containing the number
padding bytes, such that total length of the encrypted part of
message is a multiple of the blocksize. The padding and first 10
bytes of the MAC block are encrypted along with the message
SEAL(Ki, Kc, SeqNum, msg) =
{CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,
SeqNum
where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc
messages sent by the client and Kis and Kcs for those sent by
server. The sequence number is initialized to zero, and
by one for each message sent
Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg})
computed and compared with the received value; the message
discarded if they differ
3 Security
3.1 Authentication of Clients using Digest
Digest Authentication does not provide a strong
mechanism, when compared to public key based mechanisms, for example
However, since it prevents chosen plaintext attacks, it is
than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10],
POP and IMAP (see RFC 2195 [9]). It is intended to replace the
weaker and even more dangerous use of plaintext passwords; however
since it is still a password based mechanism it avoids some of
potential deployabilty issues with public-key, OTP or
mechanisms
Leach & Newman Standards Track [Page 15]
RFC 2831 Digest SASL Mechanism May 2000
Digest Authentication offers no confidentiality protection
protecting the actual password. All of the rest of the challenge
response are available to an eavesdropper, including the user's
and authentication realm
3.2 Comparison of Digest with Plaintext
The greatest threat to the type of transactions for which
protocols are used is network snooping. This kind of
might involve, for example, online access to a mail service whose
is restricted to paying subscribers. With plaintext
authentication an eavesdropper can obtain the password of the user
This not only permits him to access anything in the database, but
often worse, will permit access to anything else the user
with the same password
3.3 Replay
Replay attacks are defeated if the client or the server chooses
fresh nonce for each authentication, as this specification requires
3.4 Online dictionary
If the attacker can eavesdrop, then it can test any
nonce/response pairs against a (potentially very large) list
common words. Such a list is usually much smaller than the
number of possible passwords. The cost of computing the response
each password on the list is paid once for each challenge
The server can mitigate this attack by not allowing users to
passwords that are in a dictionary
3.5 Offline dictionary
If the attacker can choose the challenge, then it can precompute
possible responses to that challenge for a list of common words.
a list is usually much smaller than the total number of
passwords. The cost of computing the response for each password
the list is paid just once
Offline dictionary attacks are defeated if the client chooses a
nonce for each authentication, as this specification requires
Leach & Newman Standards Track [Page 16]
RFC 2831 Digest SASL Mechanism May 2000
3.6 Man in the
Digest authentication is vulnerable to "man in the middle" (MITM
attacks. Clearly, a MITM would present all the problems
eavesdropping. But it also offers some additional opportunities
the attacker
A possible man-in-the-middle attack would be to substitute a
qop scheme for the one(s) sent by the server; the server will not
able to detect this attack. For this reason, the client should
use the strongest scheme that it understands from the
offered, and should never choose a scheme that does not meet
minimum requirements
3.7 Chosen plaintext
A chosen plaintext attack is where a MITM or a malicious server
arbitrarily choose the challenge that the client will use to
the response. The ability to choose the challenge is known to
cryptanalysis much easier [8].
However, Digest does not permit the attack to choose the challenge
long as the client chooses a fresh nonce for each authentication,
this specification requires
3.8 Spoofing by Counterfeit
If a user can be led to believe that she is connecting to a
containing information protected by a password she knows, when
fact she is connecting to a hostile server, then the hostile
can obtain challenge/response pairs where it was able to
choose the challenge. There is no known way that this can
exploited
3.9 Storing
Digest authentication requires that the authenticating agent (
the server) store some data derived from the user's name and
in a "password file" associated with a given realm. Normally
might contain pairs consisting of username and H({ username-value
":", realm-value, ":", passwd }), which is adequate to compute H(A1)
as described above without directly exposing the user's password
The security implications of this are that if this password file
compromised, then an attacker gains immediate access to documents
the server using this realm. Unlike, say a standard UNIX
file, this information need not be decrypted in order to
documents in the server realm associated with this file. On the
Leach & Newman Standards Track [Page 17]
RFC 2831 Digest SASL Mechanism May 2000
hand, decryption, or more likely a brute force attack, would
necessary to obtain the user's password. This is the reason that
realm is part of the digested data stored in the password file.
means that if one Digest authentication password file is compromised
it does not automatically compromise others with the same
and password (though it does expose them to brute force attack).
There are two important security consequences of this. First
password file must be protected as if it contained
passwords, because for the purpose of accessing documents in
realm, it effectively does
A second consequence of this is that the realm string should
unique among all realms that any single user is likely to use.
particular a realm string should include the name of the host
the authentication
3.10 Multiple
Use of multiple realms may mean both that compromise of a
security database for a single realm does not compromise
security, and that there are more things to protect in order to
the whole system secure
3.11
By modern cryptographic standards Digest Authentication is weak
compared to (say) public key based mechanisms. But for a large
of purposes it is valuable as a replacement for plaintext passwords
Its strength may vary depending on the implementation
4
This example shows the use of the Digest SASL mechanism with
IMAP4 AUTHENTICATE command [RFC 2060].
In this example, "C:" and "S:" represent a line sent by the client
server respectively including a CRLF at the end. Linebreaks
indentation within a "C:" or "S:" are editorial and not part of
protocol. The password in this example was "secret". Note that
base64 encoding of the challenges and responses is part of the IMAP
AUTHENTICATE command, not part of the Digest specification itself
S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
C: c
S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE
UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=
S: c OK
Leach & Newman Standards Track [Page 18]
RFC 2831 Digest SASL Mechanism May 2000
C: a AUTHENTICATE DIGEST-MD
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9
ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4
ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg
S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C
S: a OK User logged
---
The base64-decoded version of the SASL exchange is
S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
algorithm=md5-sess,charset=utf-8
C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
digest-uri="imap/elwood.innosoft.com",
response=d388dad90d4bbd760a152321f2143af7,qop=
S: rspauth=ea40f60335c427b5527b84
The password in this example was "secret".
This example shows the use of the Digest SASL mechanism with
ACAP, using the same notational conventions and password as in
previous example. Note that ACAP does not base64 encode and
fewer round trips that IMAP4.
S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
"DIGEST-MD5" "PLAIN")
C: a AUTHENTICATE "DIGEST-MD5"
S: + {94}
S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
algorithm=md5-sess,charset=utf-8
C: {206}
C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
digest-uri="acap/elwood.innosoft.com",
response=6084c6db3fede7352c551284490fd0fc,qop=
S: a OK (SASL {40}
S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "
Completed
---
Leach & Newman Standards Track [Page 19]
RFC 2831 Digest SASL Mechanism May 2000
The server uses the values of all the directives, plus knowledge
the users password (or the hash of the user's name, server's
and the user's password) to verify the computations above. If
check, then the user has authenticated
5
[Digest] Franks, J., et al., "HTTP Authentication: Basic and
Access Authentication", RFC 2617, June 1999.
[ISO-8859] ISO-8859. International Standard--Information Processing--
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[RFC 822] Crocker, D., "Standard for The Format of ARPA
Text Messages," STD 11, RFC 822, August 1982.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
location of services (DNS SRV)", RFC 2052, October 1996.
[RFC 2060] Crispin, M., "Internet Message Access Protocol -
4rev1", RFC 2060, December 1996.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104,
1997.
[RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/
AUTHorize Extension for Simple Challenge/Response",
2195, September 1997.
Leach & Newman Standards Track [Page 20]
RFC 2831 Digest SASL Mechanism May 2000
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2222] Myers, J., "Simple Authentication and Security
(SASL)", RFC 2222, October 1997.
[USASCII] US-ASCII. Coded Character Set - 7-Bit American
Code for Information Interchange. Standard ANSI X3.4-1986,
ANSI, 1986.
6 Authors'
Paul
1 Microsoft
Redmond, WA 98052
EMail: paulle@microsoft.
Chris
Innosoft International, Inc
1050 Lakes
West Covina, CA 91790
EMail: chris.newman@innosoft.
7
What follows is the definition of the notation as is used in
HTTP/1.1 specification (RFC 2616) and the HTTP
specification (RFC 2617); it is reproduced here for ease
reference. Since it is intended that a single Digest
can support both HTTP and SASL-based protocols, the same notation
used in both to facilitate comparison and prevention of
differences. Since it is cut-and-paste from the HTTP specifications
not all productions may be used in this specification. It is also
quite legal ABNF; again, the errors were copied from the
specifications
7.1 Augmented
All of the mechanisms specified in this document are described
both prose and an augmented Backus-Naur Form (BNF) similar to
used by RFC 822 [RFC 822]. Implementers will need to be familiar
the notation in order to understand this specification
Leach & Newman Standards Track [Page 21]
RFC 2831 Digest SASL Mechanism May 2000
The augmented BNF includes the following constructs
name =
The name of a rule is simply the name itself (without
enclosing "<" and ">") and is separated from its definition by
equal "=" character. White space is only significant in
indentation of continuation lines is used to indicate a
definition that spans more than one line. Certain basic rules
in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
brackets are used within definitions whenever their presence
facilitate discerning the use of rule names
"literal
Quotation marks surround literal text. Unless stated otherwise
the text is case-insensitive
rule1 | rule
Elements separated by a bar ("|") are alternatives, e.g., "yes |
no" will accept yes or no
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element
Thus, "(elem (foo | bar) elem)" allows the token
"elem foo elem" and "elem bar elem".
*
The character "*" preceding an element indicates repetition.
full form is "*element" indicating at least and at
occurrences of element. Default values are 0 and infinity
that "*(element)" allows any number, including zero; "1*element
requires at least one; and "1*2element" allows one or two
[rule
Square brackets enclose optional elements; "[foo bar]"
equivalent to "*1(foo bar)".
N
Specific repetition: "(element)" is equivalent
"*(element)"; that is, exactly occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of
alphabetic characters
#
A construct "#" is defined, similar to "*", for defining lists
elements. The full form is "#element" indicating at
and at most elements, each separated by one or more
(",") and OPTIONAL linear white space (LWS). This makes the
form of lists very easy; a rule such
Leach & Newman Standards Track [Page 22]
RFC 2831 Digest SASL Mechanism May 2000
( *LWS element *( *LWS "," *LWS element ))
can be shown
1#
Wherever this construct is used, null elements are allowed, but
not contribute to the count of elements present. That is
"(element), , (element) " is permitted, but counts as only
elements. Therefore, where at least one element is required,
least one non-null element MUST be present. Default values are 0
and infinity so that "#element" allows any number, including zero
"1#element" requires at least one; and "1#2element" allows one
two
;
A semi-colon, set off some distance to the right of rule text
starts a comment that continues to the end of line. This is
simple way of including useful notes in parallel with
specifications
implied *
The grammar described by this specification is word-based.
where noted otherwise, linear white space (LWS) can be
between any two adjacent words (token or quoted-string),
between adjacent words and separators, without changing
interpretation of a field. At least one delimiter (LWS and/
separators) MUST exist between any two tokens (for the
of "token" below), since they would otherwise be interpreted as
single token
7.2 Basic
The following rules are used throughout this specification
describe basic parsing constructs. The US-ASCII coded character
is defined by ANSI X3.4-1986 [USASCII].
OCTET = sequence of data
CHAR = character (octets 0 - 127)>
UPALPHA =
LOALPHA =
ALPHA = UPALPHA |
DIGIT =
CTL =
(octets 0 - 31) and DEL (127)>
CR =
LF = linefeed (10)>
SP =
HT = horizontal-tab (9)>
<"> =
CRLF = CR
Leach & Newman Standards Track [Page 23]
RFC 2831 Digest SASL Mechanism May 2000
All linear white space, including folding, has the same semantics
SP. A recipient MAY replace any linear white space with a single
before interpreting the field value or forwarding the
downstream
LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and
that are not intended to be interpreted by the message parser.
of *TEXT MAY contain characters from character sets other
ISO-8859-1 [ISO 8859] only when encoded according to the rules of
2047 [RFC 2047].
TEXT =
but including LWS
A CRLF is allowed in the definition of TEXT only as part of a
field continuation. It is expected that the folding LWS will
replaced with a single SP before interpretation of the TEXT value
Hexadecimal numeric characters are used in several protocol elements
HEX = "A" | "B" | "C" | "D" | "E" | "F
| "a" | "b" | "c" | "d" | "e" | "f" |
Many HTTP/1.1 header field values consist of words separated by
or special characters. These special characters MUST be in a
string to be used within a parameter value
token = 1*
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP |
A string of text is parsed as a single word if it is quoted
double-quote marks
quoted-string = ( <"> qdstr-val <"> )
qdstr-val = *( qdtext | quoted-pair )
qdtext = >
Note that LWS is NOT implicit between the double-quote marks (<">)
surrounding a qdstr-val and the qdstr-val; any LWS will be
part of the qdstr-val. This is also the case for quotation
surrounding any other construct
Leach & Newman Standards Track [Page 24]
RFC 2831 Digest SASL Mechanism May 2000
The backslash character ("\") MAY be used as a single-
quoting mechanism only within qdstr-val and comment constructs
quoted-pair = "\"
The value of this construct is CHAR. Note that an effect of this
is that backslash must be quoted
8 Sample
The sample implementation in [Digest] also applies to DIGEST-MD5.
The following code implements the conversion from UTF-8 to 8859-1
necessary
/* if the string is entirely in the 8859-1 subset of UTF-8,
* translate to 8859-1 prior to MD
*/
void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base
int len
{
const unsigned char *scan, *end
unsigned char cbuf
end = base + len
for (scan = base; scan < end; ++scan) {
if (*scan > 0xC3) break; /* abort if outside 8859-1 */
if (*scan >= 0xC0 && *scan <= 0xC3) {
if (++scan == end || *scan < 0x80 || *scan > 0xBF
break
}
}
/* if we found a character outside 8859-1, don't alter
*/
if (scan < end) {
MD5Update(ctx, base, len);
return
}
/* convert to 8859-1 prior to applying
*/
do {
for (scan = base; scan < end && *scan < 0xC0; ++scan
;
if (scan != base) MD5Update(ctx, base, scan - base);
if (scan + 1 >= end) break
cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
MD5Update(ctx, &cbuf, 1);
Leach & Newman Standards Track [Page 25]
RFC 2831 Digest SASL Mechanism May 2000
base = scan + 2;
} while (base < end);
}
Leach & Newman Standards Track [Page 26]
RFC 2831 Digest SASL Mechanism May 2000
9 Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Leach & Newman Standards Track [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
