| blob | bc832d1410b5fafeaf171c99594e0560a3f2926c |
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 October 2005
15 Using Digest Authentication as a SASL Mechanism
16 draft-ietf-sasl-rfc2831bis-07.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).
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: April 2006 [Page 1]
64 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
67 Table of Contents
69 1 INTRODUCTION.....................................................3
70 1.1 CONVENTIONS AND NOTATION......................................3
71 1.2 CHANNEL BINDINGS..............................................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: April 2006 [Page 2]
124 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152 document are to be interpreted as described in RFC 2119 [RFC 2119].
154 <<This specification uses the same ABNF notation and lexical
155 conventions as HTTP/1.1 specification; see section 7>>.
157 Let { a, b, ... } be the concatenation of the octet strings a, b, ...
159 Let ** denote the power operation.
161 Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
163 Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string
164 k, a colon and the string s.
166 Let HEX(n) be the representation of the 16 octet MD5 hash n as a
167 string of 32 hex digits (with alphabetic characters always in lower
168 case, since MD5 is case sensitive).
170 Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet
171 string s using the octet string k as a key.
178 Leach & Newman Expires: April 2006 [Page 3]
184 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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 Channel Bindings
201 "Channel binding" is a concept described in [RFC2743] and which
202 refers to the act of cryptographically binding authentication at one
203 network layer to a secure channel at another layer and where the end-
204 points at both layers are the same entities. In the context of the
205 DIGEST-MD5 SASL mechanism this means ensuring that the challenge and
206 response messages include the "channel bindings" of any cryptographic
207 channel (e.g. TLS) over which the DIGEST-MD5 exchange is transported,
208 and that the inputs to the digest function include the same as well.
209 The "channel bindings" of a channel here refer to information which
210 securely identifies one instance of such a channel to both endpoints
211 such that MITM attacks are detectable. For TLS, the channel
212 bindings are the TLS client and server finished messages.
214 Channel bindings are herein added to DIGEST-MD5 by overloading the
215 nonce and cnonce fields of the digest-challenge and digest-response
216 messages, respectively. Because these nonces are treated as opaque
217 octet strings in previous versions of this mechanism such overloading
218 is backwards compatible. Because these nonces are used in the
219 construction of the response-value (i.e., as input to the digest
220 function) using these fields for carrying channel bindings data makes
221 the channel binding operation possible without requiring incompatible
222 changes to the message formats. The fact that the odds that older
223 implementations may select random nonces that resemble actual channel
224 bindings data are so low allows new implementations to detect old
225 peers and to decide whether to allow such peers or reject them
226 according to local policy.
238 Leach & Newman Expires: April 2006 [Page 4]
244 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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: April 2006 [Page 5]
304 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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 ;; contains data described by "nonce-data"
316 qop-options = "qop" "=" <"> qop-list <">
317 qop-list = 1#qop-value
318 qop-value = "auth" | "auth-int" | "auth-conf" |
319 qop-token
320 ;; qop-token is reserved for identifying future
321 ;; extensions to DIGEST-MD5
322 qop-token = token
323 stale = "stale" "=" "true"
324 server_maxbuf = "maxbuf" "=" maxbuf-value
325 maxbuf-value = 1*DIGIT
326 charset = "charset" "=" "utf-8"
327 algorithm = "algorithm" "=" "md5-sess"
328 cipher-opts = "cipher" "=" <"> 1#cipher-value <">
329 cipher-value = "rc4-40" | "rc4" | "rc4-56" |
330 "aes-cbc" | cipher-token
331 ;; cipher-token is reserved for new ciphersuites
332 cipher-token = token
333 auth-param = token "=" ( token | quoted-string )
334 nonce-data = new-nonce-data | obs-nonce-data
335 new-nonce-data = "CB-" channel-type ":" channel-bindings ":" nonce-octets
336 obs-nonce-data = nonce-octets
337 ;; nonce value as defined in RFC 2831. Should be accepted
338 ;; must not be generated.
339 channel-type = "TLS" / channel-type-ext
340 channel-type-ext = 1*(ALPHA | DIGIT)
341 ;; for future channel bindings
342 channel-bindings = 1*TEXTCHAR
343 ;; channel binding data as defined by the channel type
344 nonce-octets = 1*TEXTCHAR
346 The meanings of the values of the directives used above are as
347 follows:
349 realm
350 Mechanistically, a string which enables users to decide which
351 username and password to use, in case they have different ones for
352 different servers. Conceptually, it is the name of a collection
353 of accounts that might include the user's account. This string
354 should contain the name of the host performing the authentication
358 Leach & Newman Expires: April 2006 [Page 6]
364 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
367 and might additionally indicate the collection of users who might
368 have access. An example might be
369 "registered_users@gotham.news.example.com". Note that the server
370 MAY not advertise (hide) some or all realms it supports.
372 Other examples:
374 1) "dc=gotham, dc=news, dc=example, dc=com".
376 2) If there are two servers (e.g. server1.example.com and
377 server2.example.com) that share authentication database, they
378 both may advertise "example.com" as the realm.
380 A server implementation that uses a fixed string as the advertised
381 realm is compliant with this specification, however this is not
382 recommended. See also sections 3.10 "Storing passwords" and 3.11
383 "Multiple realms" for discussion.
385 The value of this directive is case-sensitive. This directive is
386 optional; if not present, the client SHOULD solicit it from the
387 user or be able to compute a default; a plausible default might be
388 the realm supplied by the user when they logged in to the client
389 system. Multiple realm directives are allowed, in which case the
390 user or client must choose one as the realm for which to supply
391 username and password.
393 Requirements on UIs: UIs MUST allow users to enter arbitrary user
394 names and realm names. In order to achieve this, UIs MAY present
395 two separate edit boxes. Alternatively, UIs MAY present a single
396 edit box and allow user to enter a special character that
397 separates user name from the realm name. In the latter case, UIs
398 MUST be able to escape the special character and they need to
399 present their escape rules to the user. UIs MUST also present the
400 list of realms advertised by the server.
402 nonce
403 A server-specified string erstwhile intended to add entropy to the
404 challenge. The nonce field may be used to exchange channel
405 binding data.
407 This directive is required and MUST appear exactly once; if not
408 present, or if multiple instances are present, the client should
409 abort the authentication exchange.
411 Older implementations typically generate some random or pseudo-
412 random data and base64 [RFC 3548] or hexadecimally encode it.
413 When channel binding is not used the nonce string MUST be
414 different each time a digest-challenge is sent as part of initial
418 Leach & Newman Expires: April 2006 [Page 7]
424 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
427 authentication. It is RECOMMENDED that the random data contain at
428 least 64 bits of entropy.
430 When channel binding is performed, the nonce must be generated
431 from the channel type, the bindings to the channel being bound to
432 and an actual nonce consisting of 64-bits or more of entropy and
433 base64-encoded, and formatted as follows:
435 "CB-" <channel type> ":" <channel bindings> ":" <nonce octets>
437 The only channel binding currently defined is to TLS channels.
438 The channel type for TLS is "TLS" and the channel bindings for TLS
439 channels consist of the TLS client and server finished messages
440 concatenated in that order and base64-encoded.
442 <<Do we need an IANA registry?>>
444 An actual nonce is included in order to allow for channel bindings
445 to possible future channels with channel bindings data which is
446 not necessarily unique for each instance.
448 When channel bindings are in use, clients MUST reject challenges
449 that contain server nonce values of this form and whose channel
450 bindings do not match those of the actual underlying channel as
451 observed by the client.
453 qop-options
454 A quoted string of one or more comma-separated tokens indicating
455 the "quality of protection" values supported by the server. The
456 value "auth" indicates authentication; the value "auth-int"
457 indicates authentication with integrity protection; the value
458 "auth-conf" indicates authentication with integrity protection and
459 encryption. This directive is optional; if not present it
460 defaults to "auth". The client MUST ignore unrecognized options;
461 if the client recognizes no option, it MUST abort the
462 authentication exchange.
464 <<What if this directive is present multiple times? Error, or take
465 the union of all values?>>
467 stale
468 The "stale" directive is not used in initial authentication. See
469 the next section for its use in subsequent authentications. This
470 directive may appear at most once; if multiple instances are
471 present, the client MUST abort the authentication exchange.
473 server_maxbuf ("maximal ciphertext buffer size")
474 A number indicating the size of the largest buffer (in bytes) the
478 Leach & Newman Expires: April 2006 [Page 8]
484 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
487 server is able to receive when using "auth-int" or "auth-conf".
488 The value MUST be bigger than 16 (32 for Confidentiality
489 protection with the "aes-cbc" cipher) and smaller or equal to
490 16777215 (i.e. 2**24-1). If this directive is missing, the default
491 value is 65536. This directive may appear at most once; if
492 multiple instances are present, or the value is out of range the
493 client MUST abort the authentication exchange.
495 Let "maximal cleartext buffer size" (or "maximal sender size") be
496 the maximal size of a cleartext buffer that, after being
497 transformed by integrity (section 2.3) or confidentiality (section
498 2.4) protection function, will produce a SASL block of the maxbuf
499 size. As it should be clear from the name, the sender MUST never
500 pass a block of data bigger than the "maximal sender size" through
501 the selected protection function. This will guarantee that the
502 receiver will never get a block bigger than the maxbuf.
538 Leach & Newman Expires: April 2006 [Page 9]
544 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
547 charset
548 This directive, if present, specifies that the server supports
549 UTF-8 [UTF-8] encoding for the username, realm and password. If
550 present, the username, realm and password are encoded as UTF-8
551 [UTF-8]. If not present, the username, realm and password used by
552 the client in Step 2 MUST be encoded in ISO 8859-1 [ISO-8859] (of
553 which US-ASCII [USASCII] is a subset). The directive is needed for
554 backwards compatibility with HTTP Digest, which only supports ISO
555 8859-1. This directive may appear at most once; if multiple
556 instances are present, the client MUST abort the authentication
557 exchange.
559 Note, that this directive doesn't affect authorization id
560 ("authzid").
562 algorithm
563 This directive is required for backwards compatibility with HTTP
564 Digest, which supports other algorithms. This directive is
565 required and MUST appear exactly once; if not present, or if
566 multiple instances are present, the client SHOULD abort the
567 authentication exchange.
569 cipher-opts
570 A list of ciphers that the server supports. This directive must be
571 present exactly once if "auth-conf" is offered in the
572 "qop-options" directive, in which case the "rc4" cipher is
573 mandatory-to-implement. The client MUST ignore unrecognized
574 ciphers; if the client recognizes no cipher, it MUST behave as if
575 "auth-conf" qop option wasn't provided by the server. If the
576 client recognizes no cipher and the server only advertised "auth-
577 conf" in the qop option, the client MUST abort the authentication
578 exchange. See section 2.4 for more detailed description of the
579 ciphers.
581 rc4, rc4-40, rc4-56
582 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
583 respectively.
585 aes-cbc
586 the Advanced Encryption Standard (AES) cipher [AES] in cipher
587 block chaining (CBC) mode with a 128 bit key and explicit
588 Initialization Vector (IV). This mode requires an IV that has
589 the same size as the block size.
591 auth-param
592 This construct allows for future extensions; it may appear more
593 than once. The client MUST ignore any unrecognized directives.
598 Leach & Newman Expires: April 2006 [Page 10]
604 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
607 For use as a SASL mechanism, note that the following changes are made
608 to "digest-challenge" from HTTP: the following Digest options (called
609 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
610 and MUST be ignored if received):
612 opaque
613 domain
615 The size of a "digest-challenge" MUST be less than 2048 bytes.
617 2.1.2 Step Two
619 The client validates "digest-challenge" as described in the previous
620 section. In particular, when channel bindings are in use, client MUST
621 reject "digest-challenge" that contain server nonce whose channel
622 bindings do not match those of the actual underlying channel as
623 observed by the client.
625 The client makes note of the "digest-challenge" and then responds
626 with a string formatted and computed according to the rules for a
627 "digest-response" defined as follows:
629 digest-response = 1#( username | realm | nonce | cnonce |
630 nonce-count | qop | digest-uri | response |
631 client_maxbuf | charset | cipher | authzid |
632 auth-param )
634 username = "username" "=" username-value
635 username-value = quoted-string
636 cnonce = "cnonce" "=" cnonce-value
637 cnonce-value = nonce-value
638 nonce-count = "nc" "=" nc-value
639 nc-value = 8LHEX
640 client_maxbuf = "maxbuf" "=" maxbuf-value
641 qop = "qop" "=" qop-value
642 digest-uri = "digest-uri" "=" <"> digest-uri-value <">
643 digest-uri-value = serv-type "/" host [ "/" serv-name ]
644 serv-type = 1*ALPHA
645 serv-name = host
646 response = "response" "=" response-value
647 response-value = 32LHEX
648 LHEX = "0" | "1" | "2" | "3" |
649 "4" | "5" | "6" | "7" |
650 "8" | "9" | "a" | "b" |
651 "c" | "d" | "e" | "f"
652 cipher = "cipher" "=" cipher-value
653 authzid = "authzid" "=" authzid-value
654 authzid-value = quoted-string
658 Leach & Newman Expires: April 2006 [Page 11]
664 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
667 The 'host' non-terminal is defined in [RFC 3986] as
669 host = IP-literal / IPv4address / reg-name
671 username
672 The user's name in the specified realm, encoded according to the
673 value of the "charset" directive. This directive is REQUIRED and
674 MUST be present exactly once; otherwise, authentication fails.
676 If the charset directive is also specified (which means that the
677 username is encoded as UTF-8) the client MUST first check if all
678 the characters of the username are in the ISO 8859-1 character
679 set. If they are, no further changes are performed. Otherwise, the
680 client SHOULD prepare <<SHOULD prepare or MUST prepare, but SHOULD
681 use SASLPrep. The same issue elsewhere>> the username using the
682 "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC
683 3454]. If the preparation of the username fails or results in an
684 empty string, the client SHOULD abort the authentication exchange
685 (*). If the preparation succeeds, the prepared value will be sent
686 to the server and used in hash computations described in section
687 2.1.2.1.
689 (*) An interactive client can request a repeated entry of username
690 value.
692 realm
693 The realm containing the user's account, encoded according to the
694 value of the "charset" directive. This directive MUST appear at
695 most once and SHOULD contain one of the realms provided by the
696 server in the "digest-challenge". If the directive is missing,
697 "realm-value" will set to the empty string when computing A1 (see
698 below for details).
700 If the realm value was provided by the client and if the charset
701 directive is also specified in "digest-response" (which means that
702 the realm is encoded as UTF-8), the client SHOULD first prepare it
703 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
704 algorithm [RFC 3454]. If the preparation of the realm fails, the
705 client SHOULD abort the authentication exchange(*). If the
706 preparation succeeds, the prepared version is sent to the server
707 and used in hash computations described in section 2.1.2.1.
709 (*) An interactive client can request a repeated entry of the
710 realm value.
712 nonce
713 The server-specified data string received in the preceding digest-
714 challenge. This directive is required and MUST be present exactly
718 Leach & Newman Expires: April 2006 [Page 12]
724 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
727 once; otherwise, authentication fails.
729 cnonce
730 A client-specified string erstwhile intended to add entropy to the
731 challenge. The cnonce field may be used to exchange channel
732 binding data.
734 This directive is required and MUST be present exactly once;
735 otherwise, authentication fails.
737 Older implementations typically generate some random or pseudo-
738 random data and base64 [RFC 3548] or hexadecimally encode it.
739 When channel binding is not used the cnonce string MUST be
740 different each time a digest-challenge is sent as part of initial
741 authentication. It is RECOMMENDED that the random data contain at
742 least 64 bits of entropy.
744 When channel binding is performed, the cnonce must be generated
745 from the channel type, the bindings to the channel being bound to
746 and an actual nonce consisting of 64-bits or more of entropy and
747 base64-encoded, and formatted as follows:
749 "CB-" <channel type> ":" <channel bindings> ":" <nonce octets>
751 The only channel binding currently defined is to TLS channels.
752 The channel type for TLS is "TLS" and the channel bindings for TLS
753 channels consist of the TLS client and server finished messages
754 concatenated in that order and base64-encoded.
756 An actual nonce is included in order to allow for channel bindings
757 to possible future channels with channel bindings data which is
758 not necessarily unique for each instance. It is used by both
759 client and server to avoid chosen plaintext attacks, and to
760 provide mutual authentication.
762 nonce-count
763 The nc-value is the hexadecimal count of the number of requests
764 (including the current request) that the client has sent with the
765 nonce value in this request. For example, in the first request
766 sent in response to a given nonce value, the client sends
767 "nc=00000001". The purpose of this directive is to allow the
768 server to detect request replays by maintaining its own copy of
769 this count - if the same nc-value is seen twice, then the request
770 is a replay. See the description below of the construction of the
771 response value. This directive is required and MUST be present
772 exactly once; otherwise, or if the value is 0, authentication
773 fails.
778 Leach & Newman Expires: April 2006 [Page 13]
784 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
787 qop
788 Indicates what "quality of protection" the client accepted. If
789 present, it may appear exactly once and its value MUST be one of
790 the alternatives in qop-options. If not present, it defaults to
791 "auth". These values affect the computation of the response. Note
792 that this is a single token, not a quoted list of alternatives.
794 serv-type
795 Indicates the type of service, such as "http" for web service,
796 "ftp" for FTP service, "smtp" for mail delivery service, etc. The
797 service name as defined in the SASL profile for the protocol see
798 section 4 of [RFC 2222], registered in the IANA registry of
799 "service" elements for the GSSAPI host-based service name form
800 [RFC 2078].
802 host
803 The DNS host name or IP (IPv4 or IPv6) address for the service
804 requested. The DNS host name must be the fully-qualified
805 canonical name of the host. The DNS host name is the preferred
806 form; see notes on server processing of the digest-uri.
808 serv-name
809 Indicates the name of the service if it is replicated. The service
810 is considered to be replicated if the client's service-location
811 process involves resolution using standard DNS lookup operations,
812 and if these operations involve DNS records (such as SRV [RFC
813 2052], or MX) which resolve one DNS name into a set of other DNS
814 names. In this case, the initial name used by the client is the
815 "serv-name", and the final name is the "host" component. For
816 example, the incoming mail service for "example.com" may be
817 replicated through the use of MX records stored in the DNS, one of
818 which points at an SMTP server called "mail3.example.com"; it's
819 "serv-name" would be "example.com", it's "host" would be
820 "mail3.example.com". If the service is not replicated, or the
821 serv-name is identical to the host, then the serv-name component
822 MUST be omitted.
824 digest-uri
825 Indicates the principal name of the service with which the client
826 wishes to connect, formed from the serv-type, host, and serv-name.
827 For example, the FTP service on "ftp.example.com" would have a
828 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
829 the example above would have a "digest-uri" value of
830 "SMTP/mail3.example.com/example.com".
832 Servers SHOULD check that the supplied value is correct. This will
833 detect accidental connection to the incorrect server, as well as some
834 redirection attacks. It is also so that clients will be trained to
838 Leach & Newman Expires: April 2006 [Page 14]
844 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
847 provide values that will work with implementations that use a shared
848 back-end authentication service that can provide server
849 authentication.
851 The serv-type component should match the service being offered. The
852 host component should match one of the host names of the host on
853 which the service is running, or it's IP address. Servers SHOULD NOT
854 normally support the IP address form, because server authentication
855 by IP address is not very useful; they should only do so if the DNS
856 is unavailable or unreliable. The serv-name component should match
857 one of the service's configured service names.
859 This directive is required and MUST be present exactly once; if
860 multiple instances are present, the server MUST abort the
861 authentication exchange.
863 Note: In the HTTP use of Digest authentication, the digest-uri is the
864 URI (usually a URL) of the resource requested -- hence the name of
865 the directive.
867 response
868 A string of 32 hex digits computed as defined below, which proves
869 that the user knows a password. This directive is required and
870 MUST be present exactly once; otherwise, authentication fails.
872 client_maxbuf
873 A number indicating the size of the largest ciphertext buffer the
874 client is able to receive when using "auth-int" or "auth-conf". If
875 this directive is missing, the default value is 65536. This
876 directive may appear at most once; if multiple instances are
877 present, the server MUST abort the authentication exchange. If the
878 value is less or equal to 32 (if "aes-cbc" cipher was selected) or
879 16 (if one of the rc4 ciphers was selected), or bigger than
880 16777215 (i.e. 2**24-1), the server MUST abort the authentication
881 exchange.
883 Upon processing/sending of the client_maxbuf value both the server
884 and the client calculate their "maximal ciphertext buffer size" as
885 the minimum of the server_maxbuf (Step One) and the client_maxbuf
886 (Step Two). The "maximal sender size" can be calculated by
887 subtracting 32 (if "aes-cbc" cipher was selected) or 16 (for any
888 of the rc4 ciphers) from the calculated "maximal ciphertext buffer
889 size".
891 When sending a block of data the client/server MUST NOT pass more
892 than the "maximal sender size" bytes of data to the selected
893 protection function (2.3 or 2.4).
898 Leach & Newman Expires: April 2006 [Page 15]
904 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
907 charset
908 This directive, if present, specifies that the client has used
909 UTF-8 [UTF-8] encoding for the username, realm and password. If
910 present, the username, realm and password are encoded as UTF-8
911 [UTF-8]. If not present, the username, realm and password MUST be
912 encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a
913 subset). The client should send this directive only if the server
914 has indicated that it supports UTF-8 [UTF-8]. The directive is
915 needed for backwards compatibility with HTTP Digest, which only
916 supports ISO 8859-1.
918 Note, that this directive doesn't affect the authorization
919 identity ("authzid").
921 LHEX
922 32 hex digits, where the alphabetic characters MUST be lower case,
923 because MD5 is not case insensitive.
925 cipher
926 The cipher chosen by the client. This directive MUST appear
927 exactly once if "auth-conf" is negotiated; if required and not
928 present, authentication fails. If the cipher chosen by the client
929 is not one of the ciphers advertised by the server, authentication
930 fails.
932 authzid
933 The "authorization ID" (authzid) directive may appear at most
934 once; if multiple instances are present, the server MUST abort the
935 authentication exchange. If present, and the authenticating user
936 has sufficient privilege, and the server supports it, then after
937 authentication the server will use this identity for making all
938 accesses and access checks. If the client specifies it, and the
939 server does not support it, then the response-value calculated on
940 the server will not match the one calculated on the client and
941 authentication will fail.
943 The authzid MUST NOT be an empty string.
945 The authorization identifier MUST NOT be converted to ISO 8859-1
946 even if the authentication identifier ("username") is converted
947 for compatibility as directed by "charset" directive.
949 The server SHOULD verify the correctness of an authzid as
950 specified by the corresponding SASL protocol profile.
952 The size of a digest-response MUST be less than 4096 bytes.
954 2.1.2.1 Response-value
958 Leach & Newman Expires: April 2006 [Page 16]
964 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
967 The definition of "response-value" above indicates the encoding for
968 its value -- 32 lower case hex characters. The following definitions
969 show how the value is computed.
971 Although qop-value and components of digest-uri-value may be
972 case-insensitive, the case which the client supplies in step two is
973 preserved for the purpose of computing and verifying the
974 response-value.
976 response-value =
977 HEX( KD ( HEX(H(A1)),
978 { unq(nonce-value), ":" nc-value, ":",
979 unq(cnonce-value), ":", qop-value, ":", HEX(H(A2)) }))
981 If authzid is specified, then A1 is
983 A1 = { SS, ":", unq(nonce-value), ":",
984 unq(cnonce-value), ":", unq(authzid-value) }
986 If authzid is not specified, then A1 is
988 A1 = { SS, ":", unq(nonce-value), ":", unq(cnonce-value) }
990 where
992 password = *OCTET
994 SS = H( { unq(username-value), ":", unq(realm-value), ":", password } )
998 The "username-value", "realm-value" and "password" are encoded
999 according to the value of the "charset" directive. If "charset=UTF-8"
1000 is present, and all the characters of "username-value" are in the ISO
1001 8859-1 character set, then it MUST be converted to ISO 8859-1 before
1002 being hashed. The same transformation has to be done for "realm-
1003 value" and "password". This is so that authentication databases that
1004 store the hashed username, realm and password (which is common) can
1005 be shared compatibly with HTTP, which specifies ISO 8859-1. A sample
1006 implementation of this conversion is in section 8.
1008 Note that on the client side the "username-value", "realm-value"(*)
1009 and "password" MUST be prepared before being encoded as described in
1010 the previous paragraph. The [SASLPrep] profile of the [StringPrep]
1011 algorithm is the RECOMMENDED preparation algorithm. The SASLprep
1012 preparation algorithm is recommended to improve the likelihood that
1013 comparisons behave in an expected manner. The SASLprep preparation
1014 algorithm is not mandatory. This is done to allow, when appropriate,
1018 Leach & Newman Expires: April 2006 [Page 17]
1024 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1027 the server to employ other preparation algorithms (including none).
1028 For instance, use of different preparation algorithm may be necessary
1029 for the server to interoperate with an external system.
1031 (*) - Note that if the "realm-value" was provided by the client (i.e.
1032 not chosen from the list of realms returned by the server), it MUST
1033 NOT be prepared.
1035 On the server side the preparation of the "username-value", "realm-
1036 value" and "password" MUST NOT be performed.
1038 If the "qop" directive's value is "auth", then A2 is:
1040 A2 = { "AUTHENTICATE:", digest-uri-value }
1078 Leach & Newman Expires: April 2006 [Page 18]
1084 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1087 If the "qop" value is "auth-int" or "auth-conf" then A2 is:
1089 A2 = { "AUTHENTICATE:", digest-uri-value,
1090 ":00000000000000000000000000000000" }
1092 Note that "AUTHENTICATE:" must be in upper case, and the second
1093 string constant is a string with a colon followed by 32 zeros.
1095 These apparently strange values of A2 are for compatibility with
1096 HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
1097 the hash of the entity body to zero in the HTTP digest calculation of
1098 A2.
1100 Also, in the HTTP usage of Digest, several directives in the
1101 "digest-challenge" sent by the server have to be returned by the
1102 client in the "digest-response". These are:
1104 opaque
1105 algorithm
1107 These directives are not needed when Digest is used as a SASL
1108 mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
1110 2.1.3 Step Three
1112 The server receives and validates the "digest-response". In
1113 particular, when channel bindings are in use, server MUST reject
1114 "digest-response" that contain client nonce whose channel bindings do
1115 not match those of the actual underlying channel as observed by the
1116 server.
1118 The server also checks that the nonce-count is "00000001". If it
1119 supports subsequent authentication (see section 2.2), it saves the
1120 value of the nonce <<(do channel bindings affect reauthentication?)>>
1121 and the nonce-count. It sends a message formatted as follows:
1123 auth-info = 1#( response-auth | auth-param )
1125 response-auth = "rspauth" "=" response-value
1127 where response-value is calculated as above, using the values sent in
1128 step two, except that if qop is "auth", then A2 is
1130 A2 = { ":", digest-uri-value }
1132 And if qop is "auth-int" or "auth-conf" then A2 is
1134 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
1138 Leach & Newman Expires: April 2006 [Page 19]
1144 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1147 Note that only one occurance of the "response-auth" is allowed. If
1148 more than one is found, the client MUST treat this as an
1149 authentication error.
1151 Compared to its use in HTTP, the following Digest directives in the
1152 "auth-info" are unused:
1154 nextnonce
1155 qop
1156 cnonce
1157 nonce-count
1159 The size of an auth-info MUST be less than 2048 bytes.
1161 2.2 Subsequent Authentication
1163 If the client has previously authenticated to the server, and
1164 remembers the values of username, realm, nonce, nonce-count, cnonce,
1165 and qop that it used in that authentication, and the SASL profile for
1166 a protocol permits an initial client response, then it MAY perform
1167 "subsequent authentication" or "fast reauthentication", as defined in
1168 this section. Note, that a subsequent authentication can be done on
1169 a different connection, or on the same connection, if the protocol
1170 profile also permits multiple authentications.
1172 2.2.1 Step one
1174 The client uses the values from the previous authentication and sends
1175 an initial response with a string formatted and computed according to
1176 the rules for a "digest-response", as defined above, but with a
1177 nonce-count one greater than used in the last "digest-response".
1179 2.2.2 Step Two
1181 The server receives the "digest-response". If the server does not
1182 support subsequent authentication, then it sends a
1183 "digest-challenge", and authentication proceeds as in initial
1184 authentication. If the server has no saved nonce and nonce-count from
1185 a previous authentication, then it sends a "digest-challenge", and
1186 authentication proceeds as in initial authentication. Otherwise, the
1187 server validates the "digest-response", checks that the nonce-count
1188 is one greater than that used in the previous authentication using
1189 that nonce, and saves the new value of nonce-count.
1191 If the response is invalid, then the server sends a
1192 "digest-challenge", and authentication proceeds as in initial
1193 authentication (and should be configurable to log an authentication
1194 failure in some sort of security audit log, since the failure may be
1198 Leach & Newman Expires: April 2006 [Page 20]
1204 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1207 a symptom of an attack). The nonce-count MUST NOT be incremented in
1208 this case: to do so would allow a denial of service attack by sending
1209 an out-of-order nonce-count.
1211 If the response is valid, the server MAY choose to deem that
1212 authentication has succeeded. However, if it has been too long since
1213 the previous authentication, or for any other reason, the server MAY
1214 send a new "digest-challenge" with a new value for nonce. The
1215 challenge MAY contain a "stale" directive with value "true", which
1216 says that the client may respond to the challenge using the password
1217 it used in the previous response; otherwise, the client must solicit
1218 the password anew from the user. This permits the server to make sure
1219 that the user has presented their password recently. (The directive
1220 name refers to the previous nonce being stale, not to the last use of
1221 the password.) Except for the handling of "stale", after sending the
1222 "digest-challenge" authentication proceeds as in the case of initial
1223 authentication.
1225 2.3 Integrity Protection
1227 If the server offered "qop=auth-int" and the client responded
1228 "qop=auth-int", then subsequent messages, up to but not including the
1229 next subsequent authentication, between the client and the server
1230 MUST be integrity protected. Using as a base session key the value of
1231 H(A1), as defined above the client and server calculate a pair of
1232 message integrity keys as follows.
1234 The key for integrity protecting messages from client to server is:
1236 Kic = MD5({H(A1),
1237 "Digest session key to client-to-server signing key magic constant"})
1239 The key for integrity protecting messages from server to client is:
1241 Kis = MD5({H(A1),
1242 "Digest session key to server-to-client signing key magic constant"})
1244 where MD5 is as specified in [RFC 1321]. If message integrity is
1245 negotiated, a MAC block for each message is appended to the message.
1246 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
1247 2104] of the message, a 2-byte message type number in network byte
1248 order with value 1, and the 4-byte sequence number in network byte
1249 order. The message type is to allow for future extensions such as
1250 rekeying.
1252 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
1253 SeqNum)
1258 Leach & Newman Expires: April 2006 [Page 21]
1264 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1267 where Ki is Kic for messages sent by the client and Kis for those
1268 sent by the server. The sequence number (SeqNum) is an unsigned
1269 number initialized to zero after initial or subsequent
1270 authentication, and incremented by one for each message
1271 sent/successfully verified. (Note, that there are two independent
1272 counters for sending and receiving.) The sequence number wraps around
1273 to 0 after 2**32-1.
1275 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
1276 received value; the message is discarded if they differ and as the
1277 result the connection being used MUST be dropped. The receiver's
1278 sequence counter is incremented if they match.
1280 2.4 Confidentiality Protection
1282 If the server sent a "cipher-opts" directive and the client responded
1283 with a "cipher" directive, then subsequent messages between the
1284 client and the server MUST be confidentiality protected. Using as a
1285 base session key the value of H(A1) as defined above the client and
1286 server calculate a pair of message integrity keys as follows.
1288 The key for confidentiality protecting messages from client to server
1289 is:
1291 Kcc = MD5({H(A1)[0..n-1],
1292 "Digest H(A1) to client-to-server sealing key magic constant"})
1294 The key for confidentiality protecting messages from server to client
1295 is:
1297 Kcs = MD5({H(A1)[0..n-1],
1298 "Digest H(A1) to server-to-client sealing key magic constant"})
1300 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
1301 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*"
1302 and "aes-cbc" ciphers is all 16 bytes of Kcc or Kcs.
1304 "aes-cbc" cipher works as described in section 2.4.1.
1306 rc4 cipher state MUST NOT be reset before sending/receiving a next
1307 buffer of protected data.
1310 If the blocksize of the chosen cipher is not 1 byte, the padding
1311 prefix is one or more octets each containing the number of padding
1312 bytes, such that the total length of the encrypted part of the
1313 message is a multiple of the blocksize.
1318 Leach & Newman Expires: April 2006 [Page 22]
1324 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1327 The MAC block is 16 bytes formatted as follows: the first 10 bytes of
1328 the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number
1329 in network byte order with value 1, and the 4-byte sequence number in
1330 network byte order.
1332 The padding and first 10 bytes of the MAC block are encrypted with
1333 the chosen cipher along with the message and explicit IV (if
1334 present).
1336 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {exp_iv, msg, pad, MAC})
1338 MAC(Ki, SeqNum, exp_iv, msg) = {HMAC(Ki, {SeqNum, exp_iv, msg})[0..9],
1339 packet_type_data, SeqNum}
1341 packet_type_data = 0x0001
1343 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
1344 messages sent by the client and Kis and Kcs for those sent by the
1345 server, exp_iv is empty string for rc4 ciphers and a randomly
1346 generated number R of the length 128 bit for the "aes-cbc" cipher.
1347 The sequence number (SeqNum) is an unsigned number initialized to
1348 zero after initial or subsequent authentication, and incremented by
1349 one for each message sent/successfully verified. (Note, that there
1350 are two independent counters for sending and receiving.) The sequence
1351 number wraps around to 0 after 2**32-1.
1353 Upon receipt, the message is decrypted, exp_iv is ignored (for the
1354 "aes-cbc" cipher only), HMAC(Ki, {SeqNum, msg}) is computed and
1355 compared with the received value; the padding and the packet type are
1356 verified. The message is discarded if the received and the
1357 calculated HMACs differ and/or the padding is invalid. See also
1358 section 3.8 for important information about MAC and padding
1359 verification. The receiver's sequence counter is then compared with
1360 the received SeqNum value; the message is discarded if they differ
1361 and, as the result, the connection being used MUST be dropped. The
1362 receiver's sequence counter is incremented if they match.
1364 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc")
1366 Unlike previous versions of DIGEST-MD5, this document uses an
1367 explicit IV for ciphers in CBC mode. This is done in order to prevent
1368 the attacks described by [CBCATT].
1370 For each buffer of cleartext data to be encrypted the sender performs
1371 the following procedure:
1373 0) For the very first SASL packet sent the IV is calculated as
1374 follows:
1378 Leach & Newman Expires: April 2006 [Page 23]
1384 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1387 The IV for the first SASL packet going from the client
1388 to the server (IVc) consists of 16 bytes calculated as follows:
1390 IVc = MD5({Kcc, "aes-128"})
1392 The IV for the first SASL packet going from the server
1393 to the client (IVs) consists of 16 bytes calculated as follows:
1395 IVs = MD5({Kcs, "aes-128"})
1397 For a subsequent packet: Em of the previous packet (see below)
1398 becomes the IV.
1400 1) Generate a cryptographically strong random number R of length 128
1401 bits (16 octets) and prepend it to the plaintext prior to
1402 encryption.
1404 2) padding and MAC block are constructed (see section 2.4) and
1405 appended to the end of the plaintext. After this step the data
1406 to be encrypted will look like:
1408 {R, msg, pad, MAC}
1410 As the total length of the data will be multiple of AES block size
1411 (i.e. 128 bit), this can also be represented as
1413 {P1, P2, P3, ..., Pm}
1415 where Pi is a chunk of data of the length 128 bit. Note, that
1416 P1 is R.
1418 3) Data is encrypted as follows:
1420 E1 = CIPHER ( Kc, P1 XOR IV )
1421 E2 = CIPHER ( Kc, P2 XOR E1 )
1422 E3 = CIPHER ( Kc, P3 XOR E2 )
1423 ...
1424 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1425 ...
1426 Em = CIPHER ( Kc, Pm XOR Em-1)
1428 This will generate ciphertext {E1, ..., Em} to be sent as a single
1429 SASL packet.
1432 The receiver performs the following steps:
1434 0) For the very first SASL packet sent the IV is calculated as
1438 Leach & Newman Expires: April 2006 [Page 24]
1444 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1447 in step 0 for the sender.
1449 For a subsequent packet: Em of the previous packet becomes
1450 the IV of the immediately following packet.
1452 1) Data is decrypted as follows:
1454 P1 = CIPHER ( Kc, E1 ) XOR IV
1455 P2 = CIPHER ( Kc, E2 ) XOR E1
1456 P3 = CIPHER ( Kc, E3 ) XOR E2
1457 ...
1458 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1459 ...
1460 Pm = CIPHER ( Kc, Em ) XOR Em-1
1462 Em becomes the IV for the decryption of the subsequent SASL
1463 packet.
1465 This will generate plaintext {P1, ..., Pm}. P1 is discarded,
1466 {P2, ..., Pm} is {msg, pad, MAC}.
1468 2) pad and MAC block are verified as described in section 2.4.
1498 Leach & Newman Expires: April 2006 [Page 25]
1504 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1507 3 Security Considerations
1509 General SASL security considerations apply to this mechanism.
1510 "stringprep" and Unicode security considerations also apply.
1512 Detailed discussion of other DIGEST-MD5 specific security issues is
1513 below.
1515 3.1 Authentication of Clients using Digest Authentication
1517 Digest Authentication does not provide a strong authentication
1518 mechanism, when compared to public key based mechanisms, for example.
1519 However, since it prevents chosen plaintext attacks, it is stronger
1520 than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC
1521 2244], POP and IMAP [RFC 2195]. It is intended to replace the much
1522 weaker and even more dangerous use of plaintext passwords; however,
1523 since it is still a password based mechanism it avoids some of the
1524 potential deployability issues with public-key, OTP or similar
1525 mechanisms.
1527 Digest Authentication offers no confidentiality protection beyond
1528 protecting the actual password. All of the rest of the challenge and
1529 response are available to an eavesdropper, including the user's name
1530 and authentication realm.
1532 3.2 Comparison of Digest with Plaintext Passwords
1534 The greatest threat to the type of transactions for which these
1535 protocols are used is network snooping. This kind of transaction
1536 might involve, for example, online access to a mail service whose use
1537 is restricted to paying subscribers. With plaintext password
1538 authentication an eavesdropper can obtain the password of the user.
1539 This not only permits him to access anything in the database, but,
1540 often worse, will permit access to anything else the user protects
1541 with the same password.
1543 3.3 Replay Attacks
1545 Replay attacks are defeated if the client or the server chooses a
1546 fresh nonce for each authentication, as this specification requires.
1548 As a security precaution, the server, when verifying a response from
1549 the client, must use the original server nonce ("nonce") it sent, not
1550 the one returned by the client in the response, as it might have been
1551 modified by an attacker.
1553 To prevent some redirection attacks it is recommended that the server
1554 verifies that the "serv-type" part of the "digest-uri" matches the
1558 Leach & Newman Expires: April 2006 [Page 26]
1564 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1567 service name and that the hostname/IP address belongs to the server.
1569 3.4 Online dictionary attacks
1571 If the attacker can eavesdrop, then it can test any overheard
1572 nonce/response pairs against a (potentially very large) list of
1573 common words. Such a list is usually much smaller than the total
1574 number of possible passwords. The cost of computing the response for
1575 each password on the list is paid once for each challenge.
1577 The server can mitigate this attack by not allowing users to select
1578 passwords that are in a dictionary.
1580 3.5 Offline dictionary attacks
1582 If the attacker can choose the challenge, then it can precompute the
1583 possible responses to that challenge for a list of common words. Such
1584 a list is usually much smaller than the total number of possible
1585 passwords. The cost of computing the response for each password on
1586 the list is paid just once.
1588 Offline dictionary attacks are defeated if the client chooses a fresh
1589 nonce for each authentication, as this specification requires.
1591 3.6 Man in the Middle
1593 Digest authentication is vulnerable to "man in the middle" (MITM)
1594 attacks. Clearly, a MITM would present all the problems of
1595 eavesdropping. But it also offers some additional opportunities to
1596 the attacker.
1598 A possible man-in-the-middle attack would be to substitute a weaker
1599 qop scheme for the one(s) sent by the server; the server will not be
1600 able to detect this attack. For this reason, the client should always
1601 use the strongest scheme that it understands from the choices
1602 offered, and should never choose a scheme that does not meet its
1603 minimum requirements.
1605 A man-in-the-middle attack may also make the client and the server
1606 that agreed to use confidentiality protection to use different (and
1607 possibly weaker) cipher's. This is because the chosen cipher is not
1608 used in the shared secret calculation.
1610 3.7 Chosen plaintext attacks
1612 A chosen plaintext attack is where a MITM or a malicious server can
1613 arbitrarily choose the challenge that the client will use to compute
1614 the response. The ability to choose the challenge is known to make
1618 Leach & Newman Expires: April 2006 [Page 27]
1624 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1627 cryptanalysis much easier [MD5].
1629 However, Digest does not permit the attack to choose the challenge as
1630 long as the client chooses a fresh nonce for each authentication, as
1631 this specification requires.
1633 3.8 CBC Mode attacks
1635 The following attack can be launched when the connection uses
1636 Confidentiality protection with ciphers in CBC mode. If bad padding
1637 is treated differently from bad MACs when decrypting a DIGEST-MD5
1638 buffer of protected data, the attacker may be able to launch
1639 Vaudenay's [VAUDENAY] attack on padding.
1641 An error logfile will suffice to launch the attack if it reveals the
1642 type of error -- even if file permissions prevent the attacker from
1643 actually reading the file (the file length increase cause by the
1644 attack is likely to reveal which of the two errors occured).
1646 A different approach to distinguish these two error cases and launch
1647 the attack is to examine the timing of error responses: if the MAC
1648 verification is skipped when bad padding has been found, the error
1649 will appear quicker in the case of incorrect block cipher padding
1650 than in the case of an incorrect MAC.
1652 A countermeasure is to compute a MAC of the plaintext anyway, even if
1653 the usual padding removal step fails because of incorrect padding, to
1654 obtain (nearly) uniform timing.
1656 3.9 Spoofing by Counterfeit Servers
1658 If a user can be led to believe that she is connecting to a host
1659 containing information protected by a password she knows, when in
1660 fact she is connecting to a hostile server, then the hostile server
1661 can obtain challenge/response pairs where it was able to partly
1662 choose the challenge. There is no known way that this can be
1663 exploited.
1665 3.10 Storing passwords
1667 Digest authentication requires that the authenticating agent (usually
1668 the server) store some data derived from the user's name and password
1669 in a "password file" associated with a given realm. Normally this
1670 might contain pairs consisting of username and H({ username-value,
1671 ":", realm-value, ":", password }), which is adequate to compute
1672 H(A1) as described above without directly exposing the user's
1673 password.
1678 Leach & Newman Expires: April 2006 [Page 28]
1684 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1687 The security implications of this are that if this password file is
1688 compromised, then an attacker gains immediate access to documents on
1689 the server using this realm. Unlike, say a standard UNIX password
1690 file, this information need not be decrypted in order to access
1691 documents in the server realm associated with this file. On the other
1692 hand, decryption, or more likely a brute force attack, would be
1693 necessary to obtain the user's password. This is the reason that the
1694 realm is part of the digested data stored in the password file. It
1695 means that if one Digest authentication password file is compromised,
1696 it does not automatically compromise others with the same username
1697 and password (though it does expose them to brute force attack).
1699 There are two important security consequences of this. First the
1700 password file must be protected as if it contained plaintext
1701 passwords, because for the purpose of accessing documents in its
1702 realm, it effectively does.
1704 A second consequence of this is that the realm string should be
1705 unique among all realms that any single user is likely to use. In
1706 particular a realm string should include the name of the host doing
1707 the authentication.
1738 Leach & Newman Expires: April 2006 [Page 29]
1744 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1747 3.11 Multiple realms
1749 Use of multiple realms may mean both that compromise of a the
1750 security database for a single realm does not compromise all
1751 security, and that there are more things to protect in order to keep
1752 the whole system secure.
1754 3.11 Summary
1756 By modern cryptographic standards Digest Authentication is weak,
1757 compared to (say) public key based mechanisms. But for a large range
1758 of purposes it is valuable as a replacement for plaintext passwords.
1759 Its strength may vary depending on the implementation.
1762 4 Example
1764 This example shows the use of the Digest SASL mechanism with the
1765 IMAP4 AUTHENTICATE command [RFC 3501].
1767 In this example, "C:" and "S:" represent a line sent by the client or
1768 server respectively including a CRLF at the end. Linebreaks and
1769 indentation within a "C:" or "S:" are editorial and not part of the
1770 protocol. The password in this example was "secret". Note that the
1771 base64 encoding of the challenges and responses is part of the IMAP4
1772 AUTHENTICATE command, not part of the Digest specification itself.
1774 S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
1775 C: c CAPABILITY
1776 S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
1777 UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
1778 S: c OK Completed
1779 C: a AUTHENTICATE DIGEST-MD5
1780 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
1781 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
1782 cnNldD11dGYtOA==
1783 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
1784 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
1785 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
1786 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
1787 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
1788 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
1789 C:
1790 S: a OK User logged in
1791 ---
1793 The base64-decoded version of the SASL exchange is:
1798 Leach & Newman Expires: April 2006 [Page 30]
1804 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1807 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
1808 algorithm=md5-sess,charset=utf-8
1809 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1810 nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
1811 digest-uri="imap/elwood.innosoft.com",
1812 response=d388dad90d4bbd760a152321f2143af7,qop=auth
1813 S: rspauth=ea40f60335c427b5527b84dbabcdfffd
1815 The password in this example was "secret".
1817 This example shows the use of the Digest SASL mechanism with the
1818 ACAP, using the same notational conventions and password as in the
1819 previous example. Note that ACAP does not base64 encode and uses
1820 fewer round trips that IMAP4.
1822 S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
1823 "DIGEST-MD5" "PLAIN")
1824 C: a AUTHENTICATE "DIGEST-MD5"
1825 S: + {94}
1826 S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
1827 algorithm=md5-sess,charset=utf-8
1828 C: {206}
1829 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1830 nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
1831 digest-uri="acap/elwood.innosoft.com",
1832 response=6084c6db3fede7352c551284490fd0fc,qop=auth
1833 S: a OK (SASL {40}
1834 S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
1835 Completed"
1836 ---
1838 The server uses the values of all the directives, plus knowledge of
1839 the users password (or the hash of the user's name, server's realm
1840 and the user's password) to verify the computations above. If they
1841 check, then the user has authenticated.
1858 Leach & Newman Expires: April 2006 [Page 31]
1864 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1867 5 References
1869 5.1 Normative references
1871 [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
1872 Access Authentication", RFC 2617, June 1999.
1874 [ISO-8859] ISO-8859. International Standard--Information Processing--
1875 8-bit Single-Byte Coded Graphic Character Sets --
1876 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
1877 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
1878 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
1879 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
1880 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
1881 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
1882 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
1883 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
1884 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
1886 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1887 April 1992.
1889 [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1890 location of services (DNS SRV)", RFC 2052, October 1996.
1892 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1893 Hashing for Message Authentication", RFC 2104, February
1894 1997.
1896 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1897 Requirement Levels", BCP 14, RFC 2119, March 1997.
1899 [RFC 2222] Melnikov, A. (editor), "Simple Authentication and Security
1900 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work
1901 in progress.
1903 [RFC 3454] Hoffman, P., Blanchet, M., "Preparation of
1904 Internationalized Strings ("stringprep")", RFC 3454,
1905 December 2002.
1907 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1908 3.2.0", defined by: The Unicode Standard, Version 3.0
1909 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
1910 as amended by the Unicode Standard Annex #28: Unicode 3.2
1911 (http://www.unicode.org/reports/tr28/tr28-3.html).
1913 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646",
1914 RFC 2279, Janyary 1998.
1918 Leach & Newman Expires: April 2006 [Page 32]
1924 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1927 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
1928 Code for Information Interchange. Standard ANSI X3.4-1986,
1929 ANSI, 1986.
1931 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1932 and passwords", RFC 4013, February 2005.
1934 [RFC 3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1935 Resource Identifier (URI): Generic Syntax", RFC 3986,
1936 January 2005.
1938 [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",
1939 http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf,
1940 3rd September 1999.
1942 [RFC2743] <<TBD>>
1944 5.2 Informative references
1946 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
1947 AUTHorize Extension for Simple Challenge/Response", RFC
1948 2195, September 1997.
1950 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with
1951 MD5", CryptoBytes, Sping 1995, RSA Inc,
1952 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
1954 [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax
1955 Specifications: ABNF", RFC 4234, October 2005.
1957 [RFC 2078] Linn, J., "Generic Security Service Application Program
1958 Interface, Version 2", RFC 2078, January 1997.
1960 [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version
1961 4rev1", RFC 3501, March 2003.
1963 [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
1964 Access Protocol", RFC 2244, November 1997.
1966 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1967 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext
1968 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1970 [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
1971 Problems and Countermeasures",
1972 http://www.openssl.org/~bodo/tls-cbc.txt.
1974 [CBCATT] Canvel, B., "Password Interception in a SSL/TLS Channel",
1978 Leach & Newman Expires: April 2006 [Page 33]
1984 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
1987 published 2003-02-20:
1988 http://lasecwww.epfl.ch/memo_ssl.shtml
1990 [VAUDENAY] Serge Vaudenay, "Security Flaws Induced by CBC Padding -
1991 Applications to SSL, IPSEC, WTLS ...". L.R. Knudsen (Ed.):
1992 EUROCRYPT 2002, LNCS 2332, pp. 534-545, 2002.
1994 [RFC 3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1995 Encodings", RFC 3548, July 2003.
1997 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
1998 MECHANISMS", <http://www.iana.org/assignments/sasl-
1999 mechanisms>.
2038 Leach & Newman Expires: April 2006 [Page 34]
2044 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2047 6 IANA Considerations
2049 It is requested that the SASL Mechanism registry [IANA-SASL] entry for
2050 the DIGEST-MD5 mechanism be updated to reflect that this document now
2051 provides its technical specification.
2053 To: iana@iana.org
2054 Subject: Updated Registration of SASL mechanism DIGEST-MD5
2056 Family of SASL mechanisms: NO
2057 SASL mechanism name: DIGEST-MD5
2058 Security considerations: See RFC XXXX.
2059 Published specification (optional, recommended): RFC XXXX
2060 Person & email address to contact for further information:
2061 Alexey Melnikov <alexey.melnikov@isode.com>
2062 IETF SASL WG <ietf-sasl@imc.org>
2063 Intended usage: COMMON
2064 Author/Change controller: IESG <iesg@ietf.org>
2065 Note: Updates existing entry for DIGEST-MD5
2098 Leach & Newman Expires: April 2006 [Page 35]
2104 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2107 7 ABNF
2109 What follows is the definition of the notation as is used in the
2110 HTTP/1.1 specification [RFC 2616] and the HTTP authentication
2111 specification [Digest]; it is reproduced here for ease of reference.
2112 Since it is intended that a single Digest implementation can support
2113 both HTTP and SASL-based protocols, the same notation is used in both
2114 to facilitate comparison and prevention of unwanted differences.
2115 Since it is cut-and-paste from the HTTP specifications, not all
2116 productions may be used in this specification.
2118 7.1 Augmented BNF
2120 All of the mechanisms specified in this document are described in
2121 both prose and an Augmented Backus-Naur Form (BNF) similar to that
2122 used by [ABNF]. Implementers will need to be familiar with the
2123 notation in order to understand this specification.
2125 The augmented BNF includes the following constructs: <<Can this be
2126 dropped in favor of ABNF?>>
2128 name = definition
2129 The name of a rule is simply the name itself (without any
2130 enclosing "<" and ">") and is separated from its definition by the
2131 equal "=" character. White space is only significant in that
2132 indentation of continuation lines is used to indicate a rule
2133 definition that spans more than one line. Certain basic rules are
2134 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
2135 brackets are used within definitions whenever their presence will
2136 facilitate discerning the use of rule names.
2138 "literal"
2139 Quotation marks surround literal text. Unless stated otherwise,
2140 the text is case-insensitive.
2142 rule1 | rule2
2143 Elements separated by a bar ("|") are alternatives, e.g., "yes |
2144 no" will accept yes or no.
2146 (rule1 rule2)
2147 Elements enclosed in parentheses are treated as a single element.
2148 Thus, "(elem (foo | bar) elem)" allows the token sequences
2149 "elem foo elem" and "elem bar elem".
2151 *rule
2152 The character "*" preceding an element indicates repetition. The
2153 full form is "<n>*<m>element" indicating at least <n> and at most
2154 <m> occurrences of element. Default values are 0 and infinity so
2158 Leach & Newman Expires: April 2006 [Page 36]
2164 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2167 that "*(element)" allows any number, including zero; "1*element"
2168 requires at least one; and "1*2element" allows one or two.
2170 [rule]
2171 Square brackets enclose optional elements; "[foo bar]" is
2172 equivalent to "*1(foo bar)".
2174 N rule
2175 Specific repetition: "<n>(element)" is equivalent to
2176 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
2177 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
2178 alphabetic characters.
2180 #rule
2181 A construct "#" is defined, similar to "*", for defining lists of
2182 elements. The full form is "<n>#<m>element" indicating at least
2183 <n> and at most <m> elements, each separated by one or more commas
2184 (",") and OPTIONAL linear white space (LWS). This makes the usual
2185 form of lists very easy; a rule such as
2186 ( *LWS element *( *LWS "," *LWS element ) *LWS )
2187 can be shown as
2188 1#element
2189 Wherever this construct is used, null elements are allowed, but do
2190 not contribute to the count of elements present. That is,
2191 "(element), , (element) " is permitted, but counts as only two
2192 elements. Therefore, where at least one element is required, at
2193 least one non-null element MUST be present. Default values are 0
2194 and infinity so that "#element" allows any number, including zero;
2195 "1#element" requires at least one; and "1#2element" allows one or
2196 two.
2198 ; comment
2199 A semi-colon, set off some distance to the right of rule text,
2200 starts a comment that continues to the end of line. This is a
2201 simple way of including useful notes in parallel with the
2202 specifications.
2204 implied *LWS
2205 The grammar described by this specification is word-based. Except
2206 where noted otherwise, linear white space (LWS) can be included
2207 between any two adjacent words (token or quoted-string), and
2208 between adjacent words and separators, without changing the
2209 interpretation of a field. At least one delimiter (LWS and/or
2210 separators) MUST exist between any two tokens (for the definition
2211 of "token" below), since they would otherwise be interpreted as a
2212 single token.
2214 7.2 Basic Rules
2218 Leach & Newman Expires: April 2006 [Page 37]
2224 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2227 The following rules are used throughout this specification to
2228 describe basic parsing constructs. The US-ASCII coded character set
2229 is defined by ANSI X3.4-1986 [USASCII].
2231 OCTET = <any 8-bit character>
2232 CHAR = <any US-ASCII character (octets 0 - 127)>
2233 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
2234 LOALPHA = <any US-ASCII lowercase letter "a".."z">
2235 ALPHA = UPALPHA | LOALPHA
2236 DIGIT = <any US-ASCII digit "0".."9">
2237 CTL = <any US-ASCII control character
2238 (octets 0 - 31) and DEL (127)>
2239 CR = <US-ASCII CR, carriage return (13)>
2240 LF = <US-ASCII LF, linefeed (10)>
2241 SP = <US-ASCII SP, space (32)>
2242 HT = <US-ASCII HT, horizontal-tab (9)>
2243 <"> = <US-ASCII double-quote mark (34)>
2244 TEXTCHAR = <any OCTET except CTLs, but including HT>
2245 CRLF = CR LF
2247 All linear white space, including folding, has the same semantics as
2248 SP. A recipient MAY replace any linear white space with a single SP
2249 before interpreting the field value or forwarding the message
2250 downstream.
2252 LWS = [CRLF] 1*( SP | HT )
2254 The TEXT rule is only used for descriptive field contents and values
2255 that are not intended to be interpreted by the message parser. Words
2256 of TEXT contains characters either from ISO-8859-1 [ISO-8859]
2257 character set or UTF-8 [UTF-8].
2259 TEXT = <any *OCTET except CTLs,
2260 but including LWS>
2262 A CRLF is allowed in the definition of TEXT only as part of a header
2263 field continuation. It is expected that the folding LWS will be
2264 replaced with a single SP before interpretation of the TEXT value.
2266 Hexadecimal numeric characters are used in several protocol elements.
2268 HEX = "A" | "B" | "C" | "D" | "E" | "F"
2269 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
2271 Many HTTP/1.1 header field values consist of words separated by LWS
2272 or special characters. These special characters MUST be in a quoted
2273 string to be used within a parameter value.
2278 Leach & Newman Expires: April 2006 [Page 38]
2284 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2287 token = 1*TOKENCHAR
2288 separators = "(" | ")" | "<" | ">" | "@"
2289 | "," | ";" | ":" | "\" | <">
2290 | "/" | "[" | "]" | "?" | "="
2291 | "{" | "}" | SP | HT
2292 TOKENCHAR = <any CHAR except CTLs or separators>
2294 A string of text is parsed as a single word if it is quoted using
2295 double-quote marks.
2297 quoted-string = ( <"> qdstr-val <"> )
2298 qdstr-val = *( qdtext | quoted-pair )
2299 qdtext = <any TEXTCHAR except <"> and "\">
2301 Note that LWS is NOT implicit between the double-quote marks (<">)
2302 surrounding a qdstr-val and the qdstr-val; any LWS will be considered
2303 part of the qdstr-val. This is also the case for quotation marks
2304 surrounding any other construct.
2306 The backslash character ("\") MAY be used as a single-character
2307 quoting mechanism only within qdstr-val and comment constructs.
2309 quoted-pair = "\" CHAR
2311 The value of this construct is CHAR. Note that an effect of this rule
2312 is that backslash itself MUST be quoted.
2338 Leach & Newman Expires: April 2006 [Page 39]
2344 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2347 8 Sample Code
2349 The sample implementation in [Digest] also applies to DIGEST-MD5.
2351 The following code implements the conversion from UTF-8 to 8859-1 if
2352 necessary.
2354 /* if the string is entirely in the 8859-1 subset of UTF-8, then
2355 * translate to 8859-1 prior to MD5
2356 */
2357 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
2358 int len)
2359 {
2360 const unsigned char *scan, *end;
2361 unsigned char cbuf;
2363 end = base + len;
2364 for (scan = base; scan < end; ++scan) {
2365 if (*scan > 0xC3) break; /* abort if outside 8859-1 */
2366 if (*scan >= 0xC0 && *scan <= 0xC3) {
2367 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
2368 break;
2369 }
2370 }
2371 /* if we found a character outside 8859-1, don't alter string
2372 */
2373 if (scan < end) {
2374 MD5Update(ctx, base, len);
2375 return;
2376 }
2378 /* convert to 8859-1 prior to applying hash
2379 */
2380 do {
2381 for (scan = base; scan < end && *scan < 0xC0; ++scan)
2382 ;
2383 if (scan != base) MD5Update(ctx, base, scan - base);
2384 if (scan + 1 >= end) break;
2385 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
2386 MD5Update(ctx, &cbuf, 1);
2387 base = scan + 2;
2388 } while (base < end);
2389 }
2398 Leach & Newman Expires: April 2006 [Page 40]
2404 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2407 9 Authors' Addresses
2409 Paul Leach
2410 Microsoft
2411 1 Microsoft Way
2412 Redmond, WA 98052, USA
2414 EMail: paulle@microsoft.com
2417 Chris Newman
2418 Sun Microsystems
2419 1050 Lakes Drive
2420 West Covina, CA 91790, USA
2422 EMail: Chris.Newman@Sun.COM
2425 Alexey Melnikov
2426 Isode Ltd.
2427 5 Castle Business Village,
2428 36 Station Road,
2429 Hampton,
2430 Middlesex,
2431 TW12 2BX,
2432 United Kingdom
2434 Email: Alexey.Melnikov@isode.com
2437 10 Acknowledgements
2439 The following people had substantial contributions to the development
2440 and/or refinement of this document:
2442 Lawrence Greenfield
2443 John Gardiner Myers
2444 Simon Josefsson
2445 RL Bob Morgan
2446 Jeff Hodges
2447 Claus Assmann
2448 Tony Hansen
2449 Ken Murchison
2450 Sam Hartman
2451 Kurt D. Zeilenga
2452 Hallvard B. Furuseth
2453 Abhijit Menon-Sen
2454 Tom Yu
2458 Leach & Newman Expires: April 2006 [Page 41]
2464 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 2005
2467 as well as other members of the SASL mailing list.
2469 The text used is section 3.8 was taken from [TLS-CBC] by Bodo
2470 Moeller.
2518 Leach & Newman Expires: April 2006 [Page 42]
2524 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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: April 2006 [Page 43]
2584 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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: April 2006 [Page 44]
2644 INTERNET DRAFT DIGEST-MD5 SASL Mechanism October 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.
2665 23). Changed nonce/cnonce to allow for channel bindings.
2667 24). Replace RFC 822 ABNF with [ABNF].
2668 (in progress)
2670 And other minor text clarifications.
2673 Appendix B: Open Issues/ToDo List
2675 1). Normative vs. Informative references must be carefully rechecked.
2677 2). Replace ABNF with the reference to RFC 2234bis?
2679 3). Resolve ISO-8859-1 and SASLPrep interaction issue as reported by
2680 Simon Josefsson.
2682 4). Can we drop ISO-8859-1 stuff in favor of UTF-8? This is what
2683 people have suggested for HTTP Digest.
2685 5). "SHOULD SASLprep" / "MUST fail authentication exchange" language
2686 should be checked for consistency. Also, should SASLPrep be
2687 applied BEFORE or AFTER checking for ISO-8859-1 subset? (I think
2688 it should be applied before)
2690 6). Pick a way to fix CBC mode attack.
2698 Leach & Newman Expires: April 2006 [Page 45]