5 Digest Authentication as a SASL Mechanism September 1998
8 Network Working Group Paul J. Leach, Microsoft
9 INTERNET-DRAFT Chris Newman, Innosoft
10 draft-leach-digest-sasl-03.txt
11 Category: Standards Track
12 Expires September 31, 1999 March 31, 1999
16 Using Digest Authentication as a SASL Mechanism
27 This document is an Internet-Draft and is in full conformance with all
28 provisions of Section 10 of RFC2026.
30 THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT. IT DOES NOT REPRESENT
31 THE CONSENSUS OF ANY WORKING GROUP.
33 Internet-Drafts are working documents of the Internet Engineering Task
34 Force (IETF), its areas, and its working groups. Note that other groups
35 may also distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet- Drafts as reference material
40 or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html.
48 Distribution of this document is unlimited. Please send comments to the
49 authors or the SASL mailing list, ietf-sasl@imc.org.
51 Copyright Notice: Copyright (C) The Internet Society (1998). All Rights
52 Reserved. See section 8 for the full copyright notice.
57 This specification defines how HTTP Digest Authentication [Digest] can
58 be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL
59 profile. It is intended both as an improvement over CRAM-MD5 [RFC2195]
60 and as a convenient way to support a single authentication mechanism for
61 web, mail, LDAP, and other protocols.
63 Leach, Newman Standards Track [Page 1]
69 Digest Authentication as a SASL Mechanism September 1998
75 1 INTRODUCTION.............................ERROR! BOOKMARK NOT DEFINED.
77 1.1 CONVENTIONS AND NOTATION.........................................3
79 1.2 REQUIREMENTS.....................................................4
82 2 AUTHENTICATION......................................................4
84 2.1 INITIAL AUTHENTICATION...........................................4
86 2.1.1 Step One......................................................4
88 2.1.2 Step Two......................................................6
90 2.1.3 Step Three...................................................11
92 2.2 SUBSEQUENT AUTHENTICATION.......................................11
94 2.2.1 Step one.....................................................12
96 2.2.2 Step Two.....................................................12
98 2.3 INTEGRITY PROTECTION............................................12
101 3 SECURITY CONSIDERATIONS............................................14
103 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION...........14
105 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS...................14
107 3.3 REPLAY ATTACKS..................................................15
109 3.4 ONLINE DICTIONARY ATTACKS.......................................15
111 3.5 OFFLINE DICTIONARY ATTACKS......................................15
113 3.6 MAN IN THE MIDDLE...............................................15
115 3.7 CHOSEN PLAINTEXT ATTACKS........................................15
117 3.8 SPOOFING BY COUNTERFEIT SERVERS.................................16
119 3.9 STORING PASSWORDS...............................................16
121 3.10SUMMARY.........................................................16
124 4 EXAMPLE............................................................17
126 5 REFERENCES.........................................................17
128 6 AUTHORS' ADDRESSES.................................................18
131 Leach, Newman Standards Track [Page 2]
137 Digest Authentication as a SASL Mechanism September 1998
140 7 ABNF...............................................................19
142 7.1 AUGMENTED BNF...................................................19
144 7.2 BASIC RULES.....................................................20
147 8 SAMPLE CODE........................................................21
149 9 FULL COPYRIGHT STATEMENT...........................................22
156 This specification describes the use of HTTP Digest Access
157 Authentication as a SASL mechanism. The authentication type associated
158 with the Digest SASL mechanism is "DIGEST-MD5".
160 This specification is intended to be upward compatible with the "md5-
161 sess" algorithm of HTTP/1.1 Digest Access Authentication specified in
162 [Digest]. The only difference in the "md5-sess" algorithm is that some
163 directives not needed in a SASL mechanism have had their values
166 There is one new feature for use as a SASL mechanism: integrity
167 protection on application protocol messages after an authentication
170 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
171 attacks, and permits the use of third party authentication servers,
172 mutual authentication, and optimized reauthentication if a client has
173 recently authenticated to a server.
176 1.1 Conventions and Notation
178 This specification uses the same ABNF notation and lexical conventions
179 as HTTP/1.1 specification; see appendix A.
181 Let { a, b, ... } be the concatenation of the strings a, b, à
183 Let H(s) be the 16 octet MD5 hash of the string s.
185 Let KD(k, s) be the 16 octet MD5 hash of the concatenation of the string
186 k, ":" (a 1 character long string consisting of a colon), and the string
189 Let HEX(n) be the representation of the 16 octet MD5 hash n as a string
190 of 32 hex digits (with alphabetic characters always in lower case),
191 since MD5 is case sensitive.
198 Leach, Newman Standards Track [Page 3]
204 Digest Authentication as a SASL Mechanism September 1998
210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
212 document are to be interpreted as described in RFC 2119 [RFC 2119].
214 An implementation is not compliant if it fails to satisfy one or more of
215 the MUST level requirements for the protocols it implements. An
216 implementation that satisfies all the MUST level and all the SHOULD
217 level requirements for its protocols is said to be "unconditionally
218 compliant"; one that satisfies all the MUST level requirements but not
219 all the SHOULD level requirements for its protocols is said to be
220 "conditionally compliant."
225 The following sections describe how to use Digest as a SASL
226 authentication mechanism.
229 2.1 Initial Authentication
231 If the client has not recently authenticated to the server, then it must
232 perform "initial authentication", as defined in this section. If it has
233 recently authenticated, then a more efficient form is available, defined
239 The server starts by sending a challenge. The data encoded in the
240 challenge contains a string formatted according to the rules for a
241 "digest-challenge" defined as follows:
243 digest-challenge = 1#( realm | nonce | qop-options | stale |
244 maxbuf | charset | cipher-opts | auth-param )
247 realm = "realm" "=" <"> realm-value <">
248 realm-value = qdstr-val
249 nonce = "nonce" "=" <"> nonce-value <">
250 nonce-value = qdstr-val
251 qop-options = "qop" "=" <"> qop-list <">
252 qop-list = 1#qop-value
253 qop-value = "auth" | "auth-int" | "auth-conf" |
255 stale = "stale" "=" "true"
256 maxbuf = "maxbuf" "=" maxbuf-value
257 maxbuf-value = 1*DIGIT
258 charset = "charset" "=" "utf-8"
259 algorithm = "algorithm" "=" "md5-sess"
260 cipher-opts = "cipher" "=" 1#cipher-value
261 cipher-value = "3des" | "des" | "rc4-40" | "rc4" | "rc4-56" | token
263 Leach, Newman Standards Track [Page 4]
269 Digest Authentication as a SASL Mechanism September 1998
272 auth-param = token "=" ( token | quoted-string )
274 The meanings of the values of the directives used above are as follows:
278 Mechanistically, a string to be displayed to users so they know which
279 username and password to use. Conceptually, it is the name of a
280 collection of accounts which might include the user's account. This
281 string should contain at least the name of the host performing the
282 authentication and might additionally indicate the collection of
283 users who might have access. An example might be
284 "registered_users@gotham.news.example.com". This directive is
285 optional; if not present, the client MUST solicit it from the user or
286 have been configured to use a default; a plausible default might be
287 the realm supplied by the user when they logged in to the client
288 system. Multiple realm directives are allowed.
292 A server-specified data string which MUST be different each time a
293 digest-challenge is sent as part of initial authentication. It is
294 recommended that this string be base64 or hexadecimal data. Note that
295 since the string is passed as a quoted string, the double-quote
296 character is not allowed. The contents of the nonce are
297 implementation dependent. The security of the implementation depends
298 on a good choice. It is RECOMMENDED that it contain at least 64 bits
299 of entropy. The nonce is opaque to the client. This directive is
300 required and may appear exactly once; if not present, or if multiple
301 instances are present, the client should abort the authentication
306 A quoted string of one or more tokens indicating the "quality of
307 protection" values supported by the server. The value "auth"
308 indicates authentication; the value "auth-int" indicates
309 authentication with integrity protection; the value "auth-conf"
310 indicates authentication with integrity protection and encryption.
311 The value is optional; if not present it defaults to "auth". The
312 client MUST ignore unrecognized options; if the client recognizes no
313 option, it should abort the authentication exchange.
317 The "stale" directive is not used in initial authentication. See the
318 next section for its use in subsequent authentications.
322 A number indicating the size of the largest buffer the server is able
323 to receive when using "auth-int" or "auth-conf". If this directive is
324 missing, the default value is 65536. This directive may appear at
325 most once; if multiple instances are present, the client should abort
326 the authentication exchange.
331 Leach, Newman Standards Track [Page 5]
337 Digest Authentication as a SASL Mechanism September 1998
341 This directive, if present, specifies that the server supports UTF-8
342 encoding for the username and password. If not present, the username
343 and password must be encoded in ISO 8859-1 (of which US-ASCII is a
344 subset). The directive is needed for backwards compatibility with
345 HTTP Digest, which only supports ISO 8859-1.
349 This directive is required for backwards compatibility with HTTP
350 Digest., which supports other algorithms.
354 A list of ciphers that the server supports. The "3des" and "des"
355 modes are mandatory-to-implement. This directive must be present
356 exactly once if "auth-conf" is offered. The client MUST ignore
357 unrecognized options; if the client recognizes no option, it should
358 abort the authentication exchange.
362 the Data Encryption Standard (DES) cipher [FIPS] in cipher block
363 chaining (CBC) mode with a 56 bit key.
367 the "triple DES" cipher in CBC mode with EDE with the same key for
368 each E stage (aka "two keys mode") for a total key length of 112
373 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively.
377 This directive allows for future extensions. The client MUST ignore
378 any unrecognized directive.
380 For use as a SASL mechanism, note that the following changes are made to
381 "digest-challenge" from HTTP: the following Digest options (called
382 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
383 and MUST be ignored if received):
389 The size of a digest-challenge MUST be less than 2048 bytes.
394 The client makes note of the "digest-challenge" and then responds with a
395 string formatted and computed according to the rules for a "digest-
396 response" defined as follows:
398 digest-response = 1#( username | realm | nonce | cnonce |
399 nonce-count | qop | digest-uri | response |
402 Leach, Newman Standards Track [Page 6]
408 Digest Authentication as a SASL Mechanism September 1998
411 maxbuf | charset | cipher | authzid | auth-param )
413 username = "username" "=" <"> username-value <">
414 username-value = qdstr-val
415 cnonce = "cnonce" "=" <"> cnonce-value <">
416 cnonce-value = qdstr-val
417 nonce-count = "nc" "=" nc-value
419 qop = "qop" "=" qop-value
420 digest-uri = "digest-uri" "=" digest-uri-value
421 digest-uri-value = serv-type "/" host [ "/" serv-name ]
423 host = 1*( ALPHA | DIGIT | "-" | "." )
425 response = "response" "=" <"> response-value <">
426 response-value = 32LHEX
427 LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
428 "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"
429 cipher = "cipher" "=" cipher-value
430 authzid = "authzid" = authzid-value
431 authzid-value = qdstrval
437 The user's name in the specified realm, encoded as UTF-8. This
438 directive is required; if not present, authentication fails.
442 The realm containing the user's account. It MUST be one of the realms
443 from the "digest-challenge", if any were provided. This directive is
444 required unless the server did not provide any realms; otherwise, if
445 not present, or not one of the ones in the "digest-challenge",
446 authentication fails.
450 The server-specified data string received in the preceding digest-
451 challenge. This directive is required; if not present, authentication
456 A client-specified data string which MUST be different each time a
457 digest-response is sent as part of initial authentication. The
458 cnonce-value is an opaque quoted string value provided by the client
459 and used by both client and server to avoid chosen plaintext attacks,
460 and to provide mutual authentication. The security of the
461 implementation depends on a good choice. It is RECOMMENDED that it
462 contain at least 64 bits of entropy. This directive is required; if
463 not present, authentication fails.
466 Leach, Newman Standards Track [Page 7]
472 Digest Authentication as a SASL Mechanism September 1998
476 The nc-value is the hexadecimal count of the number of requests
477 (including the current request) that the client has sent with the
478 nonce value in this request. For example, in the first request sent
479 in response to a given nonce value, the client sends "nc=00000001".
480 The purpose of this directive is to allow the server to detect
481 request replays by maintaining its own copy of this count - if the
482 same nc-value is seen twice, then the request is a replay. See the
483 description below of the construction of the response value.
487 Indicates what "quality of protection" the client accepted. If
488 present, its value MUST be one of the alternatives in qop-options. If
489 not present, it defaults to "auth". These values affect the
490 computation of the response. Note that this is a single token, not a
491 quoted list of alternatives.
495 Indicates the type of service, such as "www" for web service, "ftp"
496 for FTP service, "smtp" for mail delivery service, etc. The service
497 name as defined in the SASL profile for the protocol see section 4 of
498 [RFC 2222], registered in the IANA registry of "service" elements for
499 the GSSAPI host-based service name form [RFC 2078]. Regardless of
500 case, they are lower cased when used in hash computations.
504 The DNS host name or IP address for the service requested. The DNS
505 host name must be the fully-qualified canonical name of the host.
506 The DNS host name is the preferred form; see notes on server
507 processing of the digest-uri.
511 Indicates the name of the service if it is replicated. The service is
512 considered to be replicated if the client's service-location process
513 involves resolution using standard DNS lookup operations, and if
514 these operations involve DNS records (such as SRV, or MX) which
515 resolve one DNS name into a set of other DNS names. In this case, the
516 initial name used by the client is the "serv-name", and the final
517 name is the "host" component. For example, the incoming mail service
518 for "example.com" may be replicated through the use of MX records
519 stored in the DNS, one of which points at an SMTP server called
520 "mail3.example.com"; it's "serv-name" would be "example.com", it's
521 "host" would be "mail3.example.com". If the service is not
522 replicated, or the serv-name is identical to the host, then the serv-
523 name component MUST be omitted.
527 Indicates the principal name of the service with which the client
528 wishes to connect, formed from the serv-type, host, and serv-name.
529 For example, the FTP service on "ftp.example.com" would have a
530 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from the
534 Leach, Newman Standards Track [Page 8]
540 Digest Authentication as a SASL Mechanism September 1998
543 example above would have a "digest-uri" value of
544 "smtp/mail3.example.com/example.com".
547 Servers SHOULD check that the supplied value is correct. This will
548 detect accidental connection to the incorrect server. It is also so
549 that clients will be trained to provide values that will work with
550 implementations that use a shared back-end authentication service
551 that can provide server authentication.
554 The serv-type component should match the service being offered. The
555 host component should match one of the host names of the host on
556 which the service is running, or it's IP address. Servers SHOULD NOT
557 normally support the IP address form, because server authentication
558 by IP address is not very useful; they should only do so if the DNS
559 is unavailable or unreliable. The serv-name component should match
560 one of the service's configured service names.
563 Note: In the HTTP use of Digest authentication, the digest-uri is the
564 URI (usually a URL) of the resource requested -- hence the name of
569 A string of 32 hex digits computed as defined below, which proves
570 that the user knows a password. This directive is required; if not
571 present, authentication fails.
575 A number indicating the size of the largest buffer the client is able
576 to receive. If this directive is missing, the default value is 65536.
577 This directive may appear at most once; if multiple instances are
578 present, the server should abort the authentication exchange.
582 This directive, if present, specifies that the client has used UTF-8
583 encoding for the username and password. If not present, the username
584 and password must be encoded in ISO 8859-1 (of which US-ASCII is a
585 subset). The client should send this directive only if the server has
586 indicated it supports UTF-8. The directive is needed for backwards
587 compatibility with HTTP Digest, which only supports ISO 8859-1.
591 32 hex digits, where the alphabetic characters MUST be lower case,
592 because MD5 is not case insensitive.
596 The cipher chosen by the client. This directive MUST appear exactly
597 once if "auth-conf" is negotiated; if required and not present,
598 authentication fails.
602 The "authorization ID" as per RFC 2222, encoded in UTF-8. This
605 Leach, Newman Standards Track [Page 9]
611 Digest Authentication as a SASL Mechanism September 1998
614 directive is optional. If present, and the authenticating user has
615 sufficient privilege, and the server supports it, then after
616 authentication the server will use this identity for making all
617 accesses and access checks. If the client specifies it, and the
618 server does not support it, then the response-value will be
619 incorrect, and authentication will fail.
621 The size of a digest-response MUST be less than 2048 bytes.
624 2.1.2.1 Response-value
626 The definition of "response-value" above indicates the encoding for its
627 value -- 32 lower case hex characters. The following definitions show
628 how the value is computed.
631 HEX( KD ( HEX(H(A1)),
632 { nonce-value, ":" nc-value, ":",
633 cnonce-value, ":", qop-value, ":", HEX(H(A2))}))
635 If authzid is specified, then A1 is
638 A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
639 ":", nonce-value, ":", cnonce-value, ":", authzid-value }
641 If authzid is not specified, then A1 is
644 A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
645 ":", nonce-value, ":", cnonce-value }
651 The "username-value", "realm-value" and "passwd" are encoded according
652 to the value of the "charset" directive. If "charset=UTF-8" is present,
653 and all the characters of either "username-value" or "passwd" are in the
654 ISO 8859-1 character set, then it must be converted to ISO 8859-1 before
655 being hashed. This is so that authentication databases that store the
656 hashed username, realm and password (which is common) can be shared
657 compatibly with HTTP, which specifies ISO 8859-1. A sample
658 implementation of this conversion is in section 8.
660 If the "qop" directive's value is "auth", then A2 is:
662 A2 = { "AUTHENTICATE:", digest-uri-value }
666 Leach, Newman Standards Track [Page 10]
672 Digest Authentication as a SASL Mechanism September 1998
675 If the "qop" value is "auth-int" or "auth-conf" then A2 is:
677 A2 = { "AUTHENTICATE:", digest-uri-value,
678 ":00000000000000000000000000000000" }
680 Note that "AUTHENTICATE:" must be in upper case, and the second string
681 constant is a string with a colon followed by 32 zeros.
683 These apparently strange values of A2 are for compatibility with HTTP;
684 they were arrived at by setting "Method" to "AUTHENTICATE" and the hash
685 of the entity body to zero in the HTTP digest calculation of A2.
687 Also, in the HTTP usage of Digest, several directives in the "digest-
688 challenge" sent by the server have to be returned by the client in the
689 "digest-response". These are:
695 These directives are not needed when Digest is used as a SASL mechanism
696 (i.e., MUST NOT be sent, and MUST be ignored if received).
701 The server receives and validates the "digest-response". The server
702 checks that the nonce-count is "00000001". If it supports subsequent
703 authentication (see section 2.2), it saves the value of the nonce and
704 the nonce-count. It sends a message formatted as follows:
706 response-auth = "rspauth" "=" response-value
708 where response-value is calculated as above, using the values sent in
709 step two, except that if qop is "auth", then A2 is
711 A2 = { ":", digest-uri-value }
713 And if qop is "auth-int" or "auth-conf" then A2 is
715 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
717 Compared to its use in HTTP, the following Digest directives in the
718 "digest-response" are unused:
725 2.2 Subsequent Authentication
727 If the client has previously authenticated to the server, and remembers
728 the values of username, realm, nonce, nonce-count, cnonce, and qop that
729 it used in that authentication, and the SASL profile for a protocol
731 Leach, Newman Standards Track [Page 11]
737 Digest Authentication as a SASL Mechanism September 1998
740 permits an initial client response, then it MAY perform "subsequent
741 authentication", as defined in this section.
746 The client uses the values from the previous authentication and sends an
747 initial response with a string formatted and computed according to the
748 rules for a "digest-response", as defined above, but with a nonce-count
749 one greater than used in the last "digest-response".
754 The server receives the "digest-response". If the server does not
755 support subsequent authentication, then it sends a "digest-challenge",
756 and authentication proceeds as in initial authentication. If the server
757 has no saved nonce and nonce-count from a previous authentication, then
758 it sends a "digest-challenge", and authentication proceeds as in initial
759 authentication. Otherwise, the server validates the "digest-response",
760 checks that the nonce-count is one greater than that used in the
761 previous authentication using that nonce, and saves the new value of
764 If the response is invalid, then the server sends a "digest-challenge",
765 and authentication proceeds as in initial authentication (and should be
766 configurable to log an authentication failure in some sort of security
767 audit log, since the failure may be a symptom of an attack). The nonce-
768 count MUST NOT be incremented in this case: to do so would allow a
769 denial of service attack by sending an out-of-order nonce-count.
771 If the response is valid, the server MAY choose to deem that
772 authentication has succeeded. However, if it has been too long since the
773 previous authentication, or for any other reason, the server MAY send a
774 new "digest-challenge" with a new value for nonce. The challenge MAY
775 contain a "stale" directive with value "true", which says that the
776 client may respond to the challenge using the password it used in the
777 previous response; otherwise, the client must solicit the password anew
778 from the user. This permits the server to make sure that the user has
779 presented their password recently. (The directive name refers to the
780 previous nonce being stale, not to the last use of the password.) Except
781 for the handling of "stale", after sending the "digest-challenge"
782 authentication proceeds as in the case of initial authentication.
785 2.3 Integrity Protection
787 If the server offered "qop=auth-int" and the client responded "qop=auth-
788 int", then subsequent messages, up to but not including the next
789 subsequent authentication, between the client and the server MUST be
790 integrity protected. Using as a base session key the value of H(A1) as
791 defined above the client and server calculate a pair of message
792 integrity keys as follows.
794 The key for integrity protecting messages from client to server is:
798 Leach, Newman Standards Track [Page 12]
804 Digest Authentication as a SASL Mechanism September 1998
807 "Digest session key to client-to-server signing key magic
810 The key for integrity protecting messages from server to client is:
813 "Digest session key to server-to-client signing key magic
816 where MD5 is as specified in [RFC 1321]. If message integrity is
817 negotiated, a MAC for each message is appended to the message. The MAC
818 is 16 bytes: a 2-byte message type number in network byte order with
819 value 1, the first 10 bytes of the HMAC-MD5 [RFC 2104] of the message
820 and the 4-byte sequence number in network byte order. The message type
821 is to allow for future extensions such as rekeying.
823 MAC(Ki, SeqNum, msg) = (0x00001, HMAC(Ki, (SeqNum, msg))[0..7], SeqNum)
825 where Ki is Kic for messages sent by the client and Kis for those sent
826 by the server. The sequence number is initialized to zero, and
827 incremented by one for each message sent.
829 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
830 received value; the message is discarded if they differ.
833 2.4 Confidentiality Protection
835 If the server sent a "cipher-opts" directive and the client responded
836 with a "cipher" directive, then subsequent messages between the client
837 and the server MUST be confidentiality protected. Using as a base
838 session key the value of H(A1) as defined above the client and server
839 calculate a pair of message integrity keys as follows.
841 The key for confidentiality protecting messages from client to server
844 Kcc = MD5(H(A1)[0..n],
845 "Digest H(A1) to client-to-server sealing key magic constant")
847 The key for confidentiality protecting messages from server to client
850 Kcs = MD5(H(A1)[0..n],
851 "Digest H(A1) to server-to-client sealing key magic constant")
853 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for
854 "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers is
855 all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the
856 key for "3des" is the first 14 bytes. The IV for "des" and "3des" is the
857 last 8 bytes of Kcc or Kcs.
859 If message confidentiality is negotiated, each message is encrypted
860 with the chosen cipher and a MAC is appended to the message.
863 Leach, Newman Standards Track [Page 13]
869 Digest Authentication as a SASL Mechanism September 1998
872 The MAC is a variable length padding prefix followed by 16 bytes
873 formatted as follows: a 2-byte message type number in network byte order
874 with value 1, the first 10 bytes of the HMAC-MD5 [RFC 2104] of the
875 message and the 4-byte sequence number in network byte order. If the
876 blocksize of the chosen cipher is not 1 byte, the padding prefix is one
877 or more octets each containing the number of padding bytes such that
878 length of the message plus the length of the padding prefix is a
879 multiple of the blocksize.
881 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, { msg, pad}), CMAC(Ki, Kc,
883 CMAC(Ki, Kc, SeqNum, msg) =
884 { 0x00000001, CIPHER(Kc, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum }
886 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
887 messages sent by the client and Kis and Kcs for those sent by the
888 server. The sequence number is initialized to zero, and incremented by
889 one for each message sent.
891 Upon receipt, the message is decrypted, CMAC(Ki, Ke, SeqNum, msg) is
892 computed and compared with the received value; the message is discarded
896 3 Security Considerations
899 3.1 Authentication of Clients using Digest Authentication
901 Digest Authentication does not provide a strong authentication
902 mechanism, when compared to public key based mechanisms, for example.
903 However, since it prevents chosen plaintext attacks, it is stronger than
904 (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and
905 IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and
906 even more dangerous use of plaintext passwords; however, since it is
907 still a password based mechanism it avoids some of the potential
908 deployabilty issues with public-key, OTP or similar mechanisms.
910 Digest Authentication offers no confidentiality protection beyond
911 protecting the actual password. All of the rest of the challenge
912 and response are available to an eavesdropper, including the
913 user's name and authentication realm.
916 3.2 Comparison of Digest with Plaintext Passwords
918 The greatest threat to the type of transactions for which these
919 protocols are used is network snooping. This kind of transaction
920 might involve, for example, online access to a mail service whose
921 use is restricted to paying subscribers. With plaintext password
922 authentication an eavesdropper can obtain the password of the
923 user. This not only permits him to access anything in the
924 database, but, often worse, will permit access to anything else
925 the user protects with the same password.
929 Leach, Newman Standards Track [Page 14]
935 Digest Authentication as a SASL Mechanism September 1998
941 Replay attacks are defeated if the client or the server chooses a
942 fresh nonce for each authentication, as this specification
946 3.4 Online dictionary attacks
948 If the attacker can eavesdrop, then it can test any overheard
949 nonce/response pairs against a (potentially very large) list of common
950 words. Such a list is usually much smaller than the total number of
951 possible passwords. The cost of computing the response for each password
952 on the list is paid once for each challenge.
954 The server can mitigate this attack by not allowing users to select
955 passwords that are in a dictionary.
958 3.5 Offline dictionary attacks
960 If the attacker can choose the challenge, then it can precompute the
961 possible responses to that challenge for a list of common words. Such a
962 list is usually much smaller than the total number of possible
963 passwords. The cost of computing the response for each password on the
964 list is paid just once.
966 Offline dictionary attacks are defeated if the client chooses a fresh
967 nonce for each authentication, as this specification requires.
970 3.6 Man in the Middle
972 Digest authentication is vulnerable to "man in the middle" (MITM)
973 attacks. Clearly, a MITM would present all the problems of
974 eavesdropping. But it also offers some additional opportunities to the
977 A possible man-in-the-middle attack would be to substitute a weaker qop
978 scheme for the one(s) sent by the server; the server will not be able to
979 detect this attack. For this reason, the client should always use the
980 strongest scheme that it understands from the choices offered, and
981 should never choose a scheme that does not meet its minimum
985 3.7 Chosen plaintext attacks
987 A chosen plaintext attack is where a MITM or a malicious server can
988 arbitrarily choose the challenge that the client will use to compute the
989 response. The ability to choose the challenge is known to make
990 cryptanalysis much easier [8].
992 However, Digest does not permit the attack to choose the challenge as
993 long as the client chooses a fresh nonce for each authentication, as
994 this specification requires.
998 Leach, Newman Standards Track [Page 15]
1004 Digest Authentication as a SASL Mechanism September 1998
1008 3.8 Spoofing by Counterfeit Servers
1010 If a user can be led to believe that she is connecting to a host
1011 containing information protected by a password she knows, when in fact
1012 she is connecting to a hostile server, then the hostile server can
1013 obtain challenge/response pairs where it was able to partly choose the
1014 challenge. There is no known way that this can be exploited.
1017 3.9 Storing passwords
1019 Digest authentication requires that the authenticating agent (usually
1020 the server) store some data derived from the user's name and password in
1021 a "password file" associated with a given realm. Normally this might
1022 contain pairs consisting of username and H(A1), where H(A1) is the
1023 digested value of the username, realm, and password as described above.
1025 The security implications of this are that if this password file is
1026 compromised, then an attacker gains immediate access to documents on the
1027 server using this realm. Unlike, say a standard UNIX password file, this
1028 information need not be decrypted in order to access documents in the
1029 server realm associated with this file. On the other hand, decryption,
1030 or more likely a brute force attack, would be necessary to obtain the
1031 user's password. This is the reason that the realm is part of the
1032 digested data stored in the password file. It means that if one Digest
1033 authentication password file is compromised, it does not automatically
1034 compromise others with the same username and password (though it does
1035 expose them to brute force attack).
1037 There are two important security consequences of this. First the
1038 password file must be protected as if it contained plaintext passwords,
1039 because for the purpose of accessing documents in its realm, it
1042 A second consequence of this is that the realm string should be unique
1043 among all realms that any single user is likely to use. In particular a
1044 realm string should include the name of the host doing the
1048 3.10 Multiple realms
1050 Use of multiple realms may mean both that compromise of a the security
1051 database for a single realm does not compromise all security, and that
1052 there are more things to protect in order to keep the whole system
1058 By modern cryptographic standards Digest Authentication is weak,
1059 compared to (say) public key based mechanisms. But for a large range of
1060 purposes it is valuable as a replacement for plaintext passwords. Its
1061 strength may vary depending on the implementation.
1066 Leach, Newman Standards Track [Page 16]
1072 Digest Authentication as a SASL Mechanism September 1998
1077 This example shows the use of the Digest SASL mechanism with the IMAP4
1078 AUTHENTICATE command [RFC 2060]. The base64 encoding of the challenges
1079 and responses is part of the IMAP4 AUTHENTICATE command, not part of the
1080 Digest specification itself. (Note: linebreaks added for editorial
1081 clarity are not part of the mechanism):
1084 * OK elwood.innosoft.com IMAP4 Server PMDF5.3-1 at Mon, 28 Sep 1998
1085 09:16:30 -0700 (PDT)
1087 * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE STARTTLS AUTH=CRAM-MD5
1088 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN
1089 c OK CAPABILITY completed
1090 a AUTHENTICATE DIGEST-MD5
1091 + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJENlBpNXVvT2xp
1092 RzI4WFZidVRYQ0l3Iixxb3A9ImF1dGgi
1093 dXNlcm5hbWU9ImNocmlzIixyZWFsbT0iZWx3b29kLmlubm9zb2Z0LmNvbSIsbm
1094 9uY2U9IkQ2UGk1dW9PbGlHMjhYVmJ1VFhDSXciLG5jPTAwMDAwMDAxLGNub25j
1095 ZT0iZS9nWG5wRW94ODNzVzNERXU3b1FoZyIscmVzcG9uc2U9IjRmNjA2NTBhYW
1096 FmNDQxNzkyOWViNjg3Zjc2NmNlOTMyIixxb3A9ImF1dGgi
1097 a OK AUTHENTICATE completed
1100 Decoding the base64, gets:
1102 realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw",qop="auth
1107 username="chris",realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVb
1109 nc=00000001,cnonce="e/gXnpEox83sW3DEu7oQhg",
1110 response="4f60650aaaf4417929eb687f766ce932",qop="auth"
1112 The password was "secret".
1114 The server uses the values of all the directives, plus knowledge of the
1115 users password (or the hash of the userÆs name, serverÆs realm and the
1116 userÆs password) to verify the computations above. If they check, then
1117 the user has authenticated.
1123 [RFC 2069] Franks, J., et. al., "An Extension to HTTP : Digest Access Authentication", January, 1997
1126 [ISO-8859] ISO-8859. International Standard -- Information Processing --
1127 8-bit Single-Byte Coded Graphic Character Sets --
1128 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
1131 Leach, Newman Standards Track [Page 17]
1137 Digest Authentication as a SASL Mechanism September 1998
1140 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
1141 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
1142 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
1143 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
1144 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
1145 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
1146 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
1147 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
1150 [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet Text
1151 Messages," STD 11, RFC 822, UDEL, August 1982.
1154 [RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
1158 [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
1159 Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
1160 University of Tennessee, November 1996.
1163 [RFC 2052] A. Gulbrandsen, P. Vixie, A DNS RR for specifying the
1164 location of services (DNS SRV). October 1996.
1167 [RFC 2060] Crispin, "Internet Message Access Protocol - Version 4rev1",
1168 RFC 2060, University of Washington, December 1996.
1171 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
1172 for Message Authentication", RFC 2104, 02/05/1997
1175 [RFC2195] Klensin, J., et. al., "IMAP/POP AUTHorize Extension for Simple
1176 Challenge/Response", RFC 2195, September, 1997.
1179 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1180 Requirement Levels," RFC 2119, Harvard University, March 1997.
1183 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code
1184 for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
1187 6 Authors' Addresses
1193 paulle@microsoft.com
1196 Innosoft International, Inc.
1198 West Covina, CA 91790 USA
1199 chris.newman@innosoft.com
1201 Leach, Newman Standards Track [Page 18]
1207 Digest Authentication as a SASL Mechanism September 1998
1215 All of the mechanisms specified in this document are described in both
1216 prose and an augmented Backus-Naur Form (BNF) similar to that used by
1217 RFC 822 [RFC 822]. Implementors will need to be familiar with the
1218 notation in order to understand this specification. The augmented BNF
1219 includes the following constructs:
1223 The name of a rule is simply the name itself (without any enclosing
1224 "<" and ">") and is separated from its definition by the equal "="
1225 character. White space is only significant in that indentation of
1226 continuation lines is used to indicate a rule definition that spans
1227 more than one line. Certain basic rules are in uppercase, such as SP,
1228 LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within
1229 definitions whenever their presence will facilitate discerning the
1234 Quotation marks surround literal text. Unless stated otherwise, the
1235 text is case-insensitive.
1239 Elements separated by a bar ("|") are alternatives, e.g., "yes | no"
1240 will accept yes or no.
1244 Elements enclosed in parentheses are treated as a single element.
1245 Thus, "(elem (foo | bar) elem)" allows the token sequences
1246 "elem foo elem" and "elem bar elem".
1250 The character "*" preceding an element indicates repetition. The full
1251 form is "<n>*<m>element" indicating at least <n> and at most <m>
1252 occurrences of element. Default values are 0 and infinity so that
1253 "*(element)" allows any number, including zero; "1*element" requires
1254 at least one; and "1*2element" allows one or two.
1258 Square brackets enclose optional elements; "[foo bar]" is equivalent
1263 Specific repetition: "<n>(element)" is equivalent to
1264 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
1265 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
1266 alphabetic characters.
1270 A construct "#" is defined, similar to "*", for defining lists of
1272 Leach, Newman Standards Track [Page 19]
1278 Digest Authentication as a SASL Mechanism September 1998
1281 elements. The full form is "<n>#<m>element" indicating at least <n>
1282 and at most <m> elements, each separated by one or more commas (",")
1283 and OPTIONAL linear white space (LWS). This makes the usual form of
1284 lists very easy; a rule such as
1285 ( *LWS element *( *LWS "," *LWS element ))
1288 Wherever this construct is used, null elements are allowed, but do
1289 not contribute to the count of elements present. That is, "(element),
1290 , (element) " is permitted, but counts as only two elements.
1291 Therefore, where at least one element is required, at least one non-
1292 null element MUST be present. Default values are 0 and infinity so
1293 that "#element" allows any number, including zero; "1#element"
1294 requires at least one; and "1#2element" allows one or two.
1298 A semi-colon, set off some distance to the right of rule text, starts
1299 a comment that continues to the end of line. This is a simple way of
1300 including useful notes in parallel with the specifications.
1304 Except where noted otherwise, linear white space ("LWS") can be
1305 included between any adjacent "token", "quoted-string", or
1306 "separators" constructs, as these are defined in the basic rules
1307 below; such LWS is ignored.
1312 The following rules are used throughout this specification to describe
1313 basic parsing constructs. The US-ASCII coded character set is defined by
1314 ANSI X3.4-1986 [USASCII].
1316 OCTET = <any 8-bit sequence of data>
1317 CHAR = <any US-ASCII character (octets 0 - 127)>
1318 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
1319 LOALPHA = <any US-ASCII lowercase letter "a".."z">
1320 ALPHA = UPALPHA | LOALPHA
1321 DIGIT = <any US-ASCII digit "0".."9">
1322 CTL = <any US-ASCII control character
1323 (octets 0 - 31) and DEL (127)>
1324 CR = <US-ASCII CR, carriage return (13)>
1325 LF = <US-ASCII LF, linefeed (10)>
1326 SP = <US-ASCII SP, space (32)>
1327 HT = <US-ASCII HT, horizontal-tab (9)>
1328 <"> = <US-ASCII double-quote mark (34)>
1330 All linear white space, including folding, has the same semantics as SP.
1331 A recipient MAY replace any linear white space with a single SP before
1332 interpreting the field value or forwarding the message downstream.
1334 LWS = [CRLF] 1*( SP | HT )
1339 Leach, Newman Standards Track [Page 20]
1345 Digest Authentication as a SASL Mechanism September 1998
1348 The TEXT rule is only used for descriptive field contents and values
1349 that are not intended to be interpreted by the message parser. Words of
1350 *TEXT MAY contain characters from character sets other than ISO-8859-1
1351 [ISO 8859]only when encoded according to the rules of RFC 2047 [RFC
1354 TEXT = <any OCTET except CTLs,
1357 A CRLF is allowed in the definition of TEXT only as part of a header
1358 field continuation. It is expected that the folding LWS will be replaced
1359 with a single SP before interpretation of the TEXT value.
1361 Hexadecimal numeric characters are used in several protocol elements.
1363 HEX = "A" | "B" | "C" | "D" | "E" | "F"
1364 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
1366 Many HTTP/1.1 header field values consist of words separated by LWS or
1367 special characters. These special characters MUST be in a quoted string
1368 to be used within a parameter value.
1370 token = 1*<any CHAR except CTLs or separators>
1371 separators = "(" | ")" | "<" | ">" | "@"
1372 | "," | ";" | ":" | "\" | <">
1373 | "/" | "[" | "]" | "?" | "="
1374 | "{" | "}" | SP | HT
1376 A string of text is parsed as a single word if it is quoted using
1379 quoted-string = ( <"> qdstr-val <"> )
1380 qdstr-val = *(qdtext | quoted-pair )
1381 qdtext = <any TEXT except <">>
1383 The backslash character ("\") MAY be used as a single-character quoting
1384 mechanism only within qdstr-val and comment constructs.
1386 quoted-pair = "\" CHAR
1388 The value of this construct is CHAR. Note that an effect of this rule is
1389 that backslash must be quoted.
1394 The sample implementation in [Digest] also applies to DIGEST-MD5.
1396 The following code implements the conversion from UTF-8 to 8859-1 if
1403 Leach, Newman Standards Track [Page 21]
1409 Digest Authentication as a SASL Mechanism September 1998
1413 /* if the string is entirely in the 8859-1 subset of UTF-8, then
1415 * to 8859-1 prior to MD5
1417 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, int
1420 const unsigned char *scan, *end;
1424 for (scan = base; scan < end; ++scan) {
1425 if (*scan > 0xC3) break; /* abort if outside 8859-1 */
1426 if (*scan >= 0xC0 && *scan <= 0xC3) {
1427 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
1431 /* if we found a character outside 8859-1, don't alter string
1434 MD5Update(ctx, base, len);
1438 /* convert to 8859-1 prior to applying hash
1441 for (scan = base; scan < end && *scan < 0xC0; ++scan)
1443 if (scan != base) MD5Update(ctx, base, scan - base);
1444 if (scan + 1 >= end) break;
1445 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
1446 MD5Update(ctx, &cbuf, 1);
1448 } while (base < end);
1452 9 Full Copyright Statement
1454 Copyright (C) The Internet Society (1998). All Rights Reserved.
1456 This document and translations of it may be copied and furnished to
1457 others, and derivative works that comment on or otherwise explain it or
1458 assist in its implmentation may be prepared, copied, published and
1459 distributed, in whole or in part, without restriction of any kind,
1460 provided that the above copyright notice and this paragraph are included
1461 on all such copies and derivative works. However, this document itself
1462 may not be modified in any way, such as by removing the copyright notice
1463 or references to the Internet Society or other Internet organizations,
1464 except as needed for the purpose of developing Internet standards in
1465 which case the procedures for copyrights defined in the Internet
1468 Leach, Newman Standards Track [Page 22]
1474 Digest Authentication as a SASL Mechanism September 1998
1477 Standards process must be followed, or as required to translate it into
1478 languages other than English.
1480 The limited permissions granted above are perpetual and will not be
1481 revoked by the Internet Society or its successors or assigns.
1483 This document and the information contained herein is provided on an "AS
1484 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
1485 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
1486 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1487 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
1488 FITNESS FOR A PARTICULAR PURPOSE.
1532 Leach, Newman Standards Track [Page 23]