| blob | cb6b8bf22cca488ec3c8f2d385be8c8efad38c5e |
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 July 2005
15 Using Digest Authentication as a SASL Mechanism
16 draft-ietf-sasl-rfc2831bis-06.txt
18 Status of this Memo
20 By submitting this Internet-Draft, each author represents that any
21 applicable patent or other IPR claims of which he or she is aware
22 have been or will be disclosed, and any of which he or she becomes
23 aware will be disclosed, in accordance with Section 6 of BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress".
35 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/ietf/1id-abstracts.txt
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 Copyright Notice
43 Copyright (C) The Internet Society (2005). All Rights Reserved.
45 Abstract
47 This specification defines how HTTP Digest Authentication [Digest]
48 can be used as a SASL [RFC 2222] mechanism for any protocol that has
49 a SASL profile. It is intended both as an improvement over CRAM-MD5
50 [RFC 2195] and as a convenient way to support a single authentication
51 mechanism for web, mail, LDAP, and other protocols.
58 Leach & Newman Expires: January 2006 [Page 1]
64 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 IANA CONSIDERATIONS.............................................28
100 7 ABNF............................................................29
101 7.1 AUGMENTED BNF................................................29
102 7.2 BASIC RULES..................................................31
103 8 SAMPLE CODE.....................................................33
104 9 AUTHORS' ADDRESSES..............................................XX
105 10 ACKNOWLEDGEMENTS..............................................34
106 11 FULL COPYRIGHT STATEMENT.......................................35
107 Appendix A: Changes from 2831.....................................36
108 Appendix B: Open Issues...........................................37
110 <<Page numbers are all wrong, sorry.
111 Section ordering should be changed too>>
118 Leach & Newman Expires: January 2006 [Page 2]
124 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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: January 2006 [Page 3]
184 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 <<Other terms like "protocol profile" are 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: January 2006 [Page 4]
244 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 supports reauthentication and it has successfully authenticated to
254 the server before, the client may be able to use the more efficient
255 fast reauthentication mode as described in section 2.2.
257 The following sections describe these two modes in details.
259 2.1 Initial Authentication
261 If the client has not recently authenticated to the server, then it
262 must perform "initial authentication", as defined in this section. If
263 it has recently authenticated, then a more efficient form is
264 available, defined in the next section.
266 2.1.1 Step One
268 The server starts by sending a challenge. The data encoded in the
269 challenge is formatted according to the rules for the "digest-
270 challenge" defined as follows:
298 Leach & Newman Expires: January 2006 [Page 5]
304 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 = quoted-string
313 nonce = "nonce" "=" nonce-value
314 nonce-value = quoted-string
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 = "rc4-40" | "rc4" | "rc4-56" |
329 "aes-cbc" | cipher-token
330 ;; cipher-token is reserved for new ciphersuites
331 cipher-token = token
332 auth-param = token "=" ( token | quoted-string )
334 The meanings of the values of the directives used above are as
335 follows:
337 realm
338 Mechanistically, a string which enables users to decide which
339 username and password to use, in case they have different ones for
340 different servers. Conceptually, it is the name of a collection
341 of accounts that might include the user's account. This string
342 should contain the name of the host performing the authentication
343 and might additionally indicate the collection of users who might
344 have access. An example might be
345 "registered_users@gotham.news.example.com". Note that the server
346 MAY not advertise (hide) some or all realms it supports.
348 Other examples:
350 1) "dc=gotham, dc=news, dc=example, dc=com".
352 2) If there are two servers (e.g. server1.example.com and
353 server2.example.com) that share authentication database, they
354 both may advertise "example.com" as the realm.
358 Leach & Newman Expires: January 2006 [Page 6]
364 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
367 A server implementation that uses a fixed string as the advertised
368 realm is compliant with this specification, however this is not
369 recommended. See also sections 3.10 "Storing passwords" and 3.11
370 "Multiple realms" for discussion.
372 The value of this directive is case-sensitive. This directive is
373 optional; if not present, the client SHOULD solicit it from the
374 user or be able to compute a default; a plausible default might be
375 the realm supplied by the user when they logged in to the client
376 system. Multiple realm directives are allowed, in which case the
377 user or client must choose one as the realm for which to supply
378 username and password.
380 Requirements on UIs: UIs MUST allow users to enter arbitrary user
381 names and realm names. In order to achieve this, UIs MAY present
382 two separate edit boxes. Alternatively, UIs MAY present a single
383 edit box and allow user to enter a special character that
384 separates user name from the realm name. In the latter case, UIs
385 MUST be able to escape the special character and they need to
386 present their escape rules to the user. UIs MUST also present the
387 list of realms advertised by the server.
389 nonce
390 A server-specified data string which MUST be different each time a
391 digest-challenge is sent as part of initial authentication. It is
392 recommended that this string be base64 [RFC 3548] or hexadecimal
393 data. Note that the whole string is enclosed in double-quote
394 characters, however quote-characters or escape characters are not
395 allowed in the string, even when quoted. This is different from
396 the RFC 2821. The contents of the nonce are implementation
397 dependent. The security of the implementation depends on a good
398 choice. It is RECOMMENDED that it contain at least 64 bits of
399 entropy. The nonce is opaque to the client. This directive is
400 required and MUST appear exactly once; if not present, or if
401 multiple instances are present, the client should abort the
402 authentication exchange.
404 qop-options
405 A quoted string of one or more comma-separated tokens indicating
406 the "quality of protection" values supported by the server. The
407 value "auth" indicates authentication; the value "auth-int"
408 indicates authentication with integrity protection; the value
409 "auth-conf" indicates authentication with integrity protection and
410 encryption. This directive is optional; if not present it
411 defaults to "auth". The client MUST ignore unrecognized options;
412 if the client recognizes no option, it MUST abort the
413 authentication exchange.
418 Leach & Newman Expires: January 2006 [Page 7]
424 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 MUST 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 guarantee that the
453 receiver will never get a block bigger than the maxbuf.
478 Leach & Newman Expires: January 2006 [Page 8]
484 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 encoded as UTF-8
491 [UTF-8]. If not present, the username, realm and password used by
492 the client in Step 2 MUST be encoded in ISO 8859-1 [ISO-8859] (of
493 which US-ASCII [USASCII] is a subset). The directive is needed for
494 backwards compatibility with HTTP Digest, which only supports ISO
495 8859-1. This directive may appear at most once; if multiple
496 instances are present, the client MUST abort the authentication
497 exchange.
499 Note, that this directive doesn't affect authorization id
500 ("authzid").
502 algorithm
503 This directive is required for backwards compatibility with HTTP
504 Digest, which supports other algorithms. This directive is
505 required and MUST appear exactly once; if not present, or if
506 multiple instances are present, the client SHOULD abort the
507 authentication exchange.
509 cipher-opts
510 A list of ciphers that the server supports. This directive must be
511 present exactly once if "auth-conf" is offered in the
512 "qop-options" directive, in which case the "rc4" cipher is
513 mandatory-to-implement. The client MUST ignore unrecognized
514 ciphers; if the client recognizes no cipher, it MUST behave as if
515 "auth-conf" qop option wasn't provided by the server. If the
516 client recognizes no cipher and the server only advertised "auth-
517 conf" in the qop option, the client MUST abort the authentication
518 exchange. See section 2.4 for more detailed description of the
519 ciphers.
521 rc4, rc4-40, rc4-56
522 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
523 respectively.
525 aes-cbc
526 the Advanced Encryption Standard (AES) cipher [AES] in cipher
527 block chaining (CBC) mode with a 128 bit key and explicit
528 Initialization Vector (IV). This mode requires an IV that has
529 the same size as the block size.
531 auth-param
532 This construct allows for future extensions; it may appear more
533 than once. The client MUST ignore any unrecognized directives.
538 Leach & Newman Expires: January 2006 [Page 9]
544 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
547 For use as a SASL mechanism, note that the following changes are made
548 to "digest-challenge" from HTTP: the following Digest options (called
549 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
550 and MUST be ignored if received):
552 opaque
553 domain
555 The size of a digest-challenge MUST be less than 2048 bytes.
557 2.1.2 Step Two
559 The client makes note of the "digest-challenge" and then responds
560 with a string formatted and computed according to the rules for a
561 "digest-response" defined as follows:
563 digest-response = 1#( username | realm | nonce | cnonce |
564 nonce-count | qop | digest-uri | response |
565 client_maxbuf | charset | cipher | authzid |
566 auth-param )
568 username = "username" "=" username-value
569 username-value = quoted-string
570 cnonce = "cnonce" "=" cnonce-value
571 cnonce-value = nonce-value
572 nonce-count = "nc" "=" nc-value
573 nc-value = 8LHEX
574 client_maxbuf = "maxbuf" "=" maxbuf-value
575 qop = "qop" "=" qop-value
576 digest-uri = "digest-uri" "=" <"> digest-uri-value <">
577 digest-uri-value = serv-type "/" host [ "/" serv-name ]
578 serv-type = 1*ALPHA
579 serv-name = host
580 response = "response" "=" response-value
581 response-value = 32LHEX
582 LHEX = "0" | "1" | "2" | "3" |
583 "4" | "5" | "6" | "7" |
584 "8" | "9" | "a" | "b" |
585 "c" | "d" | "e" | "f"
586 cipher = "cipher" "=" cipher-value
587 authzid = "authzid" "=" authzid-value
588 authzid-value = quoted-string
590 The 'host' non-terminal is defined in [RFC 3986] as
592 host = IP-literal / IPv4address / reg-name
594 username
598 Leach & Newman Expires: January 2006 [Page 10]
604 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
607 The user's name in the specified realm, encoded according to the
608 value of the "charset" directive. This directive is REQUIRED and
609 MUST be present exactly once; otherwise, authentication fails.
611 If the charset directive is also specified (which means that the
612 username is encoded as UTF-8) the client MUST first check if all
613 the characters of the username are in the ISO 8859-1 character
614 set. If they are, no further changes are performed. Otherwise, the
615 client SHOULD prepare the username using the "SASLPrep" profile
616 [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If the
617 preparation of the username fails or results in an empty string,
618 the client SHOULD abort the authentication exchange (*). If the
619 preparation succeeds, the prepared value will be sent to the
620 server and used in hash computations described in section 2.1.2.1.
622 (*) An interactive client can request a repeated entry of username
623 value.
625 realm
626 The realm containing the user's account, encoded according to the
627 value of the "charset" directive. This directive MUST appear at
628 most once and SHOULD contain one of the realms provided by the
629 server in the "digest-challenge". If the directive is missing,
630 "realm-value" will set to the empty string when computing A1 (see
631 below for details).
633 If the realm value was provided by the client and if the charset
634 directive is also specified in "digest-response" (which means that
635 the realm is encoded as UTF-8), the client SHOULD first prepare it
636 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
637 algorithm [RFC 3454]. If the preparation of the realm fails, the
638 client SHOULD abort the authentication exchange(*). If the
639 preparation succeeds, the prepared version is sent to the server
640 and used in hash computations described in section 2.1.2.1.
642 (*) An interactive client can request a repeated entry of the
643 realm value.
645 nonce
646 The server-specified data string received in the preceding digest-
647 challenge. This directive is required and MUST be present exactly
648 once; otherwise, authentication fails.
650 cnonce
651 A client-specified data string which MUST be different each time a
652 digest-response is sent as part of initial authentication. The
653 cnonce-value is an opaque quoted string value provided by the
654 client and used by both client and server to avoid chosen
658 Leach & Newman Expires: January 2006 [Page 11]
664 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
667 plaintext attacks, and to provide mutual authentication. The
668 security of the implementation depends on a good choice. It is
669 RECOMMENDED that it contain at least 64 bits of entropy. Note that
670 the whole string is enclosed in double-quote characters, however
671 quote-characters or escape characters are not allowed in the
672 string, even when quoted. This is different from the RFC 2821.
673 This directive is required and MUST be present exactly once;
674 otherwise, authentication fails.
676 nonce-count
677 The nc-value is the hexadecimal count of the number of requests
678 (including the current request) that the client has sent with the
679 nonce value in this request. For example, in the first request
680 sent in response to a given nonce value, the client sends
681 "nc=00000001". The purpose of this directive is to allow the
682 server to detect request replays by maintaining its own copy of
683 this count - if the same nc-value is seen twice, then the request
684 is a replay. See the description below of the construction of the
685 response value. This directive is required and MUST be present
686 exactly once; otherwise, or if the value is 0, authentication
687 fails.
689 qop
690 Indicates what "quality of protection" the client accepted. If
691 present, it may appear exactly once and its value MUST be one of
692 the alternatives in qop-options. If not present, it defaults to
693 "auth". These values affect the computation of the response. Note
694 that this is a single token, not a quoted list of alternatives.
696 serv-type
697 Indicates the type of service, such as "http" for web service,
698 "ftp" for FTP service, "smtp" for mail delivery service, etc. The
699 service name as defined in the SASL profile for the protocol see
700 section 4 of [RFC 2222], registered in the IANA registry of
701 "service" elements for the GSSAPI host-based service name form
702 [RFC 2078].
704 host
705 The DNS host name or IP (IPv4 or IPv6) address for the service
706 requested. The DNS host name must be the fully-qualified
707 canonical name of the host. The DNS host name is the preferred
708 form; see notes on server processing of the digest-uri.
710 serv-name
711 Indicates the name of the service if it is replicated. The service
712 is considered to be replicated if the client's service-location
713 process involves resolution using standard DNS lookup operations,
714 and if these operations involve DNS records (such as SRV [RFC
718 Leach & Newman Expires: January 2006 [Page 12]
724 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
727 2052], or MX) which resolve one DNS name into a set of other DNS
728 names. In this case, the initial name used by the client is the
729 "serv-name", and the final name is the "host" component. For
730 example, the incoming mail service for "example.com" may be
731 replicated through the use of MX records stored in the DNS, one of
732 which points at an SMTP server called "mail3.example.com"; it's
733 "serv-name" would be "example.com", it's "host" would be
734 "mail3.example.com". If the service is not replicated, or the
735 serv-name is identical to the host, then the serv-name component
736 MUST be omitted.
738 digest-uri
739 Indicates the principal name of the service with which the client
740 wishes to connect, formed from the serv-type, host, and serv-name.
741 For example, the FTP service on "ftp.example.com" would have a
742 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
743 the example above would have a "digest-uri" value of
744 "SMTP/mail3.example.com/example.com".
746 Servers SHOULD check that the supplied value is correct. This will
747 detect accidental connection to the incorrect server, as well as some
748 redirection attacks. It is also so that clients will be trained to
749 provide values that will work with implementations that use a shared
750 back-end authentication service that can provide server
751 authentication.
753 The serv-type component should match the service being offered. The
754 host component should match one of the host names of the host on
755 which the service is running, or it's IP address. Servers SHOULD NOT
756 normally support the IP address form, because server authentication
757 by IP address is not very useful; they should only do so if the DNS
758 is unavailable or unreliable. The serv-name component should match
759 one of the service's configured service names.
761 This directive is required and MUST be present exactly once; if
762 multiple instances are present, the server MUST abort the
763 authentication exchange.
765 Note: In the HTTP use of Digest authentication, the digest-uri is the
766 URI (usually a URL) of the resource requested -- hence the name of
767 the directive.
769 response
770 A string of 32 hex digits computed as defined below, which proves
771 that the user knows a password. This directive is required and
772 MUST be present exactly once; otherwise, authentication fails.
774 client_maxbuf
778 Leach & Newman Expires: January 2006 [Page 13]
784 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
787 A number indicating the size of the largest ciphertext buffer the
788 client is able to receive when using "auth-int" or "auth-conf". If
789 this directive is missing, the default value is 65536. This
790 directive may appear at most once; if multiple instances are
791 present, the server MUST abort the authentication exchange. If the
792 value is less or equal to 32 (if "aes-cbc" cipher was selected) or
793 16 (if one of the rc4 ciphers was selected), or bigger than
794 16777215 (i.e. 2**24-1), the server MUST abort the authentication
795 exchange.
797 Upon processing/sending of the client_maxbuf value both the server
798 and the client calculate their "maximal ciphertext buffer size" as
799 the minimum of the server_maxbuf (Step One) and the client_maxbuf
800 (Step Two). The "maximal sender size" can be calculated by
801 subtracting 32 (if "aes-cbc" cipher was selected) or 16 (for any
802 of the rc4 ciphers) from the calculated "maximal ciphertext buffer
803 size".
805 When sending a block of data the client/server MUST NOT pass more
806 than the "maximal sender size" bytes of data to the selected
807 protection function (2.3 or 2.4).
809 charset
810 This directive, if present, specifies that the client has used
811 UTF-8 [UTF-8] encoding for the username, realm and password. If
812 present, the username, realm and password are encoded as UTF-8
813 [UTF-8]. If not present, the username, realm and password MUST be
814 encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a
815 subset). The client should send this directive only if the server
816 has indicated that it supports UTF-8 [UTF-8]. The directive is
817 needed for backwards compatibility with HTTP Digest, which only
818 supports ISO 8859-1.
820 Note, that this directive doesn't affect the authorization
821 identity ("authzid").
823 LHEX
824 32 hex digits, where the alphabetic characters MUST be lower case,
825 because MD5 is not case insensitive.
827 cipher
828 The cipher chosen by the client. This directive MUST appear
829 exactly once if "auth-conf" is negotiated; if required and not
830 present, authentication fails. If the cipher chosen by the client
831 is not one of the ciphers advertised by the server, authentication
832 fails.
834 authzid
838 Leach & Newman Expires: January 2006 [Page 14]
844 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
847 The "authorization ID" (authzid) directive may appear at most
848 once; if multiple instances are present, the server MUST abort the
849 authentication exchange. If present, and the authenticating user
850 has sufficient privilege, and the server supports it, then after
851 authentication the server will use this identity for making all
852 accesses and access checks. If the client specifies it, and the
853 server does not support it, then the response-value calculated on
854 the server will not match the one calculated on the client and
855 authentication will fail.
857 The authzid MUST NOT be an empty string.
859 The authorization identifier MUST NOT be converted to ISO 8859-1
860 even if the authentication identifier ("username") is converted
861 for compatibility as directed by "charset" directive.
863 The server SHOULD verify the correctness of an authzid as
864 specified by the corresponding SASL protocol profile.
866 The size of a digest-response MUST be less than 4096 bytes.
868 2.1.2.1 Response-value
870 The definition of "response-value" above indicates the encoding for
871 its value -- 32 lower case hex characters. The following definitions
872 show how the value is computed.
874 Although qop-value and components of digest-uri-value may be
875 case-insensitive, the case which the client supplies in step two is
876 preserved for the purpose of computing and verifying the
877 response-value.
879 response-value =
880 HEX( KD ( HEX(H(A1)),
881 { unq(nonce-value), ":" nc-value, ":",
882 unq(cnonce-value), ":", qop-value, ":", HEX(H(A2)) }))
884 If authzid is specified, then A1 is
886 A1 = { SS, ":", unq(nonce-value), ":",
887 unq(cnonce-value), ":", unq(authzid-value) }
889 If authzid is not specified, then A1 is
891 A1 = { SS, ":", unq(nonce-value), ":", unq(cnonce-value) }
893 where
898 Leach & Newman Expires: January 2006 [Page 15]
904 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
907 password = *OCTET
909 SS = H( { unq(username-value), ":", unq(realm-value), ":", password } )
913 The "username-value", "realm-value" and "password" are encoded
914 according to the value of the "charset" directive. If "charset=UTF-8"
915 is present, and all the characters of "username-value" are in the ISO
916 8859-1 character set, then it MUST be converted to ISO 8859-1 before
917 being hashed. The same transformation has to be done for "realm-
918 value" and "password". This is so that authentication databases that
919 store the hashed username, realm and password (which is common) can
920 be shared compatibly with HTTP, which specifies ISO 8859-1. A sample
921 implementation of this conversion is in section 8.
923 Note that on the client side the "username-value", "realm-value"(*)
924 and "password" MUST be prepared before being encoded as described in
925 the previous paragraph. The [SASLPrep] profile of the [StringPrep]
926 algorithm is the RECOMMENDED preparation algorithm. The SASLprep
927 preparation algorithm is recommended to improve the likelihood that
928 comparisons behave in an expected manner. The SASLprep preparation
929 algorithm is not mandatory. This is done to allow, when appropriate,
930 the server to employ other preparation algorithms (including none).
931 For instance, use of different preparation algorithm may be necessary
932 for the server to interoperate with an external system.
934 (*) - Note that if the "realm-value" was provided by the client (i.e.
935 not chosen from the list of realms returned by the server), it MUST
936 NOT be prepared.
938 On the server side the preparation of the "username-value", "realm-
939 value" and "password" MUST NOT be performed.
941 If the "qop" directive's value is "auth", then A2 is:
943 A2 = { "AUTHENTICATE:", digest-uri-value }
958 Leach & Newman Expires: January 2006 [Page 16]
964 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 auth-info = 1#( response-auth | auth-param )
999 response-auth = "rspauth" "=" response-value
1001 where response-value is calculated as above, using the values sent in
1002 step two, except that if qop is "auth", then A2 is
1004 A2 = { ":", digest-uri-value }
1006 And if qop is "auth-int" or "auth-conf" then A2 is
1008 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
1010 Note that only one occurance of the "response-auth" is allowed. If
1011 more than one is found, the client MUST treat this as an
1012 authentication error.
1014 Compared to its use in HTTP, the following Digest directives in the
1018 Leach & Newman Expires: January 2006 [Page 17]
1024 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1027 "auth-info" are unused:
1029 nextnonce
1030 qop
1031 cnonce
1032 nonce-count
1034 The size of an auth-info MUST be less than 2048 bytes.
1036 2.2 Subsequent Authentication
1038 If the client has previously authenticated to the server, and
1039 remembers the values of username, realm, nonce, nonce-count, cnonce,
1040 and qop that it used in that authentication, and the SASL profile for
1041 a protocol permits an initial client response, then it MAY perform
1042 "subsequent authentication" or "fast reauthentication", as defined in
1043 this section. Note, that a subsequent authentication can be done on
1044 a different connection, or on the same connection, if the protocol
1045 profile also permits multiple authentications.
1047 2.2.1 Step one
1049 The client uses the values from the previous authentication and sends
1050 an initial response with a string formatted and computed according to
1051 the rules for a "digest-response", as defined above, but with a
1052 nonce-count one greater than used in the last "digest-response".
1054 2.2.2 Step Two
1056 The server receives the "digest-response". If the server does not
1057 support subsequent authentication, then it sends a
1058 "digest-challenge", and authentication proceeds as in initial
1059 authentication. If the server has no saved nonce and nonce-count from
1060 a previous authentication, then it sends a "digest-challenge", and
1061 authentication proceeds as in initial authentication. Otherwise, the
1062 server validates the "digest-response", checks that the nonce-count
1063 is one greater than that used in the previous authentication using
1064 that nonce, and saves the new value of nonce-count.
1066 If the response is invalid, then the server sends a
1067 "digest-challenge", and authentication proceeds as in initial
1068 authentication (and should be configurable to log an authentication
1069 failure in some sort of security audit log, since the failure may be
1070 a symptom of an attack). The nonce-count MUST NOT be incremented in
1071 this case: to do so would allow a denial of service attack by sending
1072 an out-of-order nonce-count.
1074 If the response is valid, the server MAY choose to deem that
1078 Leach & Newman Expires: January 2006 [Page 18]
1084 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1087 authentication has succeeded. However, if it has been too long since
1088 the previous authentication, or for any other reason, the server MAY
1089 send a new "digest-challenge" with a new value for nonce. The
1090 challenge MAY contain a "stale" directive with value "true", which
1091 says that the client may respond to the challenge using the password
1092 it used in the previous response; otherwise, the client must solicit
1093 the password anew from the user. This permits the server to make sure
1094 that the user has presented their password recently. (The directive
1095 name refers to the previous nonce being stale, not to the last use of
1096 the password.) Except for the handling of "stale", after sending the
1097 "digest-challenge" authentication proceeds as in the case of initial
1098 authentication.
1100 2.3 Integrity Protection
1102 If the server offered "qop=auth-int" and the client responded
1103 "qop=auth-int", then subsequent messages, up to but not including the
1104 next subsequent authentication, between the client and the server
1105 MUST be integrity protected. Using as a base session key the value of
1106 H(A1), as defined above the client and server calculate a pair of
1107 message integrity keys as follows.
1109 The key for integrity protecting messages from client to server is:
1111 Kic = MD5({H(A1),
1112 "Digest session key to client-to-server signing key magic constant"})
1114 The key for integrity protecting messages from server to client is:
1116 Kis = MD5({H(A1),
1117 "Digest session key to server-to-client signing key magic constant"})
1119 where MD5 is as specified in [RFC 1321]. If message integrity is
1120 negotiated, a MAC block for each message is appended to the message.
1121 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
1122 2104] of the message, a 2-byte message type number in network byte
1123 order with value 1, and the 4-byte sequence number in network byte
1124 order. The message type is to allow for future extensions such as
1125 rekeying.
1127 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
1128 SeqNum)
1130 where Ki is Kic for messages sent by the client and Kis for those
1131 sent by the server. The sequence number (SeqNum) is an unsigned
1132 number initialized to zero after initial or subsequent
1133 authentication, and incremented by one for each message
1134 sent/successfully verified. (Note, that there are two independent
1138 Leach & Newman Expires: January 2006 [Page 19]
1144 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1147 counters for sending and receiving.) The sequence number wraps around
1148 to 0 after 2**32-1.
1150 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
1151 received value; the message is discarded if they differ and as the
1152 result the connection being used MUST be dropped. The receiver's
1153 sequence counter is incremented if they match.
1155 2.4 Confidentiality Protection
1157 If the server sent a "cipher-opts" directive and the client responded
1158 with a "cipher" directive, then subsequent messages between the
1159 client and the server MUST be confidentiality protected. Using as a
1160 base session key the value of H(A1) as defined above the client and
1161 server calculate a pair of message integrity keys as follows.
1163 The key for confidentiality protecting messages from client to server
1164 is:
1166 Kcc = MD5({H(A1)[0..n-1],
1167 "Digest H(A1) to client-to-server sealing key magic constant"})
1169 The key for confidentiality protecting messages from server to client
1170 is:
1172 Kcs = MD5({H(A1)[0..n-1],
1173 "Digest H(A1) to server-to-client sealing key magic constant"})
1175 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
1176 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*"
1177 and "aes-cbc" ciphers is all 16 bytes of Kcc or Kcs.
1179 "aes-cbc" cipher works as described in section 2.4.1.
1181 rc4 cipher state MUST NOT be reset before sending/receiving a next
1182 buffer of protected data.
1185 If the blocksize of the chosen cipher is not 1 byte, the padding
1186 prefix is one or more octets each containing the number of padding
1187 bytes, such that the total length of the encrypted part of the
1188 message is a multiple of the blocksize.
1190 The MAC block is 16 bytes formatted as follows: the first 10 bytes of
1191 the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number
1192 in network byte order with value 1, and the 4-byte sequence number in
1193 network byte order.
1198 Leach & Newman Expires: January 2006 [Page 20]
1204 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1207 <<Proposal 1 ("explicit IV in each SASL block") is detailed below>>
1209 The padding and first 10 bytes of the MAC block are encrypted with
1210 the chosen cipher along with the message and explicit IV (if
1211 present).
1213 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {exp_iv, msg, pad, MAC})
1215 MAC(Ki, SeqNum, exp_iv, msg) = {HMAC(Ki, {SeqNum, exp_iv, msg})[0..9],
1216 packet_type_data, SeqNum}
1218 packet_type_data = 0x0001
1220 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
1221 messages sent by the client and Kis and Kcs for those sent by the
1222 server, exp_iv is empty string for rc4 ciphers and a randomly
1223 generated number R of the length 128 bit for the "aes-cbc" cipher.
1224 The sequence number (SeqNum) is an unsigned number initialized to
1225 zero after initial or subsequent authentication, and incremented by
1226 one for each message sent/successfully verified. (Note, that there
1227 are two independent counters for sending and receiving.) The sequence
1228 number wraps around to 0 after 2**32-1.
1230 Upon receipt, the message is decrypted, exp_iv is ignored (for the
1231 "aes-cbc" cipher only), HMAC(Ki, {SeqNum, msg}) is computed and
1232 compared with the received value; the padding and the packet type are
1233 verified. The message is discarded if the received and the
1234 calculated HMACs differ and/or the padding is invalid. See also
1235 section 3.8 for important information about MAC and padding
1236 verification. The receiver's sequence counter is then compared with
1237 the received SeqNum value; the message is discarded if they differ
1238 and, as the result, the connection being used MUST be dropped. The
1239 receiver's sequence counter is incremented if they match.
1242 <<Proposal 2 ("explicit IV in a separate SASL block") is detailed
1243 below:
1245 Instead of sending a single SASL block that contains encrypted
1246 (128bit of entropy, followed by cleartext), we can introduce a new
1247 block type, that will only contain the entropy. Clients that have
1248 limited CPU resources (or operate on a slow link) might choose to
1249 send these special blocks not for every block of encrypted data, but
1250 for every second (third, ...) block.
1252 So, instead of sending a single block SEAL(Ki, Kc, SeqNum, msg)
1253 described aboves there are two types of blocks:
1258 Leach & Newman Expires: January 2006 [Page 21]
1264 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1267 the first is a data block as in revision 02:
1268 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {msg, pad2, MAC})
1269 MAC(Ki, SeqNum, msg) = {HMAC(Ki, {SeqNum, msg})[0..9], packet_type_data, SeqNum}
1270 packet_type_data = 0x0001
1272 the second block type has a different type and contains encrypted IV:
1274 SEAL_IV(Ki, Kc, SeqNum) = CIPHER(Kc, {exp_iv, pad1, MAC_IV})
1275 MAC_IV(Ki, SeqNum, exp_iv) = {HMAC(Ki, {SeqNum, exp_iv})[0..9], packet_type_iv,
1276 SeqNum}
1277 packet_type_iv = 0x0002
1279 The second block is also protected by MAC that includes SeqNum. So,
1280 removing/replacing it will invalidate subsequent blocks.
1282 Advantages of this approach: 1) Less intrusive changes to already
1283 deployed code. Adding new block type might be easier. Also, the
1284 minimal block size is always 16 (with the proposal #1 it is either 16
1285 or 32). 2) Clients that want to sacrifice a bit of security in order
1286 to achieve faster performance can choose to send SEAL_IV blocks less
1287 frequently.
1289 Of course I am not a cryptographer, to judge if there are any issues
1290 with the alternative proposal.>>
1293 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 1]
1295 Unlike previous versions of DIGEST-MD5, this document uses an
1296 explicit IV for ciphers in CBC mode. This is done in order to prevent
1297 the attacks described by [CBCATT].
1299 For each buffer of cleartext data to be encrypted the sender performs
1300 the following procedure:
1302 0) For the very first SASL packet sent the IV is calculated as
1303 follows:
1305 The IV for the first SASL packet going from the client
1306 to the server (IVc) consists of 16 bytes calculated as follows:
1308 IVc = MD5({Kcc, "aes-128"})
1310 The IV for the first SASL packet going from the server
1311 to the client (IVs) consists of 16 bytes calculated as follows:
1313 IVs = MD5({Kcs, "aes-128"})
1318 Leach & Newman Expires: January 2006 [Page 22]
1324 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1327 For a subsequent packet: Em of the previous packet (see below)
1328 becomes the IV.
1330 1) Generate a cryptographically strong random number R of length 128
1331 bits (16 octets) and prepend it to the plaintext prior to
1332 encryption.
1334 2) padding and MAC block are constructed (see section 2.4) and
1335 appended to the end of the plaintext. After this step the data
1336 to be encrypted will look like:
1338 {R, msg, pad, MAC}
1340 As the total length of the data will be multiple of AES block size
1341 (i.e. 128 bit), this can also be represented as
1343 {P1, P2, P3, ..., Pm}
1345 where Pi is a chunk of data of the length 128 bit. Note, that
1346 P1 is R.
1348 3) Data is encrypted as follows:
1350 E1 = CIPHER ( Kc, P1 XOR IV )
1351 E2 = CIPHER ( Kc, P2 XOR E1 )
1352 E3 = CIPHER ( Kc, P3 XOR E2 )
1353 ...
1354 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1355 ...
1356 Em = CIPHER ( Kc, Pm XOR Em-1)
1358 This will generate ciphertext {E1, ..., Em} to be sent as a single
1359 SASL packet.
1362 The receiver performs the following steps:
1364 0) For the very first SASL packet sent the IV is calculated as
1365 in step 0 for the sender.
1367 For a subsequent packet: Em of the previous packet becomes
1368 the IV of the immediately following packet.
1370 1) Data is decrypted as follows:
1372 P1 = CIPHER ( Kc, E1 ) XOR IV
1373 P2 = CIPHER ( Kc, E2 ) XOR E1
1374 P3 = CIPHER ( Kc, E3 ) XOR E2
1378 Leach & Newman Expires: January 2006 [Page 23]
1384 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1387 ...
1388 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1389 ...
1390 Pm = CIPHER ( Kc, Em ) XOR Em-1
1392 Em becomes the IV for the decryption of the subsequent SASL
1393 packet.
1395 This will generate plaintext {P1, ..., Pm}. P1 is discarded,
1396 {P2, ..., Pm} is {msg, pad, MAC}.
1398 2) pad and MAC block are verified as described in section 2.4.
1400 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 2]
1402 Unlike previous versions of DIGEST-MD5, this document uses an
1403 explicit IV for ciphers in CBC mode. This is done in order to prevent
1404 the attacks described by [CBCATT].
1406 For each buffer of cleartext data to be encrypted the sender performs
1407 the following procedure:
1409 0) For the very first SASL packet sent the IV is calculated as
1410 follows:
1412 The IV for the first SASL packet going from the client
1413 to the server (IVc) consists of 16 bytes calculated as follows:
1415 IVc = MD5({Kcc, "aes-128"})
1417 The IV for the first SASL packet going from the server
1418 to the client (IVs) consists of 16 bytes calculated as follows:
1420 IVs = MD5({Kcs, "aes-128"})
1422 For a subsequent packet: Em of the previous packet (see below)
1423 becomes the IV.
1425 1) padding and MAC block are constructed (see section 2.4) and
1426 appended to the end of the plaintext. After this step the data
1427 to be encrypted will look like:
1429 {msg, pad, MAC}
1431 As the total length of the data will be multiple of AES block size
1432 (i.e. 128 bit), this can also be represented as
1434 {P1, P2, P3, ..., Pm}
1438 Leach & Newman Expires: January 2006 [Page 24]
1444 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1447 where Pi is a chunk of data of the length 128 bit.
1449 2) Data is encrypted as follows:
1451 E1 = CIPHER ( Kc, P1 XOR IV )
1452 E2 = CIPHER ( Kc, P2 XOR E1 )
1453 E3 = CIPHER ( Kc, P3 XOR E2 )
1454 ...
1455 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1456 ...
1457 Em = CIPHER ( Kc, Pm XOR Em-1)
1459 This will generate ciphertext {E1, ..., Em} to be sent as a single
1460 SASL packet.
1463 In order to mitigate the attacks described in [CBCATT] the sender
1464 should periodically send a new SASL packet that affects IV. This
1465 packet is constructed as follows:
1467 1) Generate a cryptographically strong random number R of length 128
1468 bits (16 octets) and prepend it to the plaintext prior to
1469 encryption.
1471 2) padding and MAC block are constructed (see section 2.4) and
1472 appended after R. After this step the data
1473 to be encrypted will look like:
1475 {R, pad, MAC_IV}
1477 As the total length of the data will be multiple of AES block size
1478 (i.e. 128 bit), this can also be represented as
1480 {P1, P2, P3, ..., Pm}
1482 where Pi is a chunk of data of the length 128 bit.
1484 3) Data is encrypted as follows (this is exactly the same procedure
1485 as for
1486 a data packets described above):
1488 E1 = CIPHER ( Kc, P1 XOR IV )
1489 E2 = CIPHER ( Kc, P2 XOR E1 )
1490 E3 = CIPHER ( Kc, P3 XOR E2 )
1491 ...
1492 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1493 ...
1494 Em = CIPHER ( Kc, Pm XOR Em-1)
1498 Leach & Newman Expires: January 2006 [Page 25]
1504 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1507 This will generate ciphertext {E1, ..., Em} to be sent as a single
1508 SASL packet.
1510 The receiver performs the following steps:
1512 0) For the very first SASL packet sent the IV is calculated as
1513 in step 0 for the sender.
1515 For a subsequent packet: Em of the previous packet becomes
1516 the IV of the immediately following packet.
1518 1) Data is decrypted as follows:
1520 P1 = CIPHER ( Kc, E1 ) XOR IV
1521 P2 = CIPHER ( Kc, E2 ) XOR E1
1522 P3 = CIPHER ( Kc, E3 ) XOR E2
1523 ...
1524 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1525 ...
1526 Pm = CIPHER ( Kc, Em ) XOR Em-1
1528 Em becomes the IV for the decryption of the subsequent SASL
1529 packet.
1531 This will generate plaintext {P1, ..., Pm} or {msgX, pad, MACX}.
1533 Packet type is extracted from MACX. If the packet type is 0x0001,
1534 the plaintext represents a data block with padding and MAC.
1535 If the packet type is 0x0002, the packet contains a random value
1536 R which affects IV followed by padding and MAC_IV. The random
1537 value
1538 R is ignored by the receiver.
1540 2) For both pad and MAC block are verified as described in section
1541 2.4.
1558 Leach & Newman Expires: January 2006 [Page 26]
1564 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 deployability 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: January 2006 [Page 27]
1624 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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: January 2006 [Page 28]
1684 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 protected data, the attacker may be able to launch
1699 Vaudenay's [VAUDENAY] 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, ":", password }), which is adequate to compute
1732 H(A1) as described above without directly exposing the user's
1733 password.
1738 Leach & Newman Expires: January 2006 [Page 29]
1744 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1747 The security implications of this are that if this password file is
1748 compromised, then an attacker gains immediate access to documents on
1749 the server using this realm. Unlike, say a standard UNIX password
1750 file, this information need not be decrypted in order to access
1751 documents in the server realm associated with this file. On the other
1752 hand, decryption, or more likely a brute force attack, would be
1753 necessary to obtain the user's password. This is the reason that the
1754 realm is part of the digested data stored in the password file. It
1755 means that if one Digest authentication password file is compromised,
1756 it does not automatically compromise others with the same username
1757 and password (though it does expose them to brute force attack).
1759 There are two important security consequences of this. First the
1760 password file must be protected as if it contained plaintext
1761 passwords, because for the purpose of accessing documents in its
1762 realm, it effectively does.
1764 A second consequence of this is that the realm string should be
1765 unique among all realms that any single user is likely to use. In
1766 particular a realm string should include the name of the host doing
1767 the authentication.
1798 Leach & Newman Expires: January 2006 [Page 30]
1804 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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: January 2006 [Page 31]
1864 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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: January 2006 [Page 32]
1924 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1947 April 1992.
1949 [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1950 location of services (DNS SRV)", RFC 2052, October 1996.
1952 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1953 Hashing for Message Authentication", RFC 2104, February
1954 1997.
1956 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1957 Requirement Levels", BCP 14, RFC 2119, March 1997.
1959 [RFC 2222] Melnikov, A. (editor), "Simple Authentication and Security
1960 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work
1961 in progress.
1963 [RFC 3454] Hoffman, P., Blanchet, M., "Preparation of
1964 Internationalized Strings ("stringprep")", RFC 3454,
1965 December 2002.
1967 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1968 3.2.0", defined by: The Unicode Standard, Version 3.0
1969 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
1970 as amended by the Unicode Standard Annex #28: Unicode 3.2
1971 (http://www.unicode.org/reports/tr28/tr28-3.html).
1973 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646",
1974 RFC 2279, Janyary 1998.
1978 Leach & Newman Expires: January 2006 [Page 33]
1984 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
1987 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
1988 Code for Information Interchange. Standard ANSI X3.4-1986,
1989 ANSI, 1986.
1991 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1992 and passwords", RFC 4013, February 2005.
1994 [RFC 3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1995 Resource Identifier (URI): Generic Syntax", RFC 3986,
1996 January 2005.
1998 [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",
1999 http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf,
2000 3rd September 1999.
2003 5.2 Informative references
2005 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
2006 AUTHorize Extension for Simple Challenge/Response", RFC
2007 2195, September 1997.
2009 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with
2010 MD5", CryptoBytes, Sping 1995, RSA Inc,
2011 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
2013 [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
2014 Text Messages," STD 11, RFC 822, August 1982. <<drop?>>
2016 [RFC 2078] Linn, J., "Generic Security Service Application Program
2017 Interface, Version 2", RFC 2078, January 1997.
2019 [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version
2020 4rev1", RFC 3501, March 2003.
2022 [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
2023 Access Protocol", RFC 2244, November 1997.
2025 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2026 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext
2027 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2029 [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
2030 Problems and Countermeasures",
2031 http://www.openssl.org/~bodo/tls-cbc.txt.
2033 [CBCATT] Canvel, B., "Password Interception in a SSL/TLS Channel",
2034 published 2003-02-20:
2038 Leach & Newman Expires: January 2006 [Page 34]
2044 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2047 http://lasecwww.epfl.ch/memo_ssl.shtml
2049 [VAUDENAY] Serge Vaudenay, "Security Flaws Induced by CBC Padding -
2050 Applications to SSL, IPSEC, WTLS ...". L.R. Knudsen (Ed.):
2051 EUROCRYPT 2002, LNCS 2332, pp. 534-545, 2002.
2053 [RFC 3548] Josefsson, S., "The Base16, Base32, and Base64 Data
2054 Encodings", RFC 3548, July 2003.
2056 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
2057 MECHANISMS", <http://www.iana.org/assignments/sasl-
2058 mechanisms>.
2098 Leach & Newman Expires: January 2006 [Page 35]
2104 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2107 6 IANA Considerations
2109 It is requested that the SASL Mechanism registry [IANA-SASL] entry for
2110 the DIGEST-MD5 mechanism be updated to reflect that this document now
2111 provides its technical specification.
2113 To: iana@iana.org
2114 Subject: Updated Registration of SASL mechanism DIGEST-MD5
2116 Family of SASL mechanisms: NO
2117 SASL mechanism name: DIGEST-MD5
2118 Security considerations: See RFC XXXX.
2119 Published specification (optional, recommended): RFC XXXX
2120 Person & email address to contact for further information:
2121 Alexey Melnikov <alexey.melnikov@isode.com>
2122 IETF SASL WG <ietf-sasl@imc.org>
2123 Intended usage: COMMON
2124 Author/Change controller: IESG <iesg@ietf.org>
2125 Note: Updates existing entry for DIGEST-MD5
2158 Leach & Newman Expires: January 2006 [Page 36]
2164 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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.
2178 7.1 Augmented BNF
2180 All of the mechanisms specified in this document are described in
2181 both prose and an augmented Backus-Naur Form (BNF) similar to that
2182 used by RFC 822 [RFC 822]. Implementers will need to be familiar with
2183 the notation in order to understand this specification.
2185 The augmented BNF includes the following constructs: <<Can this be
2186 dropped in favor of ABNF?>>
2188 name = definition
2189 The name of a rule is simply the name itself (without any
2190 enclosing "<" and ">") and is separated from its definition by the
2191 equal "=" character. White space is only significant in that
2192 indentation of continuation lines is used to indicate a rule
2193 definition that spans more than one line. Certain basic rules are
2194 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
2195 brackets are used within definitions whenever their presence will
2196 facilitate discerning the use of rule names.
2198 "literal"
2199 Quotation marks surround literal text. Unless stated otherwise,
2200 the text is case-insensitive.
2202 rule1 | rule2
2203 Elements separated by a bar ("|") are alternatives, e.g., "yes |
2204 no" will accept yes or no.
2206 (rule1 rule2)
2207 Elements enclosed in parentheses are treated as a single element.
2208 Thus, "(elem (foo | bar) elem)" allows the token sequences
2209 "elem foo elem" and "elem bar elem".
2211 *rule
2212 The character "*" preceding an element indicates repetition. The
2213 full form is "<n>*<m>element" indicating at least <n> and at most
2214 <m> occurrences of element. Default values are 0 and infinity so
2218 Leach & Newman Expires: January 2006 [Page 37]
2224 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2227 that "*(element)" allows any number, including zero; "1*element"
2228 requires at least one; and "1*2element" allows one or two.
2230 [rule]
2231 Square brackets enclose optional elements; "[foo bar]" is
2232 equivalent to "*1(foo bar)".
2234 N rule
2235 Specific repetition: "<n>(element)" is equivalent to
2236 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
2237 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
2238 alphabetic characters.
2240 #rule
2241 A construct "#" is defined, similar to "*", for defining lists of
2242 elements. The full form is "<n>#<m>element" indicating at least
2243 <n> and at most <m> elements, each separated by one or more commas
2244 (",") and OPTIONAL linear white space (LWS). This makes the usual
2245 form of lists very easy; a rule such as
2246 ( *LWS element *( *LWS "," *LWS element ) *LWS )
2247 can be shown as
2248 1#element
2249 Wherever this construct is used, null elements are allowed, but do
2250 not contribute to the count of elements present. That is,
2251 "(element), , (element) " is permitted, but counts as only two
2252 elements. Therefore, where at least one element is required, at
2253 least one non-null element MUST be present. Default values are 0
2254 and infinity so that "#element" allows any number, including zero;
2255 "1#element" requires at least one; and "1#2element" allows one or
2256 two.
2258 ; comment
2259 A semi-colon, set off some distance to the right of rule text,
2260 starts a comment that continues to the end of line. This is a
2261 simple way of including useful notes in parallel with the
2262 specifications.
2264 implied *LWS
2265 The grammar described by this specification is word-based. Except
2266 where noted otherwise, linear white space (LWS) can be included
2267 between any two adjacent words (token or quoted-string), and
2268 between adjacent words and separators, without changing the
2269 interpretation of a field. At least one delimiter (LWS and/or
2270 separators) MUST exist between any two tokens (for the definition
2271 of "token" below), since they would otherwise be interpreted as a
2272 single token.
2274 7.2 Basic Rules
2278 Leach & Newman Expires: January 2006 [Page 38]
2284 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2287 The following rules are used throughout this specification to
2288 describe basic parsing constructs. The US-ASCII coded character set
2289 is defined by ANSI X3.4-1986 [USASCII].
2291 OCTET = <any 8-bit character>
2292 CHAR = <any US-ASCII character (octets 0 - 127)>
2293 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
2294 LOALPHA = <any US-ASCII lowercase letter "a".."z">
2295 ALPHA = UPALPHA | LOALPHA
2296 DIGIT = <any US-ASCII digit "0".."9">
2297 CTL = <any US-ASCII control character
2298 (octets 0 - 31) and DEL (127)>
2299 CR = <US-ASCII CR, carriage return (13)>
2300 LF = <US-ASCII LF, linefeed (10)>
2301 SP = <US-ASCII SP, space (32)>
2302 HT = <US-ASCII HT, horizontal-tab (9)>
2303 <"> = <US-ASCII double-quote mark (34)>
2304 TEXTCHAR = <any OCTET except CTLs, but including HT>
2305 CRLF = CR LF
2307 All linear white space, including folding, has the same semantics as
2308 SP. A recipient MAY replace any linear white space with a single SP
2309 before interpreting the field value or forwarding the message
2310 downstream.
2312 LWS = [CRLF] 1*( SP | HT )
2314 The TEXT rule is only used for descriptive field contents and values
2315 that are not intended to be interpreted by the message parser. Words
2316 of TEXT contains characters either from ISO-8859-1 [ISO-8859]
2317 character set or UTF-8 [UTF-8].
2319 TEXT = <any *OCTET except CTLs,
2320 but including LWS>
2322 A CRLF is allowed in the definition of TEXT only as part of a header
2323 field continuation. It is expected that the folding LWS will be
2324 replaced with a single SP before interpretation of the TEXT value.
2326 Hexadecimal numeric characters are used in several protocol elements.
2328 HEX = "A" | "B" | "C" | "D" | "E" | "F"
2329 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
2331 Many HTTP/1.1 header field values consist of words separated by LWS
2332 or special characters. These special characters MUST be in a quoted
2333 string to be used within a parameter value.
2338 Leach & Newman Expires: January 2006 [Page 39]
2344 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2347 token = 1*TOKENCHAR
2348 separators = "(" | ")" | "<" | ">" | "@"
2349 | "," | ";" | ":" | "\" | <">
2350 | "/" | "[" | "]" | "?" | "="
2351 | "{" | "}" | SP | HT
2352 TOKENCHAR = <any CHAR except CTLs or separators>
2354 A string of text is parsed as a single word if it is quoted using
2355 double-quote marks.
2357 quoted-string = ( <"> qdstr-val <"> )
2358 qdstr-val = *( qdtext | quoted-pair )
2359 qdtext = <any TEXTCHAR except <"> and "\">
2361 Note that LWS is NOT implicit between the double-quote marks (<">)
2362 surrounding a qdstr-val and the qdstr-val; any LWS will be considered
2363 part of the qdstr-val. This is also the case for quotation marks
2364 surrounding any other construct.
2366 The backslash character ("\") MAY be used as a single-character
2367 quoting mechanism only within qdstr-val and comment constructs.
2369 quoted-pair = "\" CHAR
2371 The value of this construct is CHAR. Note that an effect of this rule
2372 is that backslash itself MUST be quoted.
2398 Leach & Newman Expires: January 2006 [Page 40]
2404 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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: January 2006 [Page 41]
2464 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2467 9 Authors' Addresses
2469 Paul Leach
2470 Microsoft
2471 1 Microsoft Way
2472 Redmond, WA 98052, USA
2474 EMail: paulle@microsoft.com
2477 Chris Newman
2478 Sun Microsystems
2479 1050 Lakes Drive
2480 West Covina, CA 91790, USA
2482 EMail: Chris.Newman@Sun.COM
2485 Alexey Melnikov
2486 Isode Ltd.
2487 5 Castle Business Village,
2488 36 Station Road,
2489 Hampton,
2490 Middlesex,
2491 TW12 2BX,
2492 United Kingdom
2494 Email: Alexey.Melnikov@isode.com
2497 10 Acknowledgements
2499 The following people had substantial contributions to the development
2500 and/or refinement of this document:
2502 Lawrence Greenfield John Gardiner Myers Simon Josefsson RL Bob Morgan
2503 Jeff Hodges Claus Assmann Tony Hansen Ken Murchison Sam Hartman Kurt
2504 D. Zeilenga Hallvard B. Furuseth Abhijit Menon-Sen Tom Yu
2506 as well as other members of the SASL mailing list.
2508 The text used is section 3.8 was taken from [TLS-CBC] by Bodo
2509 Moeller.
2518 Leach & Newman Expires: January 2006 [Page 42]
2524 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2527 11 Full Copyright Statement
2529 Copyright (C) The Internet Society (2005).
2531 This document is subject to the rights, licenses and restrictions
2532 contained in BCP 78, and except as set forth therein, the authors
2533 retain all their rights.
2535 This document and the information contained herein are provided on an
2536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2538 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2539 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2540 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2543 Acknowledgement
2545 Funding for the RFC Editor function is currently provided by the
2546 Internet Society.
2548 12 Intellectual Property
2550 The IETF takes no position regarding the validity or scope of any
2551 Intellectual Property Rights or other rights that might be claimed to
2552 pertain to the implementation or use of the technology described in
2553 this document or the extent to which any license under such rights
2554 might or might not be available; nor does it represent that it has
2555 made any independent effort to identify any such rights. Information
2556 on the procedures with respect to rights in RFC documents can be
2557 found in BCP 78 and BCP 79.
2559 Copies of IPR disclosures made to the IETF Secretariat and any
2560 assurances of licenses to be made available, or the result of an
2561 attempt made to obtain a general license or permission for the use of
2562 such proprietary rights by implementers or users of this
2563 specification can be obtained from the IETF on-line IPR repository at
2564 http://www.ietf.org/ipr.
2566 The IETF invites any interested party to bring to its attention any
2567 copyrights, patents or patent applications, or other proprietary
2568 rights that may cover technology that may be required to implement
2569 this standard. Please address the information to the IETF at ietf-
2570 ipr@ietf.org.
2578 Leach & Newman Expires: January 2006 [Page 43]
2584 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
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). Removed "des" and "3des" ciphers because of known
2593 interoperability problems and vulnerability to CBC mode attack.
2595 3). Tighten ABNF. Fixed some bugs.
2597 4). Clarified nc-value verification and which side is aborting
2598 exchange.
2600 5). Added text saying that for interoperability
2601 username/password/realm SHOULD be prepared using the "SASLPrep"
2602 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454].
2604 6). Clarified that unquoted version of the username, etc. used in A1
2605 calculation.
2607 7). Various cleanup to References section. Split all references to
2608 Normative and Informative.
2610 8). Added minimal and maximal limits on maxbuf. Clarified how to
2611 calculate "maximal sender size".
2613 9). Change ABNF for host to allow for IPv6 addresses. ABNF now
2614 references RFC 3986.
2616 10). Added man-in-the-middle considerations for ciphers.
2618 11). Clarified how sequence counters are updated.
2620 12). Addition warnings about preventing reply/redirection attacks.
2622 13). Specified that "charset" directive affects "realm" and doesn't
2623 affect "authzid".
2625 14). Removed text that described that "authzid" is in Unicode in
2626 Normalization Form KC, encoded as UTF-8.
2628 15). Clarified that rc4 state is not reset between two consecutive
2629 sent/received buffers of protected data.
2631 16). Allow for extensibility in step 3. Use "auth-info" as in RFC
2632 2617.
2634 17). Prohibit an empty authzid, as this caused interoperability
2638 Leach & Newman Expires: January 2006 [Page 44]
2644 INTERNET DRAFT DIGEST-MD5 SASL Mechanism July 2005
2647 problems.
2649 18). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL
2650 mechanism" document (expired draft-ietf-sasl-digest-aes-00.txt).
2651 Use explicit IV with aes cipher in CBC mode.
2653 18). Cleaned up Confidentiality protection section. Added step by
2654 step exlanation how CBC mode is used.
2656 19). Clarified client behavior, if it recognizes no ciphers.
2658 20). Clarified that the server is not required to advertise all
2659 realms it supports.
2661 21). Clarified how UIs should present realms.
2663 22). Changed some informative text to normative MUST/SHOULDs.
2666 And other minor text clarifications.
2669 Appendix B: Open Issues/ToDo List
2671 1). Normative vs. Informative references must be carefully rechecked.
2673 2). Replace ABNF with the reference to RFC 2234bis?
2675 3). Resolve ISO-8859-1 and SASLPrep interaction issue as reported by
2676 Simon Josefsson.
2678 4). Can we drop ISO-8859-1 stuff in favor of UTF-8? This is what
2679 people have suggested for HTTP Digest.
2681 5). "SHOULD SASLprep" / "MUST fail authentication exchange" language
2682 should be checked for consistency. Also, should SASLPrep be
2683 applied BEFORE or AFTER checking for ISO-8859-1 subset? (I think
2684 it should be before)
2686 6). Pick a way to fix CBC mode attack.
2698 Leach & Newman Expires: January 2006 [Page 45]