| blob | 8b33a1dd18d8cbb9764a70f3b72c3d773991981e |
7 INTERNET-DRAFT P. Leach
8 Obsoletes: 2831 Microsoft
9 Intended category: Standards track C. Newman
10 Sun Microsystems
11 A. Melnikov
12 Isode Ltd.
13 February 2004
15 Using Digest Authentication as a SASL Mechanism
16 draft-ietf-sasl-rfc2831bis-03.txt
18 Status of this Memo
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.
38 Copyright Notice
40 Copyright (C) The Internet Society (2004). All Rights Reserved.
42 Abstract
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: August 2004 [Page 1]
64 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
67 Table of Contents
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....................................17
78 2.2.1 Step one..................................................17
79 2.2.2 Step Two..................................................17
80 2.3 INTEGRITY PROTECTION.........................................18
81 2.4 CONFIDENTIALITY PROTECTION...................................18
82 3 SECURITY CONSIDERATIONS.........................................21
83 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21
84 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21
85 3.3 REPLAY ATTACKS...............................................21
86 3.4 ONLINE DICTIONARY ATTACKS....................................22
87 3.5 OFFLINE DICTIONARY ATTACKS...................................22
88 3.6 MAN IN THE MIDDLE............................................22
89 3.7 CHOSEN PLAINTEXT ATTACKS.....................................22
90 3.8 CBC MODE ATTACKS.............................................
91 3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23
92 3.10 STORING PASSWORDS...........................................23
93 3.11 MULTIPLE REALMS.............................................24
94 3.12 SUMMARY.....................................................24
95 4 EXAMPLE.........................................................24
96 5 REFERENCES......................................................26
97 5.1 NORMATIVE REFERENCES.........................................26
98 5.2 INFORMATIVE REFERENCES.......................................27
99 6 AUTHORS' ADDRESSES..............................................28
100 7 ABNF............................................................29
101 7.1 AUGMENTED BNF................................................29
102 7.2 BASIC RULES..................................................31
103 8 SAMPLE CODE.....................................................33
104 10 ACKNOWLEDGEMENTS..............................................34
105 11 FULL COPYRIGHT STATEMENT.......................................35
106 Appendix A: Changes from 2831.....................................36
107 Appendix B: Open Issues...........................................37
118 Leach & Newman Expires: August 2004 [Page 2]
124 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
127 1 Introduction
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
141 exchange.
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: August 2004 [Page 3]
184 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
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.
196 <<"Protocol profile" is defined in RFC2222>>
198 1.2 Requirements
200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
202 document are to be interpreted as described in RFC 2119 [RFC 2119].
204 An implementation is not compliant if it fails to satisfy one or more
205 of the MUST level requirements for the protocols it implements. An
206 implementation that satisfies all the MUST level and all the SHOULD
207 level requirements for its protocols is said to be "unconditionally
208 compliant"; one that satisfies all the MUST level requirements but
209 not all the SHOULD level requirements for its protocols is said to be
210 "conditionally compliant."
238 Leach & Newman Expires: August 2004 [Page 4]
244 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
247 2 Authentication
249 DIGEST-MD5 can operate in two modes. Initial authentication (section
250 2.1) is usually used when a client authenticates to a server for the
251 first time. If protocol profile supports initial client response
252 (see "Protocol profile requirements" in [RFC 2222]) and the client
253 has successfully authenticated to the server before and the client
254 supports reauthentication (i.e. it has cached some values from a
255 previous authentication exchange, as described in 2.2), the client
256 can use fast reauthentication mode (section 2.2).
258 The following sections describe these two modes in details.
260 2.1 Initial Authentication
262 If the client has not recently authenticated to the server, then it
263 must perform "initial authentication", as defined in this section. If
264 it has recently authenticated, then a more efficient form is
265 available, defined in the next section.
267 2.1.1 Step One
269 The server starts by sending a challenge. The data encoded in the
270 challenge contains a string formatted according to the rules for a
271 "digest-challenge" defined as follows:
298 Leach & Newman Expires: August 2004 [Page 5]
304 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
307 digest-challenge =
308 1#( realm | nonce | qop-options | stale | server_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" |
318 qop-token
319 ;; qop-token is reserved for identifying future
320 ;; extensions to DIGEST-MD5
321 qop-token = token
322 stale = "stale" "=" "true"
323 server_maxbuf = "maxbuf" "=" maxbuf-value
324 maxbuf-value = 1*DIGIT
325 charset = "charset" "=" "utf-8"
326 algorithm = "algorithm" "=" "md5-sess"
327 cipher-opts = "cipher" "=" <"> 1#cipher-value <">
328 cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
329 "rc4-56" | "aes-cbc" | cipher-token
330 ;; "des" and "3des" ciphers are obsolete.
331 ;; cipher-token is reserved for new ciphersuites
332 cipher-token = token
333 auth-param = token "=" ( token | quoted-string )
335 The meanings of the values of the directives used above are as
336 follows:
338 realm
339 Mechanistically, a string which can enable users to know which
340 username and password to use, in case they might have different
341 ones for different servers. Conceptually, it is the name of a
342 collection of accounts that might include the user's account. This
343 string should contain at least the name of the host performing the
344 authentication and might additionally indicate the collection of
345 users who might have access. An example might be
346 "registered_users@gotham.news.example.com".
348 <<Add more examples:
350 1) "dc=gotham, dc=news, dc=example, dc=com".
352 2) Cluster name >>
354 <<A server implementation that uses a fixed string as the realm is
358 Leach & Newman Expires: August 2004 [Page 6]
364 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
367 compliant with this specification, however this is not
368 recommended. See also sections 3.10 "Storing passwords" and 3.11
369 "Multiple realms" for discussion>>
371 The value of this directive is case-sensitive. This directive is
372 optional; if not present, the client SHOULD solicit it from the
373 user or be able to compute a default; a plausible default might be
374 the realm supplied by the user when they logged in to the client
375 system. Multiple realm directives are allowed, in which case the
376 user or client must choose one as the realm for which to supply
377 username and password.
379 If at least one realm is present and the charset directive is also
380 specified (which means that realm(s) are encoded as UTF-8), the
381 client SHOULD prepare each instance of realm using the "SASLPrep"
382 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
383 preparation of a realm instance fails or results in an empty
384 string (unless the realm instance was the empty string), the
385 client SHOULD abort the authentication exchange.
387 Note, that if the client picks one of the realms provided by the
388 server, it MUST send it exactly as received from the server, even
389 if the prepared version of the realm differs from the received
390 version.
392 nonce
393 A server-specified data string which MUST be different each time a
394 digest-challenge is sent as part of initial authentication. It is
395 recommended that this string be base64 or hexadecimal data. Note
396 that the whole string is enclosed in double-quote characters,
397 however quote-characters or escape characters are not allowed in
398 the string, even when quoted. This is different from the RFC 2821.
399 The contents of the nonce are implementation dependent. The
400 security of the implementation depends on a good choice. It is
401 RECOMMENDED that it contain at least 64 bits of entropy. The nonce
402 is opaque to the client. This directive is required and MUST
403 appear exactly once; if not present, or if multiple instances are
404 present, the client should abort the authentication exchange.
406 qop-options
407 A quoted string of one or more tokens indicating the "quality of
408 protection" values supported by the server. The value "auth"
409 indicates authentication; the value "auth-int" indicates
410 authentication with integrity protection; the value "auth-conf"
411 indicates authentication with integrity protection and encryption.
412 This directive is optional; if not present it defaults to "auth".
413 The client MUST ignore unrecognized options; if the client
414 recognizes no option, it should abort the authentication exchange.
418 Leach & Newman Expires: August 2004 [Page 7]
424 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
427 <<What if this directive is present multiple times? Error, or take
428 the union of all values?>>
430 stale
431 The "stale" directive is not used in initial authentication. See
432 the next section for its use in subsequent authentications. This
433 directive may appear at most once; if multiple instances are
434 present, the client should abort the authentication exchange.
436 server_maxbuf ("maximal ciphertext buffer size")
437 A number indicating the size of the largest buffer (in bytes) the
438 server is able to receive when using "auth-int" or "auth-conf".
439 The value MUST be bigger than 16 (32 for Confidentiality
440 protection with the "aes-cbc" cipher) and smaller or equal to
441 16777215 (i.e. 2**24-1). If this directive is missing, the default
442 value is 65536. This directive may appear at most once; if
443 multiple instances are present, or the value is out of range the
444 client MUST abort the authentication exchange.
446 Let "maximal cleartext buffer size" (or "maximal sender size") be
447 the maximal size of a cleartext buffer that, after being
448 transformed by integrity (section 2.3) or confidentiality (section
449 2.4) protection function, will produce a SASL block of the maxbuf
450 size. As it should be clear from the name, the sender MUST never
451 pass a block of data bigger than the "maximal sender size" through
452 the selected protection function. This will guaranty that the
453 receiver will never get a block bigger than the maxbuf.
478 Leach & Newman Expires: August 2004 [Page 8]
484 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
487 charset
488 This directive, if present, specifies that the server supports
489 UTF-8 [UTF-8] encoding for the username, realm and password. If
490 present, the username, realm and password are in Unicode, prepared
491 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
492 algorithm [RFC 3454] and than encoded as UTF-8 [UTF-8]. If not
493 present, the username, realm and password used by the client in
494 Step 2 MUST be encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII
495 [USASCII] is a subset). The directive is needed for backwards
496 compatibility with HTTP Digest, which only supports ISO 8859-1.
497 This directive may appear at most once; if multiple instances are
498 present, the client should abort the authentication exchange.
500 Note, that this directive doesn't affect authorization id
501 ("authzid").
503 algorithm
504 This directive is required for backwards compatibility with HTTP
505 Digest, which supports other algorithms. This directive is
506 required and MUST appear exactly once; if not present, or if
507 multiple instances are present, the client should abort the
508 authentication exchange.
510 cipher-opts
511 A list of ciphers that the server supports. This directive must be
512 present exactly once if "auth-conf" is offered in the
513 "qop-options" directive, in which case the "rc4" cipher is
514 mandatory-to-implement. The client MUST ignore unrecognized
515 ciphers; if the client recognizes no cipher, it should abort the
516 authentication exchange. See section 2.4 for more detailed
517 description of the ciphers.
519 rc4, rc4-40, rc4-56
520 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
521 respectively.
523 aes-cbc
524 the Advanced Encryption Standard (AES) cipher [AES] in cipher
525 block chaining (CBC) mode with a 128 bit key and explicit
526 Initialization Vector (IV). This mode requires an IV that has
527 the same size as the block size.
529 auth-param
530 This construct allows for future extensions; it may appear more
531 than once. The client MUST ignore any unrecognized directives.
533 For use as a SASL mechanism, note that the following changes are made
534 to "digest-challenge" from HTTP: the following Digest options (called
538 Leach & Newman Expires: August 2004 [Page 9]
544 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
547 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
548 and MUST be ignored if received):
550 opaque
551 domain
553 The size of a digest-challenge MUST be less than 2048 bytes.
555 2.1.2 Step Two
557 The client makes note of the "digest-challenge" and then responds
558 with a string formatted and computed according to the rules for a
559 "digest-response" defined as follows:
561 digest-response = 1#( username | realm | nonce | cnonce |
562 nonce-count | qop | digest-uri | response |
563 client_maxbuf | charset | cipher | authzid |
564 auth-param )
566 username = "username" "=" <"> username-value <">
567 username-value = qdstr-val
568 cnonce = "cnonce" "=" <"> cnonce-value <">
569 cnonce-value = *qdtext
570 nonce-count = "nc" "=" nc-value
571 nc-value = 8LHEX
572 client_maxbuf = "maxbuf" "=" maxbuf-value
573 qop = "qop" "=" qop-value
574 digest-uri = "digest-uri" "=" <"> digest-uri-value <">
575 digest-uri-value = serv-type "/" host [ "/" serv-name ]
576 serv-type = 1*ALPHA
577 serv-name = host
578 response = "response" "=" response-value
579 response-value = 32LHEX
580 LHEX = "0" | "1" | "2" | "3" |
581 "4" | "5" | "6" | "7" |
582 "8" | "9" | "a" | "b" |
583 "c" | "d" | "e" | "f"
584 cipher = "cipher" "=" cipher-value
585 authzid = "authzid" "=" <"> authzid-value <">
586 authzid-value = qdstr-val
588 The 'host' non-terminal is defined in [RFC 2732] as
590 host = hostname | IPv4address | IPv6reference
591 ipv6reference = "[" IPv6address "]"
593 where IPv6address and IPv4address are defined in [RFC 2373]
594 and 'hostname' is defined in [RFC 2396].
598 Leach & Newman Expires: August 2004 [Page 10]
604 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
607 username
608 The user's name in the specified realm, encoded according to the
609 value of the "charset" directive. This directive is required and
610 MUST be present exactly once; otherwise, authentication fails.
612 If the charset directive is also specified (which means that the
613 username is encoded as UTF-8) The client MUST first check if all
614 the characters of the username are in the ISO 8859-1 character
615 set. If they are, no further changes are performed. Otherwise, the
616 client MUST prepare the username using the "SASLPrep" profile
617 [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If the
618 preparation of the username fails or results in an empty string,
619 the client MUST abort the authentication exchange. If the
620 preparation succeeds, the prepared value will be sent to the
621 server.
623 Upon the receipt of this value and if the charset directive is
624 also specified (which means that the username is encoded as
625 UTF-8), the server MUST prepare the username using the "SASLPrep"
626 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
627 preparation of the username fails or results in an empty string,
628 the server MUST fail the authentication exchange.
630 realm
631 The realm containing the user's account, encoded according to the
632 value of the "charset" directive. This directive is required if
633 the server provided any realms in the
634 "digest-challenge", in which case it may appear exactly once and
635 its value SHOULD be one of those realms. If the directive is
636 missing, "realm-value" will set to the empty string when computing
637 A1 (see below for details).
639 If realm was provided by the client and if the charset directive
640 was also specified (which means that the realm is encoded as
641 UTF-8), the server MUST prepare the realm using the "SASLPrep"
642 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
643 preparation of the realm fails or results in an empty string
644 (unless already the empty string), the server MUST fail the
645 authentication exchange.
647 <<The server has to do this only if it hasn't provided a realm and
648 the client computed one>>
650 nonce
651 The server-specified data string received in the preceding digest-
652 challenge. This directive is required and MUST be present exactly
653 once; otherwise, authentication fails.
658 Leach & Newman Expires: August 2004 [Page 11]
664 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
667 cnonce
668 A client-specified data string which MUST be different each time a
669 digest-response is sent as part of initial authentication. The
670 cnonce-value is an opaque quoted string value provided by the
671 client and used by both client and server to avoid chosen
672 plaintext attacks, and to provide mutual authentication. The
673 security of the implementation depends on a good choice. It is
674 RECOMMENDED that it contain at least 64 bits of entropy. Note that
675 the whole string is enclosed in double-quote characters, however
676 quote-characters or escape characters are not allowed in the
677 string, even when quoted. This is different from the RFC 2821.
678 This directive is required and MUST be present exactly once;
679 otherwise, authentication fails.
681 nonce-count
682 The nc-value is the hexadecimal count of the number of requests
683 (including the current request) that the client has sent with the
684 nonce value in this request. For example, in the first request
685 sent in response to a given nonce value, the client sends
686 "nc=00000001". The purpose of this directive is to allow the
687 server to detect request replays by maintaining its own copy of
688 this count - if the same nc-value is seen twice, then the request
689 is a replay. See the description below of the construction of the
690 response value. This directive is required and MUST be present
691 exactly once; otherwise, authentication fails.
693 qop
694 Indicates what "quality of protection" the client accepted. If
695 present, it may appear exactly once and its value MUST be one of
696 the alternatives in qop-options. If not present, it defaults to
697 "auth". These values affect the computation of the response. Note
698 that this is a single token, not a quoted list of alternatives.
700 serv-type
701 Indicates the type of service, such as "http" for web service,
702 "ftp" for FTP service, "smtp" for mail delivery service, etc. The
703 service name as defined in the SASL profile for the protocol see
704 section 4 of [RFC 2222], registered in the IANA registry of
705 "service" elements for the GSSAPI host-based service name form
706 [RFC 2078].
708 host
709 The DNS host name or IP (IPv4 or IPv6) address for the service
710 requested. The DNS host name must be the fully-qualified
711 canonical name of the host. The DNS host name is the preferred
712 form; see notes on server processing of the digest-uri.
718 Leach & Newman Expires: August 2004 [Page 12]
724 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
727 serv-name
728 Indicates the name of the service if it is replicated. The service
729 is considered to be replicated if the client's service-location
730 process involves resolution using standard DNS lookup operations,
731 and if these operations involve DNS records (such as SRV [RFC
732 2052], or MX) which resolve one DNS name into a set of other DNS
733 names. In this case, the initial name used by the client is the
734 "serv-name", and the final name is the "host" component. For
735 example, the incoming mail service for "example.com" may be
736 replicated through the use of MX records stored in the DNS, one of
737 which points at an SMTP server called "mail3.example.com"; it's
738 "serv-name" would be "example.com", it's "host" would be
739 "mail3.example.com". If the service is not replicated, or the
740 serv-name is identical to the host, then the serv-name component
741 MUST be omitted.
743 digest-uri
744 Indicates the principal name of the service with which the client
745 wishes to connect, formed from the serv-type, host, and serv-name.
746 For example, the FTP service on "ftp.example.com" would have a
747 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
748 the example above would have a "digest-uri" value of
749 "SMTP/mail3.example.com/example.com".
751 Servers SHOULD check that the supplied value is correct. This will
752 detect accidental connection to the incorrect server, as well as some
753 redirection attacks. It is also so that clients will be trained to
754 provide values that will work with implementations that use a shared
755 back-end authentication service that can provide server
756 authentication.
758 The serv-type component should match the service being offered. The
759 host component should match one of the host names of the host on
760 which the service is running, or it's IP address. Servers SHOULD NOT
761 normally support the IP address form, because server authentication
762 by IP address is not very useful; they should only do so if the DNS
763 is unavailable or unreliable. The serv-name component should match
764 one of the service's configured service names.
766 This directive is required and MUST be present exactly once; if
767 multiple instances are present, the client MUST abort the
768 authentication exchange.
770 Note: In the HTTP use of Digest authentication, the digest-uri is the
771 URI (usually a URL) of the resource requested -- hence the name of
772 the directive.
778 Leach & Newman Expires: August 2004 [Page 13]
784 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
787 response
788 A string of 32 hex digits computed as defined below, which proves
789 that the user knows a password. This directive is required and
790 MUST be present exactly once; otherwise, authentication fails.
792 client_maxbuf
793 A number indicating the size of the largest ciphertext buffer the
794 client is able to receive when using "auth-int" or "auth-conf". If
795 this directive is missing, the default value is 65536. This
796 directive may appear at most once; if multiple instances are
797 present, the server MUST abort the authentication exchange. If the
798 value is less or equal to 16 (<<32 for aes-cbc>>) or bigger than
799 16777215 (i.e. 2**24-1), the server MUST abort the authentication
800 exchange.
802 Upon processing/sending of the client_maxbuf value both the server
803 and the client calculate their "maximal ciphertext buffer size" as
804 the minimum of the server_maxbuf (Step One) and the client_maxbuf
805 (Step Two). The "maximal sender size" can be calculated by
806 subtracting 16 (<<32 for aes-cbc>>) from the calculated "maximal
807 ciphertext buffer size".
809 When sending a block of data the client/server MUST NOT pass more
810 than the "maximal sender size" bytes of data to the selected
811 protection function (2.3 or 2.4).
813 charset
814 This directive, if present, specifies that the client has used
815 UTF-8 [UTF-8] encoding for the username, realm and password. If
816 present, the username, realm and password are in Unicode, prepared
817 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
818 algorithm [RFC 3454] and than encoded as UTF-8 [UTF-8]. If not
819 present, the username and password must be encoded in ISO 8859-1
820 [ISO-8859] (of which
821 US-ASCII [USASCII] is a subset). The client should send this
822 directive only if the server has indicated it supports UTF-8
823 [UTF-8]. The directive is needed for backwards compatibility with
824 HTTP Digest, which only supports ISO 8859-1.
826 <<Need to explain, that SASLPrep on "realm" is ONLY performed when
827 the client selected a realm itself (the server hasn't provided
828 any). If the server has sent a list of realms and the client has
829 picked one of them, the client MUST NOT change the selected realm
830 (i.e. MUST NOT SASLPrep it).>>
832 Note, that this directive doesn't affect authorization id
833 ("authzid").
838 Leach & Newman Expires: August 2004 [Page 14]
844 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
847 LHEX
848 32 hex digits, where the alphabetic characters MUST be lower case,
849 because MD5 is not case insensitive.
851 cipher
852 The cipher chosen by the client. This directive MUST appear
853 exactly once if "auth-conf" is negotiated; if required and not
854 present, authentication fails.
856 authzid
857 The "authorization ID" directive is optional. If present, and the
858 authenticating user has sufficient privilege, and the server
859 supports it, then after authentication the server will use this
860 identity for making all accesses and access checks. If the client
861 specifies it, and the server does not support it, then the
862 response-value calculated on the server will not match the one
863 calculated on the client and authentication will fail.
865 The authzid MUST NOT be an empty string.
867 The authorization identifier MUST NOT be converted to ISO 8859-1
868 even if the authentication identifier ("username") is converted
869 for compatibility as directed by "charset" directive.
871 The server SHOULD verify the correctness of an authzid as
872 specified by the corresponding SASL protocol profile.
874 The size of a digest-response MUST be less than 4096 bytes.
876 2.1.2.1 Response-value
878 The definition of "response-value" above indicates the encoding for
879 its value -- 32 lower case hex characters. The following definitions
880 show how the value is computed.
882 Although qop-value and components of digest-uri-value may be
883 case-insensitive, the case which the client supplies in step two is
884 preserved for the purpose of computing and verifying the
885 response-value.
887 response-value =
888 HEX( KD ( HEX(H(A1)),
889 { nonce-value, ":" nc-value, ":",
890 cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
892 If authzid is specified, then A1 is
894 A1 = { SS, ":", nonce-value, ":", cnonce-value, ":", unq(authzid-value) }
898 Leach & Newman Expires: August 2004 [Page 15]
904 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
907 If authzid is not specified, then A1 is
909 A1 = { SS, ":", nonce-value, ":", cnonce-value }
911 where
913 passwd = *OCTET
915 SS = H( { unq(username-value), ":", unq(realm-value), ":", passwd } )
918 <<Note about empty authzid-value versa missing authzid-value and how
919 this affects hash>>
921 The "username-value", "realm-value" and "passwd" are encoded
922 according to the value of the "charset" directive. If "charset=UTF-8"
923 is present, and all the characters of "username-value" are, before
924 preparing using the "SASLPrep" profile [SASLPrep] of the "stringprep"
925 algorithm [RFC 3454], in the ISO 8859-1 character set, then it must
926 be converted to ISO 8859-1 before being hashed (and no SASLPrep is to
927 be done). Otherwise the SASLPrep MUST be performed. The same
928 transformation has to be done for "realm-value" (only if the "realm-
929 value" was obtained by the client). If the "realm-value" was picked
930 from a list of realms supported by the server, it MUST NOT be
931 prepared with SASLPrep) and "passwd". This is so that authentication
932 databases that store the hashed username, realm and password (which
933 is common) can be shared compatibly with HTTP, which specifies ISO
934 8859-1. A sample implementation of this conversion is in section 8.
936 If the "qop" directive's value is "auth", then A2 is:
938 A2 = { "AUTHENTICATE:", digest-uri-value }
958 Leach & Newman Expires: August 2004 [Page 16]
964 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
967 If the "qop" value is "auth-int" or "auth-conf" then A2 is:
969 A2 = { "AUTHENTICATE:", digest-uri-value,
970 ":00000000000000000000000000000000" }
972 Note that "AUTHENTICATE:" must be in upper case, and the second
973 string constant is a string with a colon followed by 32 zeros.
975 These apparently strange values of A2 are for compatibility with
976 HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
977 the hash of the entity body to zero in the HTTP digest calculation of
978 A2.
980 Also, in the HTTP usage of Digest, several directives in the
981 "digest-challenge" sent by the server have to be returned by the
982 client in the "digest-response". These are:
984 opaque
985 algorithm
987 These directives are not needed when Digest is used as a SASL
988 mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
990 2.1.3 Step Three
992 The server receives and validates the "digest-response". The server
993 checks that the nonce-count is "00000001". If it supports subsequent
994 authentication (see section 2.2), it saves the value of the nonce and
995 the nonce-count. It sends a message formatted as follows:
997 response-auth = "rspauth" "=" response-value
999 where response-value is calculated as above, using the values sent in
1000 step two, except that if qop is "auth", then A2 is
1002 A2 = { ":", digest-uri-value }
1004 And if qop is "auth-int" or "auth-conf" then A2 is
1006 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
1008 Compared to its use in HTTP, the following Digest directives in the
1009 "digest-response" are unused:
1011 nextnonce
1012 qop
1013 cnonce
1014 nonce-count
1018 Leach & Newman Expires: August 2004 [Page 17]
1024 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1027 2.2 Subsequent Authentication
1029 If the client has previously authenticated to the server, and
1030 remembers the values of username, realm, nonce, nonce-count, cnonce,
1031 and qop that it used in that authentication, and the SASL profile for
1032 a protocol permits an initial client response, then it MAY perform
1033 "subsequent authentication" or "fast reauthentication", as defined in
1034 this section. Note, that a subsequent authentication can be done on
1035 a different connection, or on the same connection, if the protocol
1036 profile also permits multiple authentications.
1038 2.2.1 Step one
1040 The client uses the values from the previous authentication and sends
1041 an initial response with a string formatted and computed according to
1042 the rules for a "digest-response", as defined above, but with a
1043 nonce-count one greater than used in the last "digest-response".
1045 2.2.2 Step Two
1047 The server receives the "digest-response". If the server does not
1048 support subsequent authentication, then it sends a
1049 "digest-challenge", and authentication proceeds as in initial
1050 authentication. If the server has no saved nonce and nonce-count from
1051 a previous authentication, then it sends a "digest-challenge", and
1052 authentication proceeds as in initial authentication. Otherwise, the
1053 server validates the "digest-response", checks that the nonce-count
1054 is one greater than that used in the previous authentication using
1055 that nonce, and saves the new value of nonce-count.
1057 If the response is invalid, then the server sends a
1058 "digest-challenge", and authentication proceeds as in initial
1059 authentication (and should be configurable to log an authentication
1060 failure in some sort of security audit log, since the failure may be
1061 a symptom of an attack). The nonce-count MUST NOT be incremented in
1062 this case: to do so would allow a denial of service attack by sending
1063 an out-of-order nonce-count.
1065 If the response is valid, the server MAY choose to deem that
1066 authentication has succeeded. However, if it has been too long since
1067 the previous authentication, or for any other reason, the server MAY
1068 send a new "digest-challenge" with a new value for nonce. The
1069 challenge MAY contain a "stale" directive with value "true", which
1070 says that the client may respond to the challenge using the password
1071 it used in the previous response; otherwise, the client must solicit
1072 the password anew from the user. This permits the server to make sure
1073 that the user has presented their password recently. (The directive
1074 name refers to the previous nonce being stale, not to the last use of
1078 Leach & Newman Expires: August 2004 [Page 18]
1084 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1087 the password.) Except for the handling of "stale", after sending the
1088 "digest-challenge" authentication proceeds as in the case of initial
1089 authentication.
1091 2.3 Integrity Protection
1093 If the server offered "qop=auth-int" and the client responded
1094 "qop=auth-int", then subsequent messages, up to but not including the
1095 next subsequent authentication, between the client and the server
1096 MUST be integrity protected. Using as a base session key the value of
1097 H(A1), as defined above the client and server calculate a pair of
1098 message integrity keys as follows.
1100 The key for integrity protecting messages from client to server is:
1102 Kic = MD5({H(A1),
1103 "Digest session key to client-to-server signing key magic constant"})
1105 The key for integrity protecting messages from server to client is:
1107 Kis = MD5({H(A1),
1108 "Digest session key to server-to-client signing key magic constant"})
1110 where MD5 is as specified in [RFC 1321]. If message integrity is
1111 negotiated, a MAC block for each message is appended to the message.
1112 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
1113 2104] of the message, a 2-byte message type number in network byte
1114 order with value 1, and the 4-byte sequence number in network byte
1115 order. The message type is to allow for future extensions such as
1116 rekeying.
1118 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
1119 SeqNum)
1121 where Ki is Kic for messages sent by the client and Kis for those
1122 sent by the server. The sequence number (SeqNum) is an unsigned
1123 number initialized to zero after initial or subsequent
1124 authentication, and incremented by one for each message
1125 sent/successfully verified. (Note, that there are two independent
1126 counters for sending and receiving.) The sequence number wraps around
1127 to 0 after 2**32-1.
1129 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
1130 received value; the message is discarded if they differ and as the
1131 result the connection being used MUST be dropped. The receiver's
1132 sequence counter is incremented if they match.
1134 2.4 Confidentiality Protection
1138 Leach & Newman Expires: August 2004 [Page 19]
1144 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1147 If the server sent a "cipher-opts" directive and the client responded
1148 with a "cipher" directive, then subsequent messages between the
1149 client and the server MUST be confidentiality protected. Using as a
1150 base session key the value of H(A1) as defined above the client and
1151 server calculate a pair of message integrity keys as follows.
1153 The key for confidentiality protecting messages from client to server
1154 is:
1156 Kcc = MD5({H(A1)[0..n-1],
1157 "Digest H(A1) to client-to-server sealing key magic constant"})
1159 The key for confidentiality protecting messages from server to client
1160 is:
1162 Kcs = MD5({H(A1)[0..n-1],
1163 "Digest H(A1) to server-to-client sealing key magic constant"})
1165 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
1166 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*"
1167 and "aes-cbc" ciphers is all 16 bytes of Kcc or Kcs.
1169 "aes-cbc" cipher works as described in section 2.4.1.
1171 rc4 cipher state MUST NOT be reset before sending/receiving a next
1172 buffer of security encoded data.
1175 If the blocksize of the chosen cipher is not 1 byte, the padding
1176 prefix is one or more octets each containing the number of padding
1177 bytes, such that the total length of the encrypted part of the
1178 message is a multiple of the blocksize.
1180 The MAC block is 16 bytes formatted as follows: the first 10 bytes of
1181 the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number
1182 in network byte order with value 1, and the 4-byte sequence number in
1183 network byte order.
1185 <<Proposal 1 ("explicit IV in each SASL block") is detailed below>>
1187 The padding and first 10 bytes of the MAC block are encrypted with
1188 the chosen cipher along with the message and explicit IV (if
1189 present).
1191 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {exp_iv, msg, pad, MAC})
1193 MAC(Ki, SeqNum, exp_iv, msg) = {HMAC(Ki, {SeqNum, exp_iv, msg})[0..9],
1194 packet_type_data, SeqNum}
1198 Leach & Newman Expires: August 2004 [Page 20]
1204 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1207 packet_type_data = 0x0001
1209 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
1210 messages sent by the client and Kis and Kcs for those sent by the
1211 server, exp_iv is empty string for rc4 ciphers and a randomly
1212 generated number R of the length 128 bit for the "aes-cbc" cipher.
1213 The sequence number (SeqNum) is an unsigned number initialized to
1214 zero after initial or subsequent authentication, and incremented by
1215 one for each message sent/successfully verified. (Note, that there
1216 are two independent counters for sending and receiving.) The sequence
1217 number wraps around to 0 after 2**32-1.
1219 Upon receipt, the message is decrypted, exp_iv is ignored (for the
1220 "aes-cbc" cipher only), HMAC(Ki, {SeqNum, msg}) is computed and
1221 compared with the received value; the padding and the packet type are
1222 verified. The message is discarded if the received and the
1223 calculated HMACs differ and/or the padding is invalid. See also
1224 section 3.8 for important information about MAC and padding
1225 verification. The receiver's sequence counter is then compared with
1226 the received SeqNum value; the message is discarded if they differ
1227 and, as the result, the connection being used MUST be dropped. The
1228 receiver's sequence counter is incremented if they match.
1231 <<Proposal 2 ("explicit IV in a separate SASL block") is detailed
1232 below:
1234 Instead of sending a single SASL block that contains encrypted
1235 (128bit of entropy, followed by cleartext), we can introduce a new
1236 block type, that will only contain the entropy. Clients that have
1237 limited CPU resources (or operate on a slow link) might choose to
1238 send these special blocks not for every block of encrypted data, but
1239 for every second (third, ...) block.
1241 So, instead of sending a single block SEAL(Ki, Kc, SeqNum, msg)
1242 described aboves there are two types of blocks:
1244 the first is a data block as in revision 02: SEAL(Ki, Kc, SeqNum,
1245 msg) = CIPHER(Kc, {msg, pad2, MAC}) MAC(Ki, SeqNum, msg) = {HMAC(Ki,
1246 {SeqNum, msg})[0..9], packet_type_data, SeqNum} packet_type_data =
1247 0x0001
1249 the second block type has a different type and contains encrypted IV:
1251 SEAL_IV(Ki, Kc, SeqNum) = CIPHER(Kc, {exp_iv, pad1, MAC_IV})
1252 MAC_IV(Ki, SeqNum, exp_iv) = {HMAC(Ki, {SeqNum, exp_iv})[0..9],
1253 packet_type_iv, SeqNum} packet_type_iv = 0x0002
1258 Leach & Newman Expires: August 2004 [Page 21]
1264 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1267 The second block is also protected by MAC that includes SeqNum. So,
1268 removing/replacing it will invalidate subsequent blocks.
1270 Advantages of this approach: 1) Less intrusive changes to already
1271 deployed code. Adding new block type might be easier. Also, the
1272 minimal block size is always 16 (with the proposal #1 it is either 16
1273 or 32). 2) Clients that want to sacrifice a bit of security in order
1274 to achieve faster performance can choose to send SEAL_IV blocks less
1275 frequently.
1277 Of course I am not a cryptographer, to judge if there are any issues
1278 with the alternative proposal.>>
1281 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 1]
1283 Unlike previous versions of DIGEST-MD5, this document uses an
1284 explicit IV for ciphers in CBC mode. This is done in order to prevent
1285 the attacks described by [CBCATT].
1287 For each buffer of cleartext data to be encrypted the sender performs
1288 the following procedure:
1290 0) For the very first SASL packet sent the IV is calculated as
1291 follows:
1293 The IV for the first SASL packet going from the client
1294 to the server (IVc) consists of 16 bytes calculated as follows:
1296 IVc = MD5({Kcc, "aes-128"})
1298 The IV for the first SASL packet going from the server
1299 to the client (IVs) consists of 16 bytes calculated as follows:
1301 IVs = MD5({Kcs, "aes-128"})
1303 For a subsequent packet: Em of the previous packet (see below)
1304 becomes the IV.
1306 1) Generate a cryptographically strong random number R of length 128
1307 bits (16 octets) and prepend it to the plaintext prior to
1308 encryption.
1310 2) padding and MAC block are constructed (see section 2.4) and
1311 appended to the end of the plaintext. After this step the data
1312 to be encrypted will look like:
1314 {R, msg, pad, MAC}
1318 Leach & Newman Expires: August 2004 [Page 22]
1324 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1327 As the total length of the data will be multiple of AES block size
1328 (i.e. 128 bit), this can also be represented as
1330 {P1, P2, P3, ..., Pm}
1332 where Pi is a chunk of data of the length 128 bit. Note, that
1333 P1 is R.
1335 3) Data is encrypted as follows:
1337 E1 = CIPHER ( Kc, P1 XOR IV )
1338 E2 = CIPHER ( Kc, P2 XOR E1 )
1339 E3 = CIPHER ( Kc, P3 XOR E2 )
1340 ...
1341 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1342 ...
1343 Em = CIPHER ( Kc, Pm XOR Em-1)
1345 This will generate ciphertext {E1, ..., Em} to be sent as a single
1346 SASL packet.
1349 The receiver performs the following steps:
1351 0) For the very first SASL packet sent the IV is calculated as
1352 in step 0 for the sender.
1354 For a subsequent packet: Em of the previous packet becomes
1355 the IV of the immediately following packet.
1357 1) Data is decrypted as follows:
1359 P1 = CIPHER ( Kc, E1 ) XOR IV
1360 P2 = CIPHER ( Kc, E2 ) XOR E1
1361 P3 = CIPHER ( Kc, E3 ) XOR E2
1362 ...
1363 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1364 ...
1365 Pm = CIPHER ( Kc, Em ) XOR Em-1
1367 Em becomes the IV for the decryption of the subsequent SASL
1368 packet.
1370 This will generate plaintext {P1, ..., Pm}. P1 is discarded,
1371 {P2, ..., Pm} is {msg, pad, MAC}.
1373 2) pad and MAC block are verified as described in section 2.4.
1378 Leach & Newman Expires: August 2004 [Page 23]
1384 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1387 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 2]
1389 Unlike previous versions of DIGEST-MD5, this document uses an
1390 explicit IV for ciphers in CBC mode. This is done in order to prevent
1391 the attacks described by [CBCATT].
1393 For each buffer of cleartext data to be encrypted the sender performs
1394 the following procedure:
1396 0) For the very first SASL packet sent the IV is calculated as
1397 follows:
1399 The IV for the first SASL packet going from the client
1400 to the server (IVc) consists of 16 bytes calculated as follows:
1402 IVc = MD5({Kcc, "aes-128"})
1404 The IV for the first SASL packet going from the server
1405 to the client (IVs) consists of 16 bytes calculated as follows:
1407 IVs = MD5({Kcs, "aes-128"})
1409 For a subsequent packet: Em of the previous packet (see below)
1410 becomes the IV.
1412 1) padding and MAC block are constructed (see section 2.4) and
1413 appended to the end of the plaintext. After this step the data
1414 to be encrypted will look like:
1416 {msg, pad, MAC}
1418 As the total length of the data will be multiple of AES block size
1419 (i.e. 128 bit), this can also be represented as
1421 {P1, P2, P3, ..., Pm}
1423 where Pi is a chunk of data of the length 128 bit.
1425 2) Data is encrypted as follows:
1427 E1 = CIPHER ( Kc, P1 XOR IV )
1428 E2 = CIPHER ( Kc, P2 XOR E1 )
1429 E3 = CIPHER ( Kc, P3 XOR E2 )
1430 ...
1431 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1432 ...
1433 Em = CIPHER ( Kc, Pm XOR Em-1)
1438 Leach & Newman Expires: August 2004 [Page 24]
1444 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1447 This will generate ciphertext {E1, ..., Em} to be sent as a single
1448 SASL packet.
1451 In order to mitigate the attacks described in [CBCATT] the sender
1452 should periodically send a new SASL packet that affects IV. This
1453 packet is constructed as follows:
1455 1) Generate a cryptographically strong random number R of length 128
1456 bits (16 octets) and prepend it to the plaintext prior to
1457 encryption.
1459 2) padding and MAC block are constructed (see section 2.4) and
1460 appended after R. After this step the data
1461 to be encrypted will look like:
1463 {R, pad, MAC_IV}
1465 As the total length of the data will be multiple of AES block size
1466 (i.e. 128 bit), this can also be represented as
1468 {P1, P2, P3, ..., Pm}
1470 where Pi is a chunk of data of the length 128 bit.
1472 3) Data is encrypted as follows (this is exactly the same procedure
1473 as for
1474 a data packets described above):
1476 E1 = CIPHER ( Kc, P1 XOR IV )
1477 E2 = CIPHER ( Kc, P2 XOR E1 )
1478 E3 = CIPHER ( Kc, P3 XOR E2 )
1479 ...
1480 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1481 ...
1482 Em = CIPHER ( Kc, Pm XOR Em-1)
1484 This will generate ciphertext {E1, ..., Em} to be sent as a single
1485 SASL packet.
1487 The receiver performs the following steps:
1489 0) For the very first SASL packet sent the IV is calculated as
1490 in step 0 for the sender.
1492 For a subsequent packet: Em of the previous packet becomes
1493 the IV of the immediately following packet.
1498 Leach & Newman Expires: August 2004 [Page 25]
1504 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1507 1) Data is decrypted as follows:
1509 P1 = CIPHER ( Kc, E1 ) XOR IV
1510 P2 = CIPHER ( Kc, E2 ) XOR E1
1511 P3 = CIPHER ( Kc, E3 ) XOR E2
1512 ...
1513 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1514 ...
1515 Pm = CIPHER ( Kc, Em ) XOR Em-1
1517 Em becomes the IV for the decryption of the subsequent SASL
1518 packet.
1520 This will generate plaintext {P1, ..., Pm} or {msgX, pad, MACX}.
1522 Packet type is extracted from MACX. If the packet type is 0x0001,
1523 the plaintext represents a data block with padding and MAC.
1524 If the packet type is 0x0002, the packet contains a random value
1525 R which affects IV followed by padding and MAC_IV. The random
1526 value
1527 R is ignored by the receiver.
1529 2) For both pad and MAC block are verified as described in section
1530 2.4.
1558 Leach & Newman Expires: August 2004 [Page 26]
1564 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1567 3 Security Considerations
1569 General SASL security considerations apply to this mechanism.
1570 "stringprep" and Unicode security considerations also apply.
1572 Detailed discussion of other DIGEST-MD5 specific security issues is
1573 below.
1575 3.1 Authentication of Clients using Digest Authentication
1577 Digest Authentication does not provide a strong authentication
1578 mechanism, when compared to public key based mechanisms, for example.
1579 However, since it prevents chosen plaintext attacks, it is stronger
1580 than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC
1581 2244], POP and IMAP [RFC 2195]. It is intended to replace the much
1582 weaker and even more dangerous use of plaintext passwords; however,
1583 since it is still a password based mechanism it avoids some of the
1584 potential deployabilty issues with public-key, OTP or similar
1585 mechanisms.
1587 Digest Authentication offers no confidentiality protection beyond
1588 protecting the actual password. All of the rest of the challenge and
1589 response are available to an eavesdropper, including the user's name
1590 and authentication realm.
1592 3.2 Comparison of Digest with Plaintext Passwords
1594 The greatest threat to the type of transactions for which these
1595 protocols are used is network snooping. This kind of transaction
1596 might involve, for example, online access to a mail service whose use
1597 is restricted to paying subscribers. With plaintext password
1598 authentication an eavesdropper can obtain the password of the user.
1599 This not only permits him to access anything in the database, but,
1600 often worse, will permit access to anything else the user protects
1601 with the same password.
1603 3.3 Replay Attacks
1605 Replay attacks are defeated if the client or the server chooses a
1606 fresh nonce for each authentication, as this specification requires.
1608 As a security precaution, the server, when verifying a response from
1609 the client, must use the original server nonce ("nonce") it sent, not
1610 the one returned by the client in the response, as it might have been
1611 modified by an attacker.
1613 To prevent some redirection attacks it is recommended that the server
1614 verifies that the "serv-type" part of the "digest-uri" matches the
1618 Leach & Newman Expires: August 2004 [Page 27]
1624 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1627 service name and that the hostname/IP address belongs to the server.
1629 3.4 Online dictionary attacks
1631 If the attacker can eavesdrop, then it can test any overheard
1632 nonce/response pairs against a (potentially very large) list of
1633 common words. Such a list is usually much smaller than the total
1634 number of possible passwords. The cost of computing the response for
1635 each password on the list is paid once for each challenge.
1637 The server can mitigate this attack by not allowing users to select
1638 passwords that are in a dictionary.
1640 3.5 Offline dictionary attacks
1642 If the attacker can choose the challenge, then it can precompute the
1643 possible responses to that challenge for a list of common words. Such
1644 a list is usually much smaller than the total number of possible
1645 passwords. The cost of computing the response for each password on
1646 the list is paid just once.
1648 Offline dictionary attacks are defeated if the client chooses a fresh
1649 nonce for each authentication, as this specification requires.
1651 3.6 Man in the Middle
1653 Digest authentication is vulnerable to "man in the middle" (MITM)
1654 attacks. Clearly, a MITM would present all the problems of
1655 eavesdropping. But it also offers some additional opportunities to
1656 the attacker.
1658 A possible man-in-the-middle attack would be to substitute a weaker
1659 qop scheme for the one(s) sent by the server; the server will not be
1660 able to detect this attack. For this reason, the client should always
1661 use the strongest scheme that it understands from the choices
1662 offered, and should never choose a scheme that does not meet its
1663 minimum requirements.
1665 A man-in-the-middle attack may also make the client and the server
1666 that agreed to use confidentiality protection to use different (and
1667 possibly weaker) cipher's. This is because the chosen cipher is not
1668 used in the shared secret calculation.
1670 3.7 Chosen plaintext attacks
1672 A chosen plaintext attack is where a MITM or a malicious server can
1673 arbitrarily choose the challenge that the client will use to compute
1674 the response. The ability to choose the challenge is known to make
1678 Leach & Newman Expires: August 2004 [Page 28]
1684 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1687 cryptanalysis much easier [MD5].
1689 However, Digest does not permit the attack to choose the challenge as
1690 long as the client chooses a fresh nonce for each authentication, as
1691 this specification requires.
1693 3.8 CBC Mode attacks
1695 The following attack can be launched when the connection uses
1696 Confidentiality protection with ciphers in CBC mode. If bad padding
1697 is treated differently from bad MACs when decrypting a DIGEST-MD5
1698 buffer of security encoded data, the attacker may be able to launch
1699 Vaudenay's attack on padding.
1701 An error logfile will suffice to launch the attack if it reveals the
1702 type of error -- even if file permissions prevent the attacker from
1703 actually reading the file (the file length increase cause by the
1704 attack is likely to reveal which of the two errors occured).
1706 A different approach to distinguish these two error cases and launch
1707 the attack is to examine the timing of error responses: if the MAC
1708 verification is skipped when bad padding has been found, the error
1709 will appear quicker in the case of incorrect block cipher padding
1710 than in the case of an incorrect MAC.
1712 A countermeasure is to compute a MAC of the plaintext anyway, even if
1713 the usual padding removal step fails because of incorrect padding, to
1714 obtain (nearly) uniform timing.
1716 3.9 Spoofing by Counterfeit Servers
1718 If a user can be led to believe that she is connecting to a host
1719 containing information protected by a password she knows, when in
1720 fact she is connecting to a hostile server, then the hostile server
1721 can obtain challenge/response pairs where it was able to partly
1722 choose the challenge. There is no known way that this can be
1723 exploited.
1725 3.10 Storing passwords
1727 Digest authentication requires that the authenticating agent (usually
1728 the server) store some data derived from the user's name and password
1729 in a "password file" associated with a given realm. Normally this
1730 might contain pairs consisting of username and H({ username-value,
1731 ":", realm-value, ":", passwd }), which is adequate to compute H(A1)
1732 as described above without directly exposing the user's password.
1734 The security implications of this are that if this password file is
1738 Leach & Newman Expires: August 2004 [Page 29]
1744 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1747 compromised, then an attacker gains immediate access to documents on
1748 the server using this realm. Unlike, say a standard UNIX password
1749 file, this information need not be decrypted in order to access
1750 documents in the server realm associated with this file. On the other
1751 hand, decryption, or more likely a brute force attack, would be
1752 necessary to obtain the user's password. This is the reason that the
1753 realm is part of the digested data stored in the password file. It
1754 means that if one Digest authentication password file is compromised,
1755 it does not automatically compromise others with the same username
1756 and password (though it does expose them to brute force attack).
1758 There are two important security consequences of this. First the
1759 password file must be protected as if it contained plaintext
1760 passwords, because for the purpose of accessing documents in its
1761 realm, it effectively does.
1763 A second consequence of this is that the realm string should be
1764 unique among all realms that any single user is likely to use. In
1765 particular a realm string should include the name of the host doing
1766 the authentication.
1798 Leach & Newman Expires: August 2004 [Page 30]
1804 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1807 3.11 Multiple realms
1809 Use of multiple realms may mean both that compromise of a the
1810 security database for a single realm does not compromise all
1811 security, and that there are more things to protect in order to keep
1812 the whole system secure.
1814 3.11 Summary
1816 By modern cryptographic standards Digest Authentication is weak,
1817 compared to (say) public key based mechanisms. But for a large range
1818 of purposes it is valuable as a replacement for plaintext passwords.
1819 Its strength may vary depending on the implementation.
1822 4 Example
1824 This example shows the use of the Digest SASL mechanism with the
1825 IMAP4 AUTHENTICATE command [RFC 3501].
1827 In this example, "C:" and "S:" represent a line sent by the client or
1828 server respectively including a CRLF at the end. Linebreaks and
1829 indentation within a "C:" or "S:" are editorial and not part of the
1830 protocol. The password in this example was "secret". Note that the
1831 base64 encoding of the challenges and responses is part of the IMAP4
1832 AUTHENTICATE command, not part of the Digest specification itself.
1834 S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
1835 C: c CAPABILITY
1836 S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
1837 UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
1838 S: c OK Completed
1839 C: a AUTHENTICATE DIGEST-MD5
1840 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
1841 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
1842 cnNldD11dGYtOA==
1843 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
1844 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
1845 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
1846 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
1847 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
1848 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
1849 C:
1850 S: a OK User logged in
1851 ---
1853 The base64-decoded version of the SASL exchange is:
1858 Leach & Newman Expires: August 2004 [Page 31]
1864 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1867 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
1868 algorithm=md5-sess,charset=utf-8
1869 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1870 nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
1871 digest-uri="imap/elwood.innosoft.com",
1872 response=d388dad90d4bbd760a152321f2143af7,qop=auth
1873 S: rspauth=ea40f60335c427b5527b84dbabcdfffd
1875 The password in this example was "secret".
1877 This example shows the use of the Digest SASL mechanism with the
1878 ACAP, using the same notational conventions and password as in the
1879 previous example. Note that ACAP does not base64 encode and uses
1880 fewer round trips that IMAP4.
1882 S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
1883 "DIGEST-MD5" "PLAIN")
1884 C: a AUTHENTICATE "DIGEST-MD5"
1885 S: + {94}
1886 S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
1887 algorithm=md5-sess,charset=utf-8
1888 C: {206}
1889 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1890 nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
1891 digest-uri="acap/elwood.innosoft.com",
1892 response=6084c6db3fede7352c551284490fd0fc,qop=auth
1893 S: a OK (SASL {40}
1894 S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
1895 Completed"
1896 ---
1898 The server uses the values of all the directives, plus knowledge of
1899 the users password (or the hash of the user's name, server's realm
1900 and the user's password) to verify the computations above. If they
1901 check, then the user has authenticated.
1918 Leach & Newman Expires: August 2004 [Page 32]
1924 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1927 5 References
1929 5.1 Normative references
1931 [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
1932 Access Authentication", RFC 2617, June 1999.
1934 [ISO-8859] ISO-8859. International Standard--Information Processing--
1935 8-bit Single-Byte Coded Graphic Character Sets --
1936 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
1937 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
1938 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
1939 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
1940 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
1941 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
1942 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
1943 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
1944 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
1946 [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
1947 Text Messages," STD 11, RFC 822, August 1982.
1949 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1950 April 1992.
1952 [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1953 location of services (DNS SRV)", RFC 2052, October 1996.
1955 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1956 Hashing for Message Authentication", RFC 2104, February
1957 1997.
1959 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1960 Requirement Levels", BCP 14, RFC 2119, March 1997.
1962 [RFC 2222] Melnikov, A. (editor), "Simple Authentication and Security
1963 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work
1964 in progress.
1966 [RFC 3454] Hoffman, P., Blanchet, M., "Preparation of
1967 Internationalized Strings ("stringprep")", RFC 3454,
1968 December 2002.
1970 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1971 3.2.0", defined by: The Unicode Standard, Version 3.0
1972 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
1973 as amended by the Unicode Standard Annex #28: Unicode 3.2
1974 (http://www.unicode.org/reports/tr28/tr28-3.html).
1978 Leach & Newman Expires: August 2004 [Page 33]
1984 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
1987 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646",
1988 RFC 2279, Janyary 1998.
1990 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
1991 Code for Information Interchange. Standard ANSI X3.4-1986,
1992 ANSI, 1986.
1994 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1995 and passwords", Work in progress, draft-ietf-sasl-
1996 saslprep-XX.txt.
1998 [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
1999 Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
2001 [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing
2002 Architecture", RFC 2373, July 1998.
2004 [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
2005 Resource Identifiers (URI): Generic Syntax", RFC 2396,
2006 August 1998.
2008 [FIPS] National Institute of Standards and Technology, "DES Modes
2009 of Operation", http://www.itl.nist.gov/fipspubs/fip81.htm,
2010 December 1980.
2012 [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",
2013 http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf,
2014 3rd September 1999.
2017 5.2 Informative references
2019 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
2020 AUTHorize Extension for Simple Challenge/Response", RFC
2021 2195, September 1997.
2023 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with
2024 MD5", CryptoBytes, Sping 1995, RSA Inc,
2025 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
2027 [RFC 2078] Linn, J., "Generic Security Service Application Program
2028 Interface, Version 2", RFC 2078, January 1997.
2030 [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version
2031 4rev1", RFC 3501, March 2003.
2033 [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
2034 Access Protocol", RFC 2244, November 1997.
2038 Leach & Newman Expires: August 2004 [Page 34]
2044 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2047 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2048 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext
2049 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2051 [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
2052 Problems and Countermeasures",
2053 http://www.openssl.org/~bodo/tls-cbc.txt.
2055 [CBCATT] Canvel, B., "Password Interception in a SSL/TLS Channel",
2056 published 2003-02-20:
2057 http://lasecwww.epfl.ch/memo_ssl.shtml
2098 Leach & Newman Expires: August 2004 [Page 35]
2104 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2107 6 Authors' Addresses
2109 Paul Leach
2110 Microsoft
2111 1 Microsoft Way
2112 Redmond, WA 98052, USA
2114 EMail: paulle@microsoft.com
2117 Chris Newman
2118 Sun Microsystems
2119 1050 Lakes Drive
2120 West Covina, CA 91790, USA
2122 EMail: Chris.Newman@Sun.COM
2125 Alexey Melnikov
2126 Isode Ltd.
2127 5 Castle Business Village,
2128 36 Station Road,
2129 Hampton,
2130 Middlesex,
2131 TW12 2BX,
2132 United Kingdom
2134 Email: Alexey.Melnikov@isode.com
2158 Leach & Newman Expires: August 2004 [Page 36]
2164 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2167 7 ABNF
2169 What follows is the definition of the notation as is used in the
2170 HTTP/1.1 specification [RFC 2616] and the HTTP authentication
2171 specification [Digest]; it is reproduced here for ease of reference.
2172 Since it is intended that a single Digest implementation can support
2173 both HTTP and SASL-based protocols, the same notation is used in both
2174 to facilitate comparison and prevention of unwanted differences.
2175 Since it is cut-and-paste from the HTTP specifications, not all
2176 productions may be used in this specification. It is also not quite
2177 legal ABNF; again, the errors were copied from the HTTP
2178 specifications.
2180 7.1 Augmented BNF
2182 All of the mechanisms specified in this document are described in
2183 both prose and an augmented Backus-Naur Form (BNF) similar to that
2184 used by RFC 822 [RFC 822]. Implementers will need to be familiar with
2185 the notation in order to understand this specification.
2187 The augmented BNF includes the following constructs:
2189 name = definition
2190 The name of a rule is simply the name itself (without any
2191 enclosing "<" and ">") and is separated from its definition by the
2192 equal "=" character. White space is only significant in that
2193 indentation of continuation lines is used to indicate a rule
2194 definition that spans more than one line. Certain basic rules are
2195 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
2196 brackets are used within definitions whenever their presence will
2197 facilitate discerning the use of rule names.
2199 "literal"
2200 Quotation marks surround literal text. Unless stated otherwise,
2201 the text is case-insensitive.
2203 rule1 | rule2
2204 Elements separated by a bar ("|") are alternatives, e.g., "yes |
2205 no" will accept yes or no.
2207 (rule1 rule2)
2208 Elements enclosed in parentheses are treated as a single element.
2209 Thus, "(elem (foo | bar) elem)" allows the token sequences
2210 "elem foo elem" and "elem bar elem".
2212 *rule
2213 The character "*" preceding an element indicates repetition. The
2214 full form is "<n>*<m>element" indicating at least <n> and at most
2218 Leach & Newman Expires: August 2004 [Page 37]
2224 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2227 <m> occurrences of element. Default values are 0 and infinity so
2228 that "*(element)" allows any number, including zero; "1*element"
2229 requires at least one; and "1*2element" allows one or two.
2231 [rule]
2232 Square brackets enclose optional elements; "[foo bar]" is
2233 equivalent to "*1(foo bar)".
2235 N rule
2236 Specific repetition: "<n>(element)" is equivalent to
2237 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
2238 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
2239 alphabetic characters.
2241 #rule
2242 A construct "#" is defined, similar to "*", for defining lists of
2243 elements. The full form is "<n>#<m>element" indicating at least
2244 <n> and at most <m> elements, each separated by one or more commas
2245 (",") and OPTIONAL linear white space (LWS). This makes the usual
2246 form of lists very easy; a rule such as
2247 ( *LWS element *( *LWS "," *LWS element ) *LWS )
2248 can be shown as
2249 1#element
2250 Wherever this construct is used, null elements are allowed, but do
2251 not contribute to the count of elements present. That is,
2252 "(element), , (element) " is permitted, but counts as only two
2253 elements. Therefore, where at least one element is required, at
2254 least one non-null element MUST be present. Default values are 0
2255 and infinity so that "#element" allows any number, including zero;
2256 "1#element" requires at least one; and "1#2element" allows one or
2257 two.
2259 ; comment
2260 A semi-colon, set off some distance to the right of rule text,
2261 starts a comment that continues to the end of line. This is a
2262 simple way of including useful notes in parallel with the
2263 specifications.
2265 implied *LWS
2266 The grammar described by this specification is word-based. Except
2267 where noted otherwise, linear white space (LWS) can be included
2268 between any two adjacent words (token or quoted-string), and
2269 between adjacent words and separators, without changing the
2270 interpretation of a field. At least one delimiter (LWS and/or
2271 separators) MUST exist between any two tokens (for the definition
2272 of "token" below), since they would otherwise be interpreted as a
2273 single token.
2278 Leach & Newman Expires: August 2004 [Page 38]
2284 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2287 7.2 Basic Rules
2289 The following rules are used throughout this specification to
2290 describe basic parsing constructs. The US-ASCII coded character set
2291 is defined by ANSI X3.4-1986 [USASCII].
2293 OCTET = <any 8-bit character>
2294 CHAR = <any US-ASCII character (octets 0 - 127)>
2295 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
2296 LOALPHA = <any US-ASCII lowercase letter "a".."z">
2297 ALPHA = UPALPHA | LOALPHA
2298 DIGIT = <any US-ASCII digit "0".."9">
2299 CTL = <any US-ASCII control character
2300 (octets 0 - 31) and DEL (127)>
2301 CR = <US-ASCII CR, carriage return (13)>
2302 LF = <US-ASCII LF, linefeed (10)>
2303 SP = <US-ASCII SP, space (32)>
2304 HT = <US-ASCII HT, horizontal-tab (9)>
2305 <"> = <US-ASCII double-quote mark (34)>
2306 TEXTCHAR = <any OCTET except CTLs, but including HT>
2307 CRLF = CR LF
2309 All linear white space, including folding, has the same semantics as
2310 SP. A recipient MAY replace any linear white space with a single SP
2311 before interpreting the field value or forwarding the message
2312 downstream.
2314 LWS = [CRLF] 1*( SP | HT )
2316 The TEXT rule is only used for descriptive field contents and values
2317 that are not intended to be interpreted by the message parser. Words
2318 of TEXT contains characters either from ISO-8859-1 [ISO-8859]
2319 character set or UTF-8 [UTF-8].
2321 TEXT = <any *OCTET except CTLs,
2322 but including LWS>
2324 A CRLF is allowed in the definition of TEXT only as part of a header
2325 field continuation. It is expected that the folding LWS will be
2326 replaced with a single SP before interpretation of the TEXT value.
2328 Hexadecimal numeric characters are used in several protocol elements.
2330 HEX = "A" | "B" | "C" | "D" | "E" | "F"
2331 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
2333 Many HTTP/1.1 header field values consist of words separated by LWS
2334 or special characters. These special characters MUST be in a quoted
2338 Leach & Newman Expires: August 2004 [Page 39]
2344 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2347 string to be used within a parameter value.
2349 token = 1*TOKENCHAR
2350 separators = "(" | ")" | "<" | ">" | "@"
2351 | "," | ";" | ":" | "\" | <">
2352 | "/" | "[" | "]" | "?" | "="
2353 | "{" | "}" | SP | HT
2354 TOKENCHAR = <any CHAR except CTLs or separators>
2356 A string of text is parsed as a single word if it is quoted using
2357 double-quote marks.
2359 quoted-string = ( <"> qdstr-val <"> )
2360 qdstr-val = *( qdtext | quoted-pair )
2361 qdtext = <any TEXTCHAR except <"> and "\">
2363 Note that LWS is NOT implicit between the double-quote marks (<">)
2364 surrounding a qdstr-val and the qdstr-val; any LWS will be considered
2365 part of the qdstr-val. This is also the case for quotation marks
2366 surrounding any other construct.
2368 The backslash character ("\") MAY be used as a single-character
2369 quoting mechanism only within qdstr-val and comment constructs.
2371 quoted-pair = "\" CHAR
2373 The value of this construct is CHAR. Note that an effect of this rule
2374 is that backslash itself MUST be quoted.
2398 Leach & Newman Expires: August 2004 [Page 40]
2404 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2407 8 Sample Code
2409 The sample implementation in [Digest] also applies to DIGEST-MD5.
2411 The following code implements the conversion from UTF-8 to 8859-1 if
2412 necessary.
2414 /* if the string is entirely in the 8859-1 subset of UTF-8, then
2415 * translate to 8859-1 prior to MD5
2416 */
2417 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
2418 int len)
2419 {
2420 const unsigned char *scan, *end;
2421 unsigned char cbuf;
2423 end = base + len;
2424 for (scan = base; scan < end; ++scan) {
2425 if (*scan > 0xC3) break; /* abort if outside 8859-1 */
2426 if (*scan >= 0xC0 && *scan <= 0xC3) {
2427 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
2428 break;
2429 }
2430 }
2431 /* if we found a character outside 8859-1, don't alter string
2432 */
2433 if (scan < end) {
2434 MD5Update(ctx, base, len);
2435 return;
2436 }
2438 /* convert to 8859-1 prior to applying hash
2439 */
2440 do {
2441 for (scan = base; scan < end && *scan < 0xC0; ++scan)
2442 ;
2443 if (scan != base) MD5Update(ctx, base, scan - base);
2444 if (scan + 1 >= end) break;
2445 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
2446 MD5Update(ctx, &cbuf, 1);
2447 base = scan + 2;
2448 } while (base < end);
2449 }
2458 Leach & Newman Expires: August 2004 [Page 41]
2464 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2467 10 Acknowledgements
2469 The following people had substantial contributions to the development
2470 and/or refinement of this document:
2472 Lawrence Greenfield
2473 John Gardiner Myers
2474 Simon Josefsson
2475 RL Bob Morgan
2476 Jeff Hodges
2477 Claus Assmann
2478 Tony Hansen
2479 Ken Murchison
2480 Sam Hartman
2481 Kurt D. Zeilenga
2482 Hallvard B. Furuseth
2484 as well as other members of the SASL mailing list.
2486 The text used is section 3.8 was taken from [TLS-CBC] by Bodo Moeller.
2518 Leach & Newman Expires: August 2004 [Page 42]
2524 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2527 11 Full Copyright Statement
2529 Copyright (C) The Internet Society (2004). All Rights Reserved.
2531 This document and translations of it may be copied and furnished to
2532 others, and derivative works that comment on or otherwise explain it
2533 or assist in its implementation may be prepared, copied, published
2534 and distributed, in whole or in part, without restriction of any
2535 kind, provided that the above copyright notice and this paragraph are
2536 included on all such copies and derivative works. However, this
2537 document itself may not be modified in any way, such as by removing
2538 the copyright notice or references to the Internet Society or other
2539 Internet organizations, except as needed for the purpose of
2540 developing Internet standards in which case the procedures for
2541 copyrights defined in the Internet Standards process must be
2542 followed, or as required to translate it into languages other than
2543 English.
2545 The limited permissions granted above are perpetual and will not be
2546 revoked by the Internet Society or its successors or assigns.
2548 This document and the information contained herein is provided on an
2549 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2550 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2551 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2552 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2553 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2555 Acknowledgement
2557 Funding for the RFC Editor function is currently provided by the
2558 Internet Society.
2578 Leach & Newman Expires: August 2004 [Page 43]
2584 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2587 Appendix A: Changes from 2831
2589 1). Fixed various typos in formulas.
2591 2). Dropped DES as mandatory to implement cipher (rc4 is mandatory to
2592 implement).
2594 3). Tighten ABNF. Fixed some bugs.
2596 4). Clarified nc-value verification and which side is aborting
2597 exchange.
2599 5). Added text saying that for interoperability
2600 username/password/realm MUST be prepared using the "SASLPrep" profile
2601 [SASLPrep] of the "stringprep" algorithm [RFC 3454].
2603 6). Clarified that unquoted version of the username, etc. used in A1
2604 calculation.
2606 7). Various cleanup to References section. Split all references to
2607 Normative and Informative.
2609 8). Added minimal and maximal limits on maxbuf. Clarified how to
2610 calculate max sender size.
2612 9). Change ABNF for host to allow for IPv6 addresses. ABNF now
2613 references RFC 2373 and RFC 2396.
2615 10). Added DES cipher interoperability section.
2617 11). Added man-in-the-middle considerations for ciphers.
2619 12). Clarified how sequence counters are updated.
2621 13). Addition warnings about preventing reply/redirection attacks.
2623 14). Specified that "charset" directive affects "realm" and doesn't
2624 affect
2625 "authzid".
2627 15). Removed text that described that "authzid" is in Unicode in
2628 Normalization
2629 Form KC, encoded as UTF-8.
2631 16). Clarified that rc4 state is not reset between two consecutive
2632 sent/received
2633 buffers of encoded data.
2638 Leach & Newman Expires: August 2004 [Page 44]
2644 INTERNET DRAFT DIGEST-MD5 SASL Mechanism February 2004
2647 17). Clarified that for DES/3DES the IV for the next buffer of
2648 encoded data is
2649 the last 8 bytes of the ciphertext.
2651 18). Clarified how "maximal sender size" is calculated.
2653 19). Prohibit an empty authzid, as this caused interoperability
2654 problems.
2656 20). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL
2657 mechanism"
2658 document (expired draft-ietf-sasl-digest-aes-00.txt).
2660 21). Removed "des" and "3des" ciphers because of known
2661 interoperability problems
2662 and vulnerability to CBC mode attack.
2664 22). Use explicit IV with aes cipher in CBC mode.
2666 23). Changed "aes" cipher option name to "aes-cbc", because -03
2667 introduces new
2668 encryption procedure.
2670 24). Cleaned up Confidentiality protection section. Added step by
2671 step exlanation
2672 how CBC mode is used.
2674 25). Added clarification which end and under what conditions has to
2675 perform SASLPrep
2676 (still work in progress).
2678 And other minor text clarifications.
2681 Appendix B: Open Issues/ToDo List
2683 1). The latest revision prohibits escaped characters in nonce/cnonce.
2684 This is different
2685 from HTTP Digest. Any objections?
2687 2). Do we need/want a new stringprep profile for "realm"?
2689 3). Resolve ISO-8859-1 and SaslPrep interaction issue as reported by
2690 Simon Josefsson.
2692 4). Add more examples that show how realm may look like.
2694 5). Normative vs. Informative references must be carefully rechecked.
2698 Leach & Newman Expires: August 2004 [Page 45]