7 INTERNET-DRAFT P. Leach
8 Obsoletes: 2831 Microsoft
9 Intended category: Standards track C. Newman
15 Using Digest Authentication as a SASL Mechanism
16 draft-melnikov-rfc2831bis-01.txt
20 This document is an Internet-Draft and is in full conformance with
21 all provisions of Section 10 of RFC 2026.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that other
25 groups may also distribute working documents as Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
40 Copyright (C) The Internet Society (2002). All Rights Reserved.
44 This specification defines how HTTP Digest Authentication [Digest]
45 can be used as a SASL [RFC 2222] mechanism for any protocol that has
46 a SASL profile. It is intended both as an improvement over CRAM-MD5
47 [RFC 2195] and as a convenient way to support a single authentication
48 mechanism for web, mail, LDAP, and other protocols.
58 Leach & Newman Expires: December 2002 [Page 1]
64 INTERNET DRAFT Digest SASL Mechanism June 2002
69 1 INTRODUCTION.....................................................3
70 1.1 CONVENTIONS AND NOTATION......................................3
71 1.2 REQUIREMENTS..................................................4
72 2 AUTHENTICATION...................................................5
73 2.1 INITIAL AUTHENTICATION........................................5
74 2.1.1 Step One...................................................5
75 2.1.2 Step Two...................................................9
76 2.1.3 Step Three................................................16
77 2.2 SUBSEQUENT AUTHENTICATION....................................16
78 2.2.1 Step one..................................................17
79 2.2.2 Step Two..................................................17
80 2.3 INTEGRITY PROTECTION.........................................17
81 2.4 CONFIDENTIALITY PROTECTION...................................18
82 3 SECURITY CONSIDERATIONS.........................................19
83 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........19
84 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................20
85 3.3 REPLAY ATTACKS...............................................20
86 3.4 ONLINE DICTIONARY ATTACKS....................................20
87 3.5 OFFLINE DICTIONARY ATTACKS...................................20
88 3.6 MAN IN THE MIDDLE............................................21
89 3.7 CHOSEN PLAINTEXT ATTACKS.....................................21
90 3.8 SPOOFING BY COUNTERFEIT SERVERS..............................21
91 3.9 STORING PASSWORDS............................................21
92 3.10 MULTIPLE REALMS.............................................22
93 3.11 SUMMARY.....................................................22
94 4 EXAMPLE.........................................................22
95 5 REFERENCES......................................................24
96 5.1 NORMATIVE REFERENCES.........................................24
97 5.2 INFORMATIVE REFERENCES.......................................25
98 6 AUTHORS' ADDRESSES..............................................26
99 7 ABNF............................................................27
100 7.1 AUGMENTED BNF................................................27
101 7.2 BASIC RULES..................................................29
102 8 SAMPLE CODE.....................................................31
103 9 INTEROPERABILITY CONSIDERATIONS.................................32
104 9.1 Implementing DES cipher in CBC mode..........................32
105 10 FULL COPYRIGHT STATEMENT.......................................32
106 Appendix A: Changes from 2831.....................................33
107 Appendix B: Open Issues...........................................33
118 Leach & Newman Expires: December 2002 [Page 2]
124 INTERNET DRAFT Digest SASL Mechanism June 2002
129 This specification describes the use of HTTP Digest Access
130 Authentication as a SASL mechanism. The authentication type
131 associated with the Digest SASL mechanism is "DIGEST-MD5".
133 This specification is intended to be upward compatible with the
134 "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication
135 specified in [Digest]. The only difference in the "md5-sess"
136 algorithm is that some directives not needed in a SASL mechanism have
137 had their values defaulted.
139 There is one new feature for use as a SASL mechanism: integrity
140 protection on application protocol messages after an authentication
143 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
144 attacks, and permits the use of third party authentication servers,
145 mutual authentication, and optimized reauthentication if a client has
146 recently authenticated to a server.
148 1.1 Conventions and Notation
150 This specification uses the same ABNF notation and lexical
151 conventions as HTTP/1.1 specification; see section 7.
153 Let { a, b, ... } be the concatenation of the octet strings a, b, ...
155 Let ** denote the power operation.
157 Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
159 Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string
160 k, a colon and the string s.
162 Let HEX(n) be the representation of the 16 octet MD5 hash n as a
163 string of 32 hex digits (with alphabetic characters always in lower
164 case, since MD5 is case sensitive).
166 Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet
167 string s using the octet string k as a key.
178 Leach & Newman Expires: December 2002 [Page 3]
184 INTERNET DRAFT Digest SASL Mechanism June 2002
187 Let unq(X) be the value of the quoted-string X without the
188 surrounding quotes and with all escape characters "\\" removed. For
189 example for the quoted-string "Babylon" the value of unq("Babylon")
190 is Babylon; for the quoted string "ABC\"123\\" the value of
191 unq("ABC\"123\\") is ABC"123\.
193 The value of a quoted string constant as an octet string does not
194 include any terminating null character.
198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
200 document are to be interpreted as described in RFC 2119 [RFC 2119].
202 An implementation is not compliant if it fails to satisfy one or more
203 of the MUST level requirements for the protocols it implements. An
204 implementation that satisfies all the MUST level and all the SHOULD
205 level requirements for its protocols is said to be "unconditionally
206 compliant"; one that satisfies all the MUST level requirements but
207 not all the SHOULD level requirements for its protocols is said to be
208 "conditionally compliant."
238 Leach & Newman Expires: December 2002 [Page 4]
244 INTERNET DRAFT Digest SASL Mechanism June 2002
249 The following sections describe how to use Digest as a SASL
250 authentication mechanism.
252 2.1 Initial Authentication
254 If the client has not recently authenticated to the server, then it
255 must perform "initial authentication", as defined in this section. If
256 it has recently authenticated, then a more efficient form is
257 available, defined in the next section.
261 The server starts by sending a challenge. The data encoded in the
262 challenge contains a string formatted according to the rules for a
263 "digest-challenge" defined as follows:
298 Leach & Newman Expires: December 2002 [Page 5]
304 INTERNET DRAFT Digest SASL Mechanism June 2002
308 1#( realm | nonce | qop-options | stale | maxbuf | charset
309 algorithm | cipher-opts | auth-param )
311 realm = "realm" "=" <"> realm-value <">
312 realm-value = qdstr-val
313 nonce = "nonce" "=" <"> nonce-value <">
314 nonce-value = *qdtext
315 qop-options = "qop" "=" <"> qop-list <">
316 qop-list = 1#qop-value
317 qop-value = "auth" | "auth-int" | "auth-conf" |
319 stale = "stale" "=" "true"
320 maxbuf = "maxbuf" "=" maxbuf-value
321 maxbuf-value = 1*DIGIT
322 charset = "charset" "=" "utf-8"
323 algorithm = "algorithm" "=" "md5-sess"
324 cipher-opts = "cipher" "=" <"> 1#cipher-value <">
325 cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
327 auth-param = token "=" ( token | quoted-string )
329 The meanings of the values of the directives used above are as
333 Mechanistically, a string which can enable users to know which
334 username and password to use, in case they might have different
335 ones for different servers. Conceptually, it is the name of a
336 collection of accounts that might include the user's account. This
337 string should contain at least the name of the host performing the
338 authentication and might additionally indicate the collection of
339 users who might have access. An example might be
340 "registered_users@gotham.news.example.com". This directive is
341 optional; if not present, the client SHOULD solicit it from the
342 user or be able to compute a default; a plausible default might be
343 the realm supplied by the user when they logged in to the client
344 system. Multiple realm directives are allowed, in which case the
345 user or client must choose one as the realm for which to supply to
346 username and password.
349 A server-specified data string which MUST be different each time a
350 digest-challenge is sent as part of initial authentication. It is
351 recommended that this string be base64 or hexadecimal data. Note
352 that since the string is passed as a quoted string, the
353 double-quote character is not allowed unless escaped (see section
354 7.2). The contents of the nonce are implementation dependent. The
358 Leach & Newman Expires: December 2002 [Page 6]
364 INTERNET DRAFT Digest SASL Mechanism June 2002
367 security of the implementation depends on a good choice. It is
368 RECOMMENDED that it contain at least 64 bits of entropy. The nonce
369 is opaque to the client. This directive is required and MUST
370 appear exactly once; if not present, or if multiple instances are
371 present, the client should abort the authentication exchange.
374 A quoted string of one or more tokens indicating the "quality of
375 protection" values supported by the server. The value "auth"
376 indicates authentication; the value "auth-int" indicates
377 authentication with integrity protection; the value "auth-conf"
378 indicates authentication with integrity protection and encryption.
379 This directive is optional; if not present it defaults to "auth".
380 The client MUST ignore unrecognized options; if the client
381 recognizes no option, it should abort the authentication exchange.
384 The "stale" directive is not used in initial authentication. See
385 the next section for its use in subsequent authentications. This
386 directive may appear at most once; if multiple instances are
387 present, the client should abort the authentication exchange.
389 maxbuf ("maximal ciphertext buffer size")
390 A number indicating the size of the largest buffer the server is
391 able to receive when using "auth-int" or "auth-conf". The value
392 MUST be bigger than 16 and smaller or equal to 16777215 (i.e.
393 2**24-1). If this directive is missing, the default value is
394 65536. This directive may appear at most once; if multiple
395 instances are present, the client should abort the authentication
398 Let call "maximal cleartext buffer size" (or "maximal sender
399 size") the maximal size of a cleartext buffer that, after being
400 transformed by integrity (section 2.3) or confidentiality (section
401 2.4) protection function, will produce a SASL block of the maxbuf
402 size. The "maximal sender size" for the client can be calculated
403 by subtracting 16 from the maxbuf value. As it should be clear
404 from the name, the sender MUST never pass a block of data bigger
405 than the "maximal sender size" through the selected protection
406 function. This will guaranty that the receiver will never get a
407 block bigger than the maxbuf.
410 This directive, if present, specifies that the server supports
411 UTF-8 [UTF-8] encoding for the username and password. If present,
412 the username and password MUST be in Unicode Normalization Form KC
413 [UNICODE-NORMALIZATION] (without NUL character) encoded as UTF-8
414 [UTF-8]. If not present, the username and password must be
418 Leach & Newman Expires: December 2002 [Page 7]
424 INTERNET DRAFT Digest SASL Mechanism June 2002
427 encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a
428 subset). The directive is needed for backwards compatibility with
429 HTTP Digest, which only supports ISO 8859-1. This directive may
430 appear at most once; if multiple instances are present, the client
431 should abort the authentication exchange.
434 This directive is required for backwards compatibility with HTTP
435 Digest, which supports other algorithms. This directive is
436 required and MUST appear exactly once; if not present, or if
437 multiple instances are present, the client should abort the
438 authentication exchange.
441 A list of ciphers that the server supports. This directive must be
442 present exactly once if "auth-conf" is offered in the
443 "qop-options" directive, in which case the "3des" cipher is
444 mandatory-to-implement. The client MUST ignore unrecognized
445 options; if the client recognizes no option, it should abort the
446 authentication exchange.
449 the Data Encryption Standard (DES) cipher [FIPS] in cipher
450 block chaining (CBC) mode with a 56 bit key.
453 the "triple DES" cipher in CBC mode with EDE with the same key
454 for each E stage (aka "two keys mode") for a total key length
458 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
461 auth-param This construct allows for future extensions; it may appear
462 more than once. The client MUST ignore any unrecognized
465 For use as a SASL mechanism, note that the following changes are made
466 to "digest-challenge" from HTTP: the following Digest options (called
467 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
468 and MUST be ignored if received):
473 The size of a digest-challenge MUST be less than 2048 bytes.
478 Leach & Newman Expires: December 2002 [Page 8]
484 INTERNET DRAFT Digest SASL Mechanism June 2002
489 The client makes note of the "digest-challenge" and then responds
490 with a string formatted and computed according to the rules for a
491 "digest-response" defined as follows:
493 digest-response = 1#( username | realm | nonce | cnonce |
494 nonce-count | qop | digest-uri | response |
495 maxbuf | charset | cipher | authzid |
498 username = "username" "=" <"> username-value <">
499 username-value = qdstr-val
500 cnonce = "cnonce" "=" <"> cnonce-value <">
501 cnonce-value = *qdtext
502 nonce-count = "nc" "=" nc-value
504 qop = "qop" "=" qop-value
505 digest-uri = "digest-uri" "=" <"> digest-uri-value <">
506 digest-uri-value = serv-type "/" host [ "/" serv-name ]
509 response = "response" "=" response-value
510 response-value = 32LHEX
511 LHEX = "0" | "1" | "2" | "3" |
512 "4" | "5" | "6" | "7" |
513 "8" | "9" | "a" | "b" |
514 "c" | "d" | "e" | "f"
515 cipher = "cipher" "=" cipher-value
516 authzid = "authzid" "=" <"> authzid-value <">
517 authzid-value = qdstr-val
519 The 'host' non-terminal is defined in [RFC 2732] as
521 host = hostname | IPv4address | IPv6reference
522 ipv6reference = "[" IPv6address "]"
524 where IPv6address and IPv4address are defined in [RFC 2373]
525 and 'hostname' is defined in [RFC 2396].
528 The user's name in the specified realm, encoded according to the
529 value of the "charset" directive. This directive is required and
530 MUST be present exactly once; otherwise, authentication fails.
533 The realm containing the user's account. This directive is
534 required if the server provided any realms in the
538 Leach & Newman Expires: December 2002 [Page 9]
544 INTERNET DRAFT Digest SASL Mechanism June 2002
547 "digest-challenge", in which case it may appear exactly once and
548 its value SHOULD be one of those realms. If the directive is
549 missing, "realm-value" will set to the empty string when computing
550 A1 (see below for details).
553 The server-specified data string received in the preceding digest-
554 challenge. This directive is required and MUST be present exactly
555 once; otherwise, authentication fails.
598 Leach & Newman Expires: December 2002 [Page 10]
604 INTERNET DRAFT Digest SASL Mechanism June 2002
608 A client-specified data string which MUST be different each time a
609 digest-response is sent as part of initial authentication. The
610 cnonce-value is an opaque quoted string value provided by the
611 client and used by both client and server to avoid chosen
612 plaintext attacks, and to provide mutual authentication. The
613 security of the implementation depends on a good choice. It is
614 RECOMMENDED that it contain at least 64 bits of entropy. This
615 directive is required and MUST be present exactly once; otherwise,
616 authentication fails.
619 The nc-value is the hexadecimal count of the number of requests
620 (including the current request) that the client has sent with the
621 nonce value in this request. For example, in the first request
622 sent in response to a given nonce value, the client sends
623 "nc=00000001". The purpose of this directive is to allow the
624 server to detect request replays by maintaining its own copy of
625 this count - if the same nc-value is seen twice, then the request
626 is a replay. See the description below of the construction of the
627 response value. This directive is required and MUST be present
628 exactly once; otherwise, authentication fails.
631 Indicates what "quality of protection" the client accepted. If
632 present, it may appear exactly once and its value MUST be one of
633 the alternatives in qop-options. If not present, it defaults to
634 "auth". These values affect the computation of the response. Note
635 that this is a single token, not a quoted list of alternatives.
638 Indicates the type of service, such as "www" for web service,
639 "ftp" for FTP service, "smtp" for mail delivery service, etc. The
640 service name as defined in the SASL profile for the protocol see
641 section 4 of [RFC 2222], registered in the IANA registry of
642 "service" elements for the GSSAPI host-based service name form
646 The DNS host name or IP (IPv4 or IPv6) address for the service
647 requested. The DNS host name must be the fully-qualified
648 canonical name of the host. The DNS host name is the preferred
649 form; see notes on server processing of the digest-uri.
658 Leach & Newman Expires: December 2002 [Page 11]
664 INTERNET DRAFT Digest SASL Mechanism June 2002
668 Indicates the name of the service if it is replicated. The service
669 is considered to be replicated if the client's service-location
670 process involves resolution using standard DNS lookup operations,
671 and if these operations involve DNS records (such as SRV [RFC
672 2052], or MX) which resolve one DNS name into a set of other DNS
673 names. In this case, the initial name used by the client is the
674 "serv-name", and the final name is the "host" component. For
675 example, the incoming mail service for "example.com" may be
676 replicated through the use of MX records stored in the DNS, one of
677 which points at an SMTP server called "mail3.example.com"; it's
678 "serv-name" would be "example.com", it's "host" would be
679 "mail3.example.com". If the service is not replicated, or the
680 serv-name is identical to the host, then the serv-name component
684 Indicates the principal name of the service with which the client
685 wishes to connect, formed from the serv-type, host, and serv-name.
686 For example, the FTP service on "ftp.example.com" would have a
687 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
688 the example above would have a "digest-uri" value of
689 "smtp/mail3.example.com/example.com".
691 Servers SHOULD check that the supplied value is correct. This will
692 detect accidental connection to the incorrect server. It is also so
693 that clients will be trained to provide values that will work with
694 implementations that use a shared back-end authentication service
695 that can provide server authentication.
697 The serv-type component should match the service being offered. The
698 host component should match one of the host names of the host on
699 which the service is running, or it's IP address. Servers SHOULD NOT
700 normally support the IP address form, because server authentication
701 by IP address is not very useful; they should only do so if the DNS
702 is unavailable or unreliable. The serv-name component should match
703 one of the service's configured service names.
705 This directive may appear at most once; if multiple instances are
706 present, the client should abort the authentication exchange.
708 Note: In the HTTP use of Digest authentication, the digest-uri is the
709 URI (usually a URL) of the resource requested -- hence the name of
713 A string of 32 hex digits computed as defined below, which proves
714 that the user knows a password. This directive is required and
718 Leach & Newman Expires: December 2002 [Page 12]
724 INTERNET DRAFT Digest SASL Mechanism June 2002
727 MUST be present exactly once; otherwise, authentication fails.
778 Leach & Newman Expires: December 2002 [Page 13]
784 INTERNET DRAFT Digest SASL Mechanism June 2002
788 A number indicating the size of the largest buffer the client is
789 able to receive. If this directive is missing, the default value
790 is 65536. This directive may appear at most once; if multiple
791 instances are present, the server should abort the authentication
795 This directive, if present, specifies that the client has used
796 UTF-8 [UTF-8] encoding for the username and password. If present,
797 the username and password MUST be in Unicode Normalization Form KC
798 [UNICODE-NORMALIZATION] (without NUL character) encoded as UTF-8
799 [UTF-8]. If not present, the username and password must be encoded
800 in ISO 8859-1 [ISO-8859] (of which
801 US-ASCII [USASCII] is a subset). The client should send this
802 directive only if the server has indicated it supports UTF-8
803 [UTF-8]. The directive is needed for backwards compatibility with
804 HTTP Digest, which only supports ISO 8859-1.
807 32 hex digits, where the alphabetic characters MUST be lower case,
808 because MD5 is not case insensitive.
811 The cipher chosen by the client. This directive MUST appear
812 exactly once if "auth-conf" is negotiated; if required and not
813 present, authentication fails.
816 The "authorization ID" in Unicode Normalization Form KC [UNICODE-
817 NORMALIZATION] without NUL character, encoded in UTF-8 [UTF-8].
818 This directive is optional. If present, and the authenticating
819 user has sufficient privilege, and the server supports it, then
820 after authentication the server will use this identity for making
821 all accesses and access checks. If the client specifies it, and
822 the server does not support it, then the response-value calculated
823 on the server will not match the one calculated on the client and
824 authentication will fail.
826 The size of a digest-response MUST be less than 4096 bytes.
828 2.1.2.1 Response-value
830 The definition of "response-value" above indicates the encoding for
831 its value -- 32 lower case hex characters. The following definitions
832 show how the value is computed.
834 Although qop-value and components of digest-uri-value may be
838 Leach & Newman Expires: December 2002 [Page 14]
844 INTERNET DRAFT Digest SASL Mechanism June 2002
847 case-insensitive, the case which the client supplies in step two is
848 preserved for the purpose of computing and verifying the
852 HEX( KD ( HEX(H(A1)),
853 { nonce-value, ":" nc-value, ":",
854 cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
856 If authzid is specified, then A1 is
859 A1 = { H( { unq(username-value), ":", unq(realm-value), ":", passwd } ),
860 ":", nonce-value, ":", cnonce-value, ":", unq(authzid-value) }
862 If authzid is not specified, then A1 is
865 A1 = { H( { unq(username-value), ":", unq(realm-value), ":", passwd } ),
866 ":", nonce-value, ":", cnonce-value }
872 The "username-value", "realm-value" and "passwd" are encoded
873 according to the value of the "charset" directive. If "charset=UTF-8"
874 is present, and all the characters of "username-value"/"passwd" are,
875 after converting to Unicode Normalization Form KC [UNICODE-
876 NORMALIZATION], in the ISO 8859-1 character set, then it must be
877 converted to ISO 8859-1 before being hashed. This is so that
878 authentication databases that store the hashed username, realm and
879 password (which is common) can be shared compatibly with HTTP, which
880 specifies ISO 8859-1. A sample implementation of this conversion is
883 If the "qop" directive's value is "auth", then A2 is:
885 A2 = { "AUTHENTICATE:", digest-uri-value }
887 If the "qop" value is "auth-int" or "auth-conf" then A2 is:
889 A2 = { "AUTHENTICATE:", digest-uri-value,
890 ":00000000000000000000000000000000" }
892 Note that "AUTHENTICATE:" must be in upper case, and the second
893 string constant is a string with a colon followed by 32 zeros.
898 Leach & Newman Expires: December 2002 [Page 15]
904 INTERNET DRAFT Digest SASL Mechanism June 2002
907 These apparently strange values of A2 are for compatibility with
908 HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
909 the hash of the entity body to zero in the HTTP digest calculation of
912 Also, in the HTTP usage of Digest, several directives in the
913 "digest-challenge" sent by the server have to be returned by the
914 client in the "digest-response". These are:
919 These directives are not needed when Digest is used as a SASL
920 mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
924 The server receives and validates the "digest-response". The server
925 checks that the nonce-count is "00000001". If it supports subsequent
926 authentication (see section 2.2), it saves the value of the nonce and
927 the nonce-count. It sends a message formatted as follows:
929 response-auth = "rspauth" "=" response-value
931 where response-value is calculated as above, using the values sent in
932 step two, except that if qop is "auth", then A2 is
934 A2 = { ":", digest-uri-value }
936 And if qop is "auth-int" or "auth-conf" then A2 is
938 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
940 Compared to its use in HTTP, the following Digest directives in the
941 "digest-response" are unused:
948 2.2 Subsequent Authentication
950 If the client has previously authenticated to the server, and
951 remembers the values of username, realm, nonce, nonce-count, cnonce,
952 and qop that it used in that authentication, and the SASL profile for
953 a protocol permits an initial client response, then it MAY perform
954 "subsequent authentication", as defined in this section.
958 Leach & Newman Expires: December 2002 [Page 16]
964 INTERNET DRAFT Digest SASL Mechanism June 2002
969 The client uses the values from the previous authentication and sends
970 an initial response with a string formatted and computed according to
971 the rules for a "digest-response", as defined above, but with a
972 nonce-count one greater than used in the last "digest-response".
976 The server receives the "digest-response". If the server does not
977 support subsequent authentication, then it sends a
978 "digest-challenge", and authentication proceeds as in initial
979 authentication. If the server has no saved nonce and nonce-count from
980 a previous authentication, then it sends a "digest-challenge", and
981 authentication proceeds as in initial authentication. Otherwise, the
982 server validates the "digest-response", checks that the nonce-count
983 is one greater than that used in the previous authentication using
984 that nonce, and saves the new value of nonce-count.
986 If the response is invalid, then the server sends a
987 "digest-challenge", and authentication proceeds as in initial
988 authentication (and should be configurable to log an authentication
989 failure in some sort of security audit log, since the failure may be
990 a symptom of an attack). The nonce-count MUST NOT be incremented in
991 this case: to do so would allow a denial of service attack by sending
992 an out-of-order nonce-count.
994 If the response is valid, the server MAY choose to deem that
995 authentication has succeeded. However, if it has been too long since
996 the previous authentication, or for any other reason, the server MAY
997 send a new "digest-challenge" with a new value for nonce. The
998 challenge MAY contain a "stale" directive with value "true", which
999 says that the client may respond to the challenge using the password
1000 it used in the previous response; otherwise, the client must solicit
1001 the password anew from the user. This permits the server to make sure
1002 that the user has presented their password recently. (The directive
1003 name refers to the previous nonce being stale, not to the last use of
1004 the password.) Except for the handling of "stale", after sending the
1005 "digest-challenge" authentication proceeds as in the case of initial
1008 2.3 Integrity Protection
1010 If the server offered "qop=auth-int" and the client responded
1011 "qop=auth-int", then subsequent messages, up to but not including the
1012 next subsequent authentication, between the client and the server
1018 Leach & Newman Expires: December 2002 [Page 17]
1024 INTERNET DRAFT Digest SASL Mechanism June 2002
1027 MUST be integrity protected. Using as a base session key the value of
1028 H(A1) as defined above the client and server calculate a pair of
1029 message integrity keys as follows.
1031 The key for integrity protecting messages from client to server is:
1034 "Digest session key to client-to-server signing key magic constant"})
1036 The key for integrity protecting messages from server to client is:
1039 "Digest session key to server-to-client signing key magic constant"})
1041 where MD5 is as specified in [RFC 1321]. If message integrity is
1042 negotiated, a MAC block for each message is appended to the message.
1043 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
1044 2104] of the message, a 2-byte message type number in network byte
1045 order with value 1, and the 4-byte sequence number in network byte
1046 order. The message type is to allow for future extensions such as
1049 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
1052 where Ki is Kic for messages sent by the client and Kis for those
1053 sent by the server. The sequence number is initialized to zero, and
1054 incremented by one for each message sent.
1056 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
1057 received value; the message is discarded if they differ.
1059 2.4 Confidentiality Protection
1061 If the server sent a "cipher-opts" directive and the client responded
1062 with a "cipher" directive, then subsequent messages between the
1063 client and the server MUST be confidentiality protected. Using as a
1064 base session key the value of H(A1) as defined above the client and
1065 server calculate a pair of message integrity keys as follows.
1067 The key for confidentiality protecting messages from client to server
1070 Kcc = MD5({H(A1)[0..n-1],
1071 "Digest H(A1) to client-to-server sealing key magic constant"})
1073 The key for confidentiality protecting messages from server to client
1078 Leach & Newman Expires: December 2002 [Page 18]
1084 INTERNET DRAFT Digest SASL Mechanism June 2002
1087 Kcs = MD5({H(A1)[0..n-1],
1088 "Digest H(A1) to server-to-client sealing key magic constant"})
1090 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
1091 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*"
1092 ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first
1093 7 bytes; the key for "3des" is the first 14 bytes. The IV for "des"
1094 and "3des" is the last 8 bytes of Kcc or Kcs.
1096 The MAC block is a variable length padding prefix followed by 16
1097 bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC
1098 2104] of the message, a 2-byte message type number in network byte
1099 order with value 1, and the 4-byte sequence number in network byte
1100 order. If the blocksize of the chosen cipher is not 1 byte, the
1101 padding prefix is one or more octets each containing the number of
1102 padding bytes, such that total length of the encrypted part of the
1103 message is a multiple of the blocksize. The padding and first 10
1104 bytes of the MAC block are encrypted with the chosen cipher along
1107 SEAL(Ki, Kc, SeqNum, msg) =
1108 {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,
1111 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
1112 messages sent by the client and Kis and Kcs for those sent by the
1113 server. The sequence number is initialized to zero, and incremented
1114 by one for each message sent.
1116 Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is
1117 computed and compared with the received value; the message is
1118 discarded if they differ.
1120 3 Security Considerations
1122 3.1 Authentication of Clients using Digest Authentication
1124 Digest Authentication does not provide a strong authentication
1125 mechanism, when compared to public key based mechanisms, for example.
1126 However, since it prevents chosen plaintext attacks, it is stronger
1127 than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC
1128 2244], POP and IMAP [RFC 2195]. It is intended to replace the much
1129 weaker and even more dangerous use of plaintext passwords; however,
1130 since it is still a password based mechanism it avoids some of the
1131 potential deployabilty issues with public-key, OTP or similar
1134 Digest Authentication offers no confidentiality protection beyond
1138 Leach & Newman Expires: December 2002 [Page 19]
1144 INTERNET DRAFT Digest SASL Mechanism June 2002
1147 protecting the actual password. All of the rest of the challenge and
1148 response are available to an eavesdropper, including the user's name
1149 and authentication realm.
1151 3.2 Comparison of Digest with Plaintext Passwords
1153 The greatest threat to the type of transactions for which these
1154 protocols are used is network snooping. This kind of transaction
1155 might involve, for example, online access to a mail service whose use
1156 is restricted to paying subscribers. With plaintext password
1157 authentication an eavesdropper can obtain the password of the user.
1158 This not only permits him to access anything in the database, but,
1159 often worse, will permit access to anything else the user protects
1160 with the same password.
1164 Replay attacks are defeated if the client or the server chooses a
1165 fresh nonce for each authentication, as this specification requires.
1167 3.4 Online dictionary attacks
1169 If the attacker can eavesdrop, then it can test any overheard
1170 nonce/response pairs against a (potentially very large) list of
1171 common words. Such a list is usually much smaller than the total
1172 number of possible passwords. The cost of computing the response for
1173 each password on the list is paid once for each challenge.
1175 The server can mitigate this attack by not allowing users to select
1176 passwords that are in a dictionary.
1178 3.5 Offline dictionary attacks
1180 If the attacker can choose the challenge, then it can precompute the
1181 possible responses to that challenge for a list of common words. Such
1182 a list is usually much smaller than the total number of possible
1183 passwords. The cost of computing the response for each password on
1184 the list is paid just once.
1186 Offline dictionary attacks are defeated if the client chooses a fresh
1187 nonce for each authentication, as this specification requires.
1198 Leach & Newman Expires: December 2002 [Page 20]
1204 INTERNET DRAFT Digest SASL Mechanism June 2002
1207 3.6 Man in the Middle
1209 Digest authentication is vulnerable to "man in the middle" (MITM)
1210 attacks. Clearly, a MITM would present all the problems of
1211 eavesdropping. But it also offers some additional opportunities to
1214 A possible man-in-the-middle attack would be to substitute a weaker
1215 qop scheme for the one(s) sent by the server; the server will not be
1216 able to detect this attack. For this reason, the client should always
1217 use the strongest scheme that it understands from the choices
1218 offered, and should never choose a scheme that does not meet its
1219 minimum requirements.
1221 3.7 Chosen plaintext attacks
1223 A chosen plaintext attack is where a MITM or a malicious server can
1224 arbitrarily choose the challenge that the client will use to compute
1225 the response. The ability to choose the challenge is known to make
1226 cryptanalysis much easier [MD5].
1228 However, Digest does not permit the attack to choose the challenge as
1229 long as the client chooses a fresh nonce for each authentication, as
1230 this specification requires.
1232 3.8 Spoofing by Counterfeit Servers
1234 If a user can be led to believe that she is connecting to a host
1235 containing information protected by a password she knows, when in
1236 fact she is connecting to a hostile server, then the hostile server
1237 can obtain challenge/response pairs where it was able to partly
1238 choose the challenge. There is no known way that this can be
1241 3.9 Storing passwords
1243 Digest authentication requires that the authenticating agent (usually
1244 the server) store some data derived from the user's name and password
1245 in a "password file" associated with a given realm. Normally this
1246 might contain pairs consisting of username and H({ username-value,
1247 ":", realm-value, ":", passwd }), which is adequate to compute H(A1)
1248 as described above without directly exposing the user's password.
1250 The security implications of this are that if this password file is
1251 compromised, then an attacker gains immediate access to documents on
1252 the server using this realm. Unlike, say a standard UNIX password
1253 file, this information need not be decrypted in order to access
1254 documents in the server realm associated with this file. On the other
1258 Leach & Newman Expires: December 2002 [Page 21]
1264 INTERNET DRAFT Digest SASL Mechanism June 2002
1267 hand, decryption, or more likely a brute force attack, would be
1268 necessary to obtain the user's password. This is the reason that the
1269 realm is part of the digested data stored in the password file. It
1270 means that if one Digest authentication password file is compromised,
1271 it does not automatically compromise others with the same username
1272 and password (though it does expose them to brute force attack).
1274 There are two important security consequences of this. First the
1275 password file must be protected as if it contained plaintext
1276 passwords, because for the purpose of accessing documents in its
1277 realm, it effectively does.
1279 A second consequence of this is that the realm string should be
1280 unique among all realms that any single user is likely to use. In
1281 particular a realm string should include the name of the host doing
1284 3.10 Multiple realms
1286 Use of multiple realms may mean both that compromise of a the
1287 security database for a single realm does not compromise all
1288 security, and that there are more things to protect in order to keep
1289 the whole system secure.
1293 By modern cryptographic standards Digest Authentication is weak,
1294 compared to (say) public key based mechanisms. But for a large range
1295 of purposes it is valuable as a replacement for plaintext passwords.
1296 Its strength may vary depending on the implementation.
1300 This example shows the use of the Digest SASL mechanism with the
1301 IMAP4 AUTHENTICATE command [RFC 2060].
1303 In this example, "C:" and "S:" represent a line sent by the client or
1304 server respectively including a CRLF at the end. Linebreaks and
1305 indentation within a "C:" or "S:" are editorial and not part of the
1306 protocol. The password in this example was "secret". Note that the
1307 base64 encoding of the challenges and responses is part of the IMAP4
1308 AUTHENTICATE command, not part of the Digest specification itself.
1310 S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
1312 S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
1313 UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
1318 Leach & Newman Expires: December 2002 [Page 22]
1324 INTERNET DRAFT Digest SASL Mechanism June 2002
1327 C: a AUTHENTICATE DIGEST-MD5
1328 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
1329 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
1331 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
1332 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
1333 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
1334 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
1335 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
1336 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
1338 S: a OK User logged in
1341 The base64-decoded version of the SASL exchange is:
1343 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
1344 algorithm=md5-sess,charset=utf-8
1345 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1346 nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
1347 digest-uri="imap/elwood.innosoft.com",
1348 response=d388dad90d4bbd760a152321f2143af7,qop=auth
1349 S: rspauth=ea40f60335c427b5527b84dbabcdfffd
1351 The password in this example was "secret".
1353 This example shows the use of the Digest SASL mechanism with the
1354 ACAP, using the same notational conventions and password as in the
1355 previous example. Note that ACAP does not base64 encode and uses
1356 fewer round trips that IMAP4.
1358 S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
1359 "DIGEST-MD5" "PLAIN")
1360 C: a AUTHENTICATE "DIGEST-MD5"
1362 S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
1363 algorithm=md5-sess,charset=utf-8
1365 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1366 nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
1367 digest-uri="acap/elwood.innosoft.com",
1368 response=6084c6db3fede7352c551284490fd0fc,qop=auth
1370 S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
1378 Leach & Newman Expires: December 2002 [Page 23]
1384 INTERNET DRAFT Digest SASL Mechanism June 2002
1387 The server uses the values of all the directives, plus knowledge of
1388 the users password (or the hash of the user's name, server's realm
1389 and the user's password) to verify the computations above. If they
1390 check, then the user has authenticated.
1394 5.1 Normative references
1396 [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
1397 Access Authentication", RFC 2617, June 1999.
1399 [ISO-8859] ISO-8859. International Standard--Information Processing--
1400 8-bit Single-Byte Coded Graphic Character Sets --
1401 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
1402 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
1403 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
1404 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
1405 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
1406 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
1407 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
1408 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
1409 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
1411 [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
1412 Text Messages," STD 11, RFC 822, August 1982.
1414 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1417 [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1418 location of services (DNS SRV)", RFC 2052, October 1996.
1420 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1421 Hashing for Message Authentication", RFC 2104, February
1438 Leach & Newman Expires: December 2002 [Page 24]
1444 INTERNET DRAFT Digest SASL Mechanism June 2002
1447 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1448 Requirement Levels", BCP 14, RFC 2119, March 1997.
1450 [RFC 2222] Myers, J., "Simple Authentication and Security Layer
1451 (SASL)", RFC 2222, October 1997.
1453 [UNICODE-NORMALIZATION] Davis, Durst, "Unicode Standard Annex #15:
1454 Unicode Normalization Forms",
1455 http://www.unicode.org/unicode/reports/tr15/, March 2001.
1457 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
1460 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
1461 Code for Information Interchange. Standard ANSI X3.4-1986,
1464 [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
1465 Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
1467 [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing
1468 Architecture", RFC 2373, July 1998.
1470 [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
1471 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1474 5.2 Informative references
1476 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
1477 AUTHorize Extension for Simple Challenge/Response", RFC
1478 2195, September 1997.
1480 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5",
1481 CryptoBytes, Sping 1995, RSA Inc,
1482 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
1484 [RFC 2078] Linn, J., "Generic Security Service Application Program
1485 Interface, Version 2", RFC 2078, January 1997.
1487 [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
1488 4rev1", RFC 2060, December 1996.
1490 [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
1491 Access Protocol", RFC 2244, November 1997.
1493 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1494 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext
1498 Leach & Newman Expires: December 2002 [Page 25]
1504 INTERNET DRAFT Digest SASL Mechanism June 2002
1507 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1509 6 Authors' Addresses
1516 EMail: paulle@microsoft.com
1520 Innosoft International, Inc.
1522 West Covina, CA 91790 USA
1524 EMail: chris.newman@innosoft.com
1528 ACI WorldWide/MessagingDirect
1529 22 The Quadrant, Richmond, Surrey, TW9 1BP, UK
1531 Email: mel@messagingdirect.com
1558 Leach & Newman Expires: December 2002 [Page 26]
1564 INTERNET DRAFT Digest SASL Mechanism June 2002
1569 What follows is the definition of the notation as is used in the
1570 HTTP/1.1 specification [RFC 2616] and the HTTP authentication
1571 specification [Digest]; it is reproduced here for ease of reference.
1572 Since it is intended that a single Digest implementation can support
1573 both HTTP and SASL-based protocols, the same notation is used in both
1574 to facilitate comparison and prevention of unwanted differences.
1575 Since it is cut-and-paste from the HTTP specifications, not all
1576 productions may be used in this specification. It is also not quite
1577 legal ABNF; again, the errors were copied from the HTTP
1582 All of the mechanisms specified in this document are described in
1583 both prose and an augmented Backus-Naur Form (BNF) similar to that
1584 used by RFC 822 [RFC 822]. Implementers will need to be familiar with
1585 the notation in order to understand this specification.
1587 The augmented BNF includes the following constructs:
1590 The name of a rule is simply the name itself (without any
1591 enclosing "<" and ">") and is separated from its definition by the
1592 equal "=" character. White space is only significant in that
1593 indentation of continuation lines is used to indicate a rule
1594 definition that spans more than one line. Certain basic rules are
1595 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
1596 brackets are used within definitions whenever their presence will
1597 facilitate discerning the use of rule names.
1600 Quotation marks surround literal text. Unless stated otherwise,
1601 the text is case-insensitive.
1604 Elements separated by a bar ("|") are alternatives, e.g., "yes |
1605 no" will accept yes or no.
1608 Elements enclosed in parentheses are treated as a single element.
1609 Thus, "(elem (foo | bar) elem)" allows the token sequences
1610 "elem foo elem" and "elem bar elem".
1613 The character "*" preceding an element indicates repetition. The
1614 full form is "<n>*<m>element" indicating at least <n> and at most
1618 Leach & Newman Expires: December 2002 [Page 27]
1624 INTERNET DRAFT Digest SASL Mechanism June 2002
1627 <m> occurrences of element. Default values are 0 and infinity so
1628 that "*(element)" allows any number, including zero; "1*element"
1629 requires at least one; and "1*2element" allows one or two.
1632 Square brackets enclose optional elements; "[foo bar]" is
1633 equivalent to "*1(foo bar)".
1636 Specific repetition: "<n>(element)" is equivalent to
1637 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
1638 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
1639 alphabetic characters.
1642 A construct "#" is defined, similar to "*", for defining lists of
1643 elements. The full form is "<n>#<m>element" indicating at least
1644 <n> and at most <m> elements, each separated by one or more commas
1645 (",") and OPTIONAL linear white space (LWS). This makes the usual
1646 form of lists very easy; a rule such as
1647 ( *LWS element *( *LWS "," *LWS element ))
1650 Wherever this construct is used, null elements are allowed, but do
1651 not contribute to the count of elements present. That is,
1652 "(element), , (element) " is permitted, but counts as only two
1653 elements. Therefore, where at least one element is required, at
1654 least one non-null element MUST be present. Default values are 0
1655 and infinity so that "#element" allows any number, including zero;
1656 "1#element" requires at least one; and "1#2element" allows one or
1660 A semi-colon, set off some distance to the right of rule text,
1661 starts a comment that continues to the end of line. This is a
1662 simple way of including useful notes in parallel with the
1666 The grammar described by this specification is word-based. Except
1667 where noted otherwise, linear white space (LWS) can be included
1668 between any two adjacent words (token or quoted-string), and
1669 between adjacent words and separators, without changing the
1670 interpretation of a field. At least one delimiter (LWS and/or
1671 separators) MUST exist between any two tokens (for the definition
1672 of "token" below), since they would otherwise be interpreted as a
1678 Leach & Newman Expires: December 2002 [Page 28]
1684 INTERNET DRAFT Digest SASL Mechanism June 2002
1689 The following rules are used throughout this specification to
1690 describe basic parsing constructs. The US-ASCII coded character set
1691 is defined by ANSI X3.4-1986 [USASCII].
1693 OCTET = <any 8-bit character>
1694 CHAR = <any US-ASCII character (octets 0 - 127)>
1695 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
1696 LOALPHA = <any US-ASCII lowercase letter "a".."z">
1697 ALPHA = UPALPHA | LOALPHA
1698 DIGIT = <any US-ASCII digit "0".."9">
1699 CTL = <any US-ASCII control character
1700 (octets 0 - 31) and DEL (127)>
1701 CR = <US-ASCII CR, carriage return (13)>
1702 LF = <US-ASCII LF, linefeed (10)>
1703 SP = <US-ASCII SP, space (32)>
1704 HT = <US-ASCII HT, horizontal-tab (9)>
1705 <"> = <US-ASCII double-quote mark (34)>
1706 TEXTCHAR = <any OCTET except CTLs, but including HT>
1709 All linear white space, including folding, has the same semantics as
1710 SP. A recipient MAY replace any linear white space with a single SP
1711 before interpreting the field value or forwarding the message
1714 LWS = [CRLF] 1*( SP | HT )
1716 The TEXT rule is only used for descriptive field contents and values
1717 that are not intended to be interpreted by the message parser. Words
1718 of TEXT contains characters either from ISO-8859-1 [ISO-8859]
1719 character set or UTF-8 [UTF-8].
1721 TEXT = <any *OCTET except CTLs,
1724 A CRLF is allowed in the definition of TEXT only as part of a header
1725 field continuation. It is expected that the folding LWS will be
1726 replaced with a single SP before interpretation of the TEXT value.
1728 Hexadecimal numeric characters are used in several protocol elements.
1730 HEX = "A" | "B" | "C" | "D" | "E" | "F"
1731 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
1733 Many HTTP/1.1 header field values consist of words separated by LWS
1734 or special characters. These special characters MUST be in a quoted
1738 Leach & Newman Expires: December 2002 [Page 29]
1744 INTERNET DRAFT Digest SASL Mechanism June 2002
1747 string to be used within a parameter value.
1750 separators = "(" | ")" | "<" | ">" | "@"
1751 | "," | ";" | ":" | "\" | <">
1752 | "/" | "[" | "]" | "?" | "="
1753 | "{" | "}" | SP | HT
1754 TOKENCHAR = <any CHAR except CTLs or separators>
1756 A string of text is parsed as a single word if it is quoted using
1759 quoted-string = ( <"> qdstr-val <"> )
1760 qdstr-val = *( qdtext | quoted-pair )
1761 qdtext = <any TEXTCHAR except <"> and "\">
1763 Note that LWS is NOT implicit between the double-quote marks (<">)
1764 surrounding a qdstr-val and the qdstr-val; any LWS will be considered
1765 part of the qdstr-val. This is also the case for quotation marks
1766 surrounding any other construct.
1768 The backslash character ("\") MAY be used as a single-character
1769 quoting mechanism only within qdstr-val and comment constructs.
1771 quoted-pair = "\" CHAR
1773 The value of this construct is CHAR. Note that an effect of this rule
1774 is that backslash itself MUST be quoted.
1798 Leach & Newman Expires: December 2002 [Page 30]
1804 INTERNET DRAFT Digest SASL Mechanism June 2002
1809 The sample implementation in [Digest] also applies to DIGEST-MD5.
1811 The following code implements the conversion from UTF-8 to 8859-1 if
1814 /* if the string is entirely in the 8859-1 subset of UTF-8, then
1815 * translate to 8859-1 prior to MD5
1817 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
1820 const unsigned char *scan, *end;
1824 for (scan = base; scan < end; ++scan) {
1825 if (*scan > 0xC3) break; /* abort if outside 8859-1 */
1826 if (*scan >= 0xC0 && *scan <= 0xC3) {
1827 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
1831 /* if we found a character outside 8859-1, don't alter string
1834 MD5Update(ctx, base, len);
1838 /* convert to 8859-1 prior to applying hash
1841 for (scan = base; scan < end && *scan < 0xC0; ++scan)
1843 if (scan != base) MD5Update(ctx, base, scan - base);
1844 if (scan + 1 >= end) break;
1845 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
1846 MD5Update(ctx, &cbuf, 1);
1848 } while (base < end);
1858 Leach & Newman Expires: December 2002 [Page 31]
1864 INTERNET DRAFT Digest SASL Mechanism June 2002
1867 9 Interoperability considerations
1869 9.1 Implementing DES cipher in CBC mode
1871 Several cryptographic libraries (Ebones, OpenSSL) provide a convenience
1872 function des_cbc_encrypt for implementing DES cipher in CBC mode.
1873 There is a documented bug in this function: the function doesn't update
1874 IV before returning. If an implementation uses this function to implement
1875 DES cipher in CBC mode, it MUST update IV by copying the last 8 bytes of
1876 the des_cbc_encrypt's output to the IV buffer.
1878 Note that the function des_ede2_cbc_encrypt that may be used to implement
1879 3DES (in "two keys mode") in CBC mode works as expected.
1881 10 Full Copyright Statement
1883 Copyright (C) The Internet Society (2002). All Rights Reserved.
1885 This document and translations of it may be copied and furnished to
1886 others, and derivative works that comment on or otherwise explain it
1887 or assist in its implementation may be prepared, copied, published
1888 and distributed, in whole or in part, without restriction of any
1889 kind, provided that the above copyright notice and this paragraph are
1890 included on all such copies and derivative works. However, this
1891 document itself may not be modified in any way, such as by removing
1892 the copyright notice or references to the Internet Society or other
1893 Internet organizations, except as needed for the purpose of
1894 developing Internet standards in which case the procedures for
1895 copyrights defined in the Internet Standards process must be
1896 followed, or as required to translate it into languages other than
1899 The limited permissions granted above are perpetual and will not be
1900 revoked by the Internet Society or its successors or assigns.
1902 This document and the information contained herein is provided on an
1903 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1904 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1905 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1906 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1907 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1911 Funding for the RFC Editor function is currently provided by the
1918 Leach & Newman Expires: December 2002 [Page 32]
1924 INTERNET DRAFT Digest SASL Mechanism June 2002
1927 Appendix A: Changes from 2831
1929 1). Fixed various typos in formulas.
1931 2). Dropped DES as mandatory to implement cipher (3DES is mandatory
1934 3). Tighten ABNF. Fixed some bugs.
1936 4). Clarified nc-value verification and which side is aborting
1939 5). Added text saying that for interoperability username/password
1940 MUST be normalized according to Normalization form KC.
1942 6). Clarified that unquoted version of the username, etc. used in A1
1945 7). Various cleanup to References section. Split all references to
1946 Normative and Informative.
1948 8). Added minimal and maximal limits on maxbuf. Clarified how to
1949 calculate max sender size.
1951 9). Change ABNF for host to allow for IPv6 addresses. ABNF now
1952 references RFC 2373 and RFC 2396.
1954 10). Minor text clarifications.
1956 Appendix B: Open Issues
1958 1). The latest revision prohibits escaped characters in nonce/cnonce.
1961 2). Is a realm in UTF-8?
1963 3). Normative vs. Informative references must be carefully rechecked.
1965 4). Merge DIGEST-MD5 AES cipher with this document?
1967 5). What to do about CBC mode attack that affects TLS document and
1978 Leach & Newman Expires: December 2002 [Page 33]