| blob | 1a460d21a209ffdfa9ee861493170e07908fc205 |
2 INTERNET-DRAFT P. Leach
3 Obsoletes: 2831 Microsoft
4 Intended category: Standards track C. Newman
5 Sun Microsystems
6 A. Melnikov
7 Isode Ltd.
8 September 2004
10 Using Digest Authentication as a SASL Mechanism
11 draft-ietf-sasl-rfc2831bis-04.txt
13 Status of this Memo
15 By submitting this Internet-Draft, I certify that any applicable
16 patent or other IPR claims of which I am aware have been disclosed,
17 and any of which I become aware will be disclosed, in accordance with
18 RFC 3668.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that other
22 groups may also distribute working documents as Internet-Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 Copyright Notice
37 Copyright (C) The Internet Society (2004). All Rights Reserved.
39 Abstract
41 This specification defines how HTTP Digest Authentication [Digest]
42 can be used as a SASL [RFC 2222] mechanism for any protocol that has
43 a SASL profile. It is intended both as an improvement over CRAM-MD5
44 [RFC 2195] and as a convenient way to support a single authentication
45 mechanism for web, mail, LDAP, and other protocols.
53 Leach & Newman Expires: March 2005 [Page 1]
59 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
62 Table of Contents
64 1 INTRODUCTION.....................................................3
65 1.1 CONVENTIONS AND NOTATION......................................3
66 1.2 REQUIREMENTS..................................................4
67 2 AUTHENTICATION...................................................5
68 2.1 INITIAL AUTHENTICATION........................................5
69 2.1.1 Step One...................................................5
70 2.1.2 Step Two...................................................9
71 2.1.3 Step Three................................................16
72 2.2 SUBSEQUENT AUTHENTICATION....................................17
73 2.2.1 Step one..................................................17
74 2.2.2 Step Two..................................................17
75 2.3 INTEGRITY PROTECTION.........................................18
76 2.4 CONFIDENTIALITY PROTECTION...................................18
77 3 SECURITY CONSIDERATIONS.........................................21
78 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21
79 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21
80 3.3 REPLAY ATTACKS...............................................21
81 3.4 ONLINE DICTIONARY ATTACKS....................................22
82 3.5 OFFLINE DICTIONARY ATTACKS...................................22
83 3.6 MAN IN THE MIDDLE............................................22
84 3.7 CHOSEN PLAINTEXT ATTACKS.....................................22
85 3.8 CBC MODE ATTACKS.............................................
86 3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23
87 3.10 STORING PASSWORDS...........................................23
88 3.11 MULTIPLE REALMS.............................................24
89 3.12 SUMMARY.....................................................24
90 4 EXAMPLE.........................................................24
91 5 REFERENCES......................................................26
92 5.1 NORMATIVE REFERENCES.........................................26
93 5.2 INFORMATIVE REFERENCES.......................................27
94 6 AUTHORS' ADDRESSES..............................................28
95 7 ABNF............................................................29
96 7.1 AUGMENTED BNF................................................29
97 7.2 BASIC RULES..................................................31
98 8 SAMPLE CODE.....................................................33
99 10 ACKNOWLEDGEMENTS..............................................34
100 11 FULL COPYRIGHT STATEMENT.......................................35
101 Appendix A: Changes from 2831.....................................36
102 Appendix B: Open Issues...........................................37
113 Leach & Newman Expires: March 2005 [Page 2]
119 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
122 1 Introduction
124 This specification describes the use of HTTP Digest Access
125 Authentication as a SASL mechanism. The authentication type
126 associated with the Digest SASL mechanism is "DIGEST-MD5".
128 This specification is intended to be upward compatible with the
129 "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication
130 specified in [Digest]. The only difference in the "md5-sess"
131 algorithm is that some directives not needed in a SASL mechanism have
132 had their values defaulted.
134 There is one new feature for use as a SASL mechanism: integrity
135 protection on application protocol messages after an authentication
136 exchange.
138 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
139 attacks, and permits the use of third party authentication servers,
140 mutual authentication, and optimized reauthentication if a client has
141 recently authenticated to a server.
143 1.1 Conventions and Notation
145 This specification uses the same ABNF notation and lexical
146 conventions as HTTP/1.1 specification; see section 7.
148 Let { a, b, ... } be the concatenation of the octet strings a, b, ...
150 Let ** denote the power operation.
152 Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
154 Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string
155 k, a colon and the string s.
157 Let HEX(n) be the representation of the 16 octet MD5 hash n as a
158 string of 32 hex digits (with alphabetic characters always in lower
159 case, since MD5 is case sensitive).
161 Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet
162 string s using the octet string k as a key.
173 Leach & Newman Expires: March 2005 [Page 3]
179 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
182 Let unq(X) be the value of the quoted-string X without the
183 surrounding quotes and with all escape characters "\\" removed. For
184 example for the quoted-string "Babylon" the value of unq("Babylon")
185 is Babylon; for the quoted string "ABC\"123\\" the value of
186 unq("ABC\"123\\") is ABC"123\.
188 The value of a quoted string constant as an octet string does not
189 include any terminating null character.
191 <<"Protocol profile" is defined in RFC2222>>
193 1.2 Requirements
195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
197 document are to be interpreted as described in RFC 2119 [RFC 2119].
199 An implementation is not compliant if it fails to satisfy one or more
200 of the MUST level requirements for the protocols it implements. An
201 implementation that satisfies all the MUST level and all the SHOULD
202 level requirements for its protocols is said to be "unconditionally
203 compliant"; one that satisfies all the MUST level requirements but
204 not all the SHOULD level requirements for its protocols is said to be
205 "conditionally compliant."
233 Leach & Newman Expires: March 2005 [Page 4]
239 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
242 2 Authentication
244 DIGEST-MD5 can operate in two modes. Initial authentication (section
245 2.1) is usually used when a client authenticates to a server for the
246 first time. If protocol profile supports initial client response
247 (see "Protocol profile requirements" in [RFC 2222]) and the client
248 has successfully authenticated to the server before and the client
249 supports reauthentication (i.e. it has cached some values from a
250 previous authentication exchange, as described in 2.2), the client
251 can use fast reauthentication mode (section 2.2).
253 The following sections describe these two modes in details.
255 2.1 Initial Authentication
257 If the client has not recently authenticated to the server, then it
258 must perform "initial authentication", as defined in this section. If
259 it has recently authenticated, then a more efficient form is
260 available, defined in the next section.
262 2.1.1 Step One
264 The server starts by sending a challenge. The data encoded in the
265 challenge contains a string formatted according to the rules for a
266 "digest-challenge" defined as follows:
293 Leach & Newman Expires: March 2005 [Page 5]
299 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
302 digest-challenge =
303 1#( realm | nonce | qop-options | stale | server_maxbuf | charset
304 algorithm | cipher-opts | auth-param )
306 realm = "realm" "=" <"> realm-value <">
307 realm-value = qdstr-val
308 nonce = "nonce" "=" <"> nonce-value <">
309 nonce-value = *qdtext
310 qop-options = "qop" "=" <"> qop-list <">
311 qop-list = 1#qop-value
312 qop-value = "auth" | "auth-int" | "auth-conf" |
313 qop-token
314 ;; qop-token is reserved for identifying future
315 ;; extensions to DIGEST-MD5
316 qop-token = token
317 stale = "stale" "=" "true"
318 server_maxbuf = "maxbuf" "=" maxbuf-value
319 maxbuf-value = 1*DIGIT
320 charset = "charset" "=" "utf-8"
321 algorithm = "algorithm" "=" "md5-sess"
322 cipher-opts = "cipher" "=" <"> 1#cipher-value <">
323 cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
324 "rc4-56" | "aes-cbc" | cipher-token
325 ;; "des" and "3des" ciphers are obsolete.
326 ;; cipher-token is reserved for new ciphersuites
327 cipher-token = token
328 auth-param = token "=" ( token | quoted-string )
330 The meanings of the values of the directives used above are as
331 follows:
333 realm
334 Mechanistically, a string which can enable users to know which
335 username and password to use, in case they might have different
336 ones for different servers. Conceptually, it is the name of a
337 collection of accounts that might include the user's account. This
338 string should contain the name of the host performing the
339 authentication and might additionally indicate the collection of
340 users who might have access. An example might be
341 "registered_users@gotham.news.example.com". Note that the server
342 MAY not advertise some or all realms it supports.
344 Other examples:
346 1) "dc=gotham, dc=news, dc=example, dc=com".
348 2) If there are two servers (e.g. server1.example.com and
349 server2.example.com) that share authentication database, they
353 Leach & Newman Expires: March 2005 [Page 6]
359 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
362 both
363 may advertise "example.com" as the realm.
365 A server implementation that uses a fixed string as the advertised
366 realm is compliant with this specification, however this is not
367 recommended. See also sections 3.10 "Storing passwords" and 3.11
368 "Multiple realms" for discussion.
370 The value of this directive is case-sensitive. This directive is
371 optional; if not present, the client SHOULD solicit it from the
372 user or be able to compute a default; a plausible default might be
373 the realm supplied by the user when they logged in to the client
374 system. Multiple realm directives are allowed, in which case the
375 user or client must choose one as the realm for which to supply
376 username and password.
378 Requirements on UIs: UIs MUST allow users to enter arbitrary user
379 names and realm names. In order to achieve this, UIs MAY present
380 two separate edit boxes. Alternatively, UIs MAY present a single
381 edit box and allow user to enter a special character that
382 separates user name from the realm name. In the latter case, UIs
383 MUST be able to escape the special character and they need to
384 present their escape rules to the user. UIs MUST also present the
385 list of realms advertised by the server.
387 If at least one realm is present and the charset directive is also
388 specified (which means that realm(s) are encoded as UTF-8), the
389 client SHOULD prepare each instance of realm using the "SASLPrep"
390 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
391 preparation of a realm instance fails or results in an empty
392 string (unless the realm instance was the empty string), the
393 client SHOULD abort the authentication exchange.
395 Note, that if the client picks one of the realms provided by the
396 server, it MUST send it exactly as received from the server, even
397 if the prepared version of the realm differs from the received
398 version.
400 nonce
401 A server-specified data string which MUST be different each time a
402 digest-challenge is sent as part of initial authentication. It is
403 recommended that this string be base64 or hexadecimal data. Note
404 that the whole string is enclosed in double-quote characters,
405 however quote-characters or escape characters are not allowed in
406 the string, even when quoted. This is different from the RFC 2821.
407 The contents of the nonce are implementation dependent. The
408 security of the implementation depends on a good choice. It is
409 RECOMMENDED that it contain at least 64 bits of entropy. The nonce
413 Leach & Newman Expires: March 2005 [Page 7]
419 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
422 is opaque to the client. This directive is required and MUST
423 appear exactly once; if not present, or if multiple instances are
424 present, the client should abort the authentication exchange.
426 qop-options
427 A quoted string of one or more tokens indicating the "quality of
428 protection" values supported by the server. The value "auth"
429 indicates authentication; the value "auth-int" indicates
430 authentication with integrity protection; the value "auth-conf"
431 indicates authentication with integrity protection and encryption.
432 This directive is optional; if not present it defaults to "auth".
433 The client MUST ignore unrecognized options; if the client
434 recognizes no option, it MUST abort the authentication exchange.
436 <<What if this directive is present multiple times? Error, or take
437 the union of all values?>>
439 stale
440 The "stale" directive is not used in initial authentication. See
441 the next section for its use in subsequent authentications. This
442 directive may appear at most once; if multiple instances are
443 present, the client MUST abort the authentication exchange.
445 server_maxbuf ("maximal ciphertext buffer size")
446 A number indicating the size of the largest buffer (in bytes) the
447 server is able to receive when using "auth-int" or "auth-conf".
448 The value MUST be bigger than 16 (32 for Confidentiality
449 protection with the "aes-cbc" cipher) and smaller or equal to
450 16777215 (i.e. 2**24-1). If this directive is missing, the default
451 value is 65536. This directive may appear at most once; if
452 multiple instances are present, or the value is out of range the
453 client MUST abort the authentication exchange.
455 Let "maximal cleartext buffer size" (or "maximal sender size") be
456 the maximal size of a cleartext buffer that, after being
457 transformed by integrity (section 2.3) or confidentiality (section
458 2.4) protection function, will produce a SASL block of the maxbuf
459 size. As it should be clear from the name, the sender MUST never
460 pass a block of data bigger than the "maximal sender size" through
461 the selected protection function. This will guaranty that the
462 receiver will never get a block bigger than the maxbuf.
473 Leach & Newman Expires: March 2005 [Page 8]
479 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
482 charset
483 This directive, if present, specifies that the server supports
484 UTF-8 [UTF-8] encoding for the username, realm and password. If
485 present, the username, realm and password are in Unicode, prepared
486 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
487 algorithm [RFC 3454] and than encoded as UTF-8 [UTF-8]. If not
488 present, the username, realm and password used by the client in
489 Step 2 MUST be encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII
490 [USASCII] is a subset). The directive is needed for backwards
491 compatibility with HTTP Digest, which only supports ISO 8859-1.
492 This directive may appear at most once; if multiple instances are
493 present, the client MUST abort the authentication exchange.
495 Note, that this directive doesn't affect authorization id
496 ("authzid").
498 algorithm
499 This directive is required for backwards compatibility with HTTP
500 Digest, which supports other algorithms. This directive is
501 required and MUST appear exactly once; if not present, or if
502 multiple instances are present, the client SHOULD abort the
503 authentication exchange.
505 cipher-opts
506 A list of ciphers that the server supports. This directive must be
507 present exactly once if "auth-conf" is offered in the
508 "qop-options" directive, in which case the "rc4" cipher is
509 mandatory-to-implement. The client MUST ignore unrecognized
510 ciphers; if the client recognizes no cipher, it MUST behave as if
511 "auth-conf" qop option wasn't provided by the server. See section
512 2.4 for more detailed description of the ciphers.
514 rc4, rc4-40, rc4-56
515 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
516 respectively.
518 aes-cbc
519 the Advanced Encryption Standard (AES) cipher [AES] in cipher
520 block chaining (CBC) mode with a 128 bit key and explicit
521 Initialization Vector (IV). This mode requires an IV that has
522 the same size as the block size.
524 auth-param
525 This construct allows for future extensions; it may appear more
526 than once. The client MUST ignore any unrecognized directives.
528 For use as a SASL mechanism, note that the following changes are made
529 to "digest-challenge" from HTTP: the following Digest options (called
533 Leach & Newman Expires: March 2005 [Page 9]
539 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
542 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
543 and MUST be ignored if received):
545 opaque
546 domain
548 The size of a digest-challenge MUST be less than 2048 bytes.
550 2.1.2 Step Two
552 The client makes note of the "digest-challenge" and then responds
553 with a string formatted and computed according to the rules for a
554 "digest-response" defined as follows:
556 digest-response = 1#( username | realm | nonce | cnonce |
557 nonce-count | qop | digest-uri | response |
558 client_maxbuf | charset | cipher | authzid |
559 auth-param )
561 username = "username" "=" <"> username-value <">
562 username-value = qdstr-val
563 cnonce = "cnonce" "=" <"> cnonce-value <">
564 cnonce-value = *qdtext
565 nonce-count = "nc" "=" nc-value
566 nc-value = 8LHEX
567 client_maxbuf = "maxbuf" "=" maxbuf-value
568 qop = "qop" "=" qop-value
569 digest-uri = "digest-uri" "=" <"> digest-uri-value <">
570 digest-uri-value = serv-type "/" host [ "/" serv-name ]
571 serv-type = 1*ALPHA
572 serv-name = host
573 response = "response" "=" response-value
574 response-value = 32LHEX
575 LHEX = "0" | "1" | "2" | "3" |
576 "4" | "5" | "6" | "7" |
577 "8" | "9" | "a" | "b" |
578 "c" | "d" | "e" | "f"
579 cipher = "cipher" "=" cipher-value
580 authzid = "authzid" "=" <"> authzid-value <">
581 authzid-value = qdstr-val
583 The 'host' non-terminal is defined in [RFC 2732] as
585 host = hostname | IPv4address | IPv6reference
586 ipv6reference = "[" IPv6address "]"
588 where IPv6address and IPv4address are defined in [RFC 2373]
589 and 'hostname' is defined in [RFC 2396].
593 Leach & Newman Expires: March 2005 [Page 10]
599 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
602 username
603 The user's name in the specified realm, encoded according to the
604 value of the "charset" directive. This directive is required and
605 MUST be present exactly once; otherwise, authentication fails.
607 If the charset directive is also specified (which means that the
608 username is encoded as UTF-8) The client MUST first check if all
609 the characters of the username are in the ISO 8859-1 character
610 set. If they are, no further changes are performed. Otherwise, the
611 client MUST prepare the username using the "SASLPrep" profile
612 [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If the
613 preparation of the username fails or results in an empty string,
614 the client SHOULD abort the authentication exchange. If the
615 preparation succeeds, the prepared value will be sent to the
616 server.
618 Upon the receipt of this value and if the charset directive is
619 also specified (which means that the username is encoded as
620 UTF-8), the server MUST prepare the username using the "SASLPrep"
621 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
622 preparation of the username fails or results in an empty string,
623 the server MUST fail the authentication exchange.
625 realm
626 The realm containing the user's account, encoded according to the
627 value of the "charset" directive. This directive is required if
628 the server provided any realms in the
629 "digest-challenge", in which case it may appear exactly once and
630 its value SHOULD be one of those realms. If the directive is
631 missing, "realm-value" will set to the empty string when computing
632 A1 (see below for details).
634 If realm was provided by the client and if the charset directive
635 was also specified (which means that the realm is encoded as
636 UTF-8), the server MUST prepare the realm using the "SASLPrep"
637 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If
638 preparation of the realm fails or results in an empty string
639 (unless already the empty string), the server MUST fail the
640 authentication exchange.
642 <<The server has to do this only if the client has sent a realm,
643 that wasn't one of realms advertised by the server>>
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.
653 Leach & Newman Expires: March 2005 [Page 11]
659 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
662 cnonce
663 A client-specified data string which MUST be different each time a
664 digest-response is sent as part of initial authentication. The
665 cnonce-value is an opaque quoted string value provided by the
666 client and used by both client and server to avoid chosen
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, authentication fails.
688 qop
689 Indicates what "quality of protection" the client accepted. If
690 present, it may appear exactly once and its value MUST be one of
691 the alternatives in qop-options. If not present, it defaults to
692 "auth". These values affect the computation of the response. Note
693 that this is a single token, not a quoted list of alternatives.
695 serv-type
696 Indicates the type of service, such as "http" for web service,
697 "ftp" for FTP service, "smtp" for mail delivery service, etc. The
698 service name as defined in the SASL profile for the protocol see
699 section 4 of [RFC 2222], registered in the IANA registry of
700 "service" elements for the GSSAPI host-based service name form
701 [RFC 2078].
703 host
704 The DNS host name or IP (IPv4 or IPv6) address for the service
705 requested. The DNS host name must be the fully-qualified
706 canonical name of the host. The DNS host name is the preferred
707 form; see notes on server processing of the digest-uri.
713 Leach & Newman Expires: March 2005 [Page 12]
719 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
722 serv-name
723 Indicates the name of the service if it is replicated. The service
724 is considered to be replicated if the client's service-location
725 process involves resolution using standard DNS lookup operations,
726 and if these operations involve DNS records (such as SRV [RFC
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 client 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.
773 Leach & Newman Expires: March 2005 [Page 13]
779 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
782 response
783 A string of 32 hex digits computed as defined below, which proves
784 that the user knows a password. This directive is required and
785 MUST be present exactly once; otherwise, authentication fails.
787 client_maxbuf
788 A number indicating the size of the largest ciphertext buffer the
789 client is able to receive when using "auth-int" or "auth-conf". If
790 this directive is missing, the default value is 65536. This
791 directive may appear at most once; if multiple instances are
792 present, the server MUST abort the authentication exchange. If the
793 value is less or equal to 16 (<<32 for aes-cbc>>) 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 16 (<<32 for aes-cbc>>) from the calculated "maximal
802 ciphertext buffer size".
804 When sending a block of data the client/server MUST NOT pass more
805 than the "maximal sender size" bytes of data to the selected
806 protection function (2.3 or 2.4).
808 charset
809 This directive, if present, specifies that the client has used
810 UTF-8 [UTF-8] encoding for the username, realm and password. If
811 present, the username, realm and password are in Unicode, prepared
812 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
813 algorithm [RFC 3454] and than encoded as UTF-8 [UTF-8]. If not
814 present, the username and password must be encoded in ISO 8859-1
815 [ISO-8859] (of which
816 US-ASCII [USASCII] is a subset). The client should send this
817 directive only if the server has indicated it supports UTF-8
818 [UTF-8]. The directive is needed for backwards compatibility with
819 HTTP Digest, which only supports ISO 8859-1.
821 <<Need to explain, that SASLPrep on "realm" is ONLY performed when
822 the client selected a realm itself (the server hasn't provided
823 any). If the server has sent a list of realms and the client has
824 picked one of them, the client MUST NOT change the selected realm
825 (i.e. MUST NOT SASLPrep it).>>
827 Note, that this directive doesn't affect authorization id
828 ("authzid").
833 Leach & Newman Expires: March 2005 [Page 14]
839 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
842 LHEX
843 32 hex digits, where the alphabetic characters MUST be lower case,
844 because MD5 is not case insensitive.
846 cipher
847 The cipher chosen by the client. This directive MUST appear
848 exactly once if "auth-conf" is negotiated; if required and not
849 present, authentication fails.
851 authzid
852 The "authorization ID" directive is optional. If present, and the
853 authenticating user has sufficient privilege, and the server
854 supports it, then after authentication the server will use this
855 identity for making all accesses and access checks. If the client
856 specifies it, and the server does not support it, then the
857 response-value calculated on the server will not match the one
858 calculated on the client and authentication will fail.
860 The authzid MUST NOT be an empty string.
862 The authorization identifier MUST NOT be converted to ISO 8859-1
863 even if the authentication identifier ("username") is converted
864 for compatibility as directed by "charset" directive.
866 The server SHOULD verify the correctness of an authzid as
867 specified by the corresponding SASL protocol profile.
869 The size of a digest-response MUST be less than 4096 bytes.
871 2.1.2.1 Response-value
873 The definition of "response-value" above indicates the encoding for
874 its value -- 32 lower case hex characters. The following definitions
875 show how the value is computed.
877 Although qop-value and components of digest-uri-value may be
878 case-insensitive, the case which the client supplies in step two is
879 preserved for the purpose of computing and verifying the
880 response-value.
882 response-value =
883 HEX( KD ( HEX(H(A1)),
884 { nonce-value, ":" nc-value, ":",
885 cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
887 If authzid is specified, then A1 is
889 A1 = { SS, ":", nonce-value, ":", cnonce-value, ":", unq(authzid-value) }
893 Leach & Newman Expires: March 2005 [Page 15]
899 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
902 If authzid is not specified, then A1 is
904 A1 = { SS, ":", nonce-value, ":", cnonce-value }
906 where
908 passwd = *OCTET
910 SS = H( { unq(username-value), ":", unq(realm-value), ":", passwd } )
913 <<Note about empty authzid-value versa missing authzid-value and how
914 this affects hash>>
916 The "username-value", "realm-value" and "passwd" are encoded
917 according to the value of the "charset" directive. If "charset=UTF-8"
918 is present, and all the characters of "username-value" are, before
919 preparing using the "SASLPrep" profile [SASLPrep] of the "stringprep"
920 algorithm [RFC 3454], in the ISO 8859-1 character set, then it must
921 be converted to ISO 8859-1 before being hashed (and no SASLPrep is to
922 be done). Otherwise the SASLPrep MUST be performed. The same
923 transformation has to be done for "realm-value" (only if the "realm-
924 value" was obtained by the client). If the "realm-value" was picked
925 from a list of realms supported by the server, it MUST NOT be
926 prepared with SASLPrep) and "passwd". This is so that authentication
927 databases that store the hashed username, realm and password (which
928 is common) can be shared compatibly with HTTP, which specifies ISO
929 8859-1. A sample implementation of this conversion is in section 8.
931 If the "qop" directive's value is "auth", then A2 is:
933 A2 = { "AUTHENTICATE:", digest-uri-value }
953 Leach & Newman Expires: March 2005 [Page 16]
959 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
962 If the "qop" value is "auth-int" or "auth-conf" then A2 is:
964 A2 = { "AUTHENTICATE:", digest-uri-value,
965 ":00000000000000000000000000000000" }
967 Note that "AUTHENTICATE:" must be in upper case, and the second
968 string constant is a string with a colon followed by 32 zeros.
970 These apparently strange values of A2 are for compatibility with
971 HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
972 the hash of the entity body to zero in the HTTP digest calculation of
973 A2.
975 Also, in the HTTP usage of Digest, several directives in the
976 "digest-challenge" sent by the server have to be returned by the
977 client in the "digest-response". These are:
979 opaque
980 algorithm
982 These directives are not needed when Digest is used as a SASL
983 mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
985 2.1.3 Step Three
987 The server receives and validates the "digest-response". The server
988 checks that the nonce-count is "00000001". If it supports subsequent
989 authentication (see section 2.2), it saves the value of the nonce and
990 the nonce-count. It sends a message formatted as follows:
992 response-auth = "rspauth" "=" response-value
994 where response-value is calculated as above, using the values sent in
995 step two, except that if qop is "auth", then A2 is
997 A2 = { ":", digest-uri-value }
999 And if qop is "auth-int" or "auth-conf" then A2 is
1001 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
1003 Compared to its use in HTTP, the following Digest directives in the
1004 "digest-response" are unused:
1006 nextnonce
1007 qop
1008 cnonce
1009 nonce-count
1013 Leach & Newman Expires: March 2005 [Page 17]
1019 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1022 2.2 Subsequent Authentication
1024 If the client has previously authenticated to the server, and
1025 remembers the values of username, realm, nonce, nonce-count, cnonce,
1026 and qop that it used in that authentication, and the SASL profile for
1027 a protocol permits an initial client response, then it MAY perform
1028 "subsequent authentication" or "fast reauthentication", as defined in
1029 this section. Note, that a subsequent authentication can be done on
1030 a different connection, or on the same connection, if the protocol
1031 profile also permits multiple authentications.
1033 2.2.1 Step one
1035 The client uses the values from the previous authentication and sends
1036 an initial response with a string formatted and computed according to
1037 the rules for a "digest-response", as defined above, but with a
1038 nonce-count one greater than used in the last "digest-response".
1040 2.2.2 Step Two
1042 The server receives the "digest-response". If the server does not
1043 support subsequent authentication, then it sends a
1044 "digest-challenge", and authentication proceeds as in initial
1045 authentication. If the server has no saved nonce and nonce-count from
1046 a previous authentication, then it sends a "digest-challenge", and
1047 authentication proceeds as in initial authentication. Otherwise, the
1048 server validates the "digest-response", checks that the nonce-count
1049 is one greater than that used in the previous authentication using
1050 that nonce, and saves the new value of nonce-count.
1052 If the response is invalid, then the server sends a
1053 "digest-challenge", and authentication proceeds as in initial
1054 authentication (and should be configurable to log an authentication
1055 failure in some sort of security audit log, since the failure may be
1056 a symptom of an attack). The nonce-count MUST NOT be incremented in
1057 this case: to do so would allow a denial of service attack by sending
1058 an out-of-order nonce-count.
1060 If the response is valid, the server MAY choose to deem that
1061 authentication has succeeded. However, if it has been too long since
1062 the previous authentication, or for any other reason, the server MAY
1063 send a new "digest-challenge" with a new value for nonce. The
1064 challenge MAY contain a "stale" directive with value "true", which
1065 says that the client may respond to the challenge using the password
1066 it used in the previous response; otherwise, the client must solicit
1067 the password anew from the user. This permits the server to make sure
1068 that the user has presented their password recently. (The directive
1069 name refers to the previous nonce being stale, not to the last use of
1073 Leach & Newman Expires: March 2005 [Page 18]
1079 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1082 the password.) Except for the handling of "stale", after sending the
1083 "digest-challenge" authentication proceeds as in the case of initial
1084 authentication.
1086 2.3 Integrity Protection
1088 If the server offered "qop=auth-int" and the client responded
1089 "qop=auth-int", then subsequent messages, up to but not including the
1090 next subsequent authentication, between the client and the server
1091 MUST be integrity protected. Using as a base session key the value of
1092 H(A1), as defined above the client and server calculate a pair of
1093 message integrity keys as follows.
1095 The key for integrity protecting messages from client to server is:
1097 Kic = MD5({H(A1),
1098 "Digest session key to client-to-server signing key magic constant"})
1100 The key for integrity protecting messages from server to client is:
1102 Kis = MD5({H(A1),
1103 "Digest session key to server-to-client signing key magic constant"})
1105 where MD5 is as specified in [RFC 1321]. If message integrity is
1106 negotiated, a MAC block for each message is appended to the message.
1107 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
1108 2104] of the message, a 2-byte message type number in network byte
1109 order with value 1, and the 4-byte sequence number in network byte
1110 order. The message type is to allow for future extensions such as
1111 rekeying.
1113 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
1114 SeqNum)
1116 where Ki is Kic for messages sent by the client and Kis for those
1117 sent by the server. The sequence number (SeqNum) is an unsigned
1118 number initialized to zero after initial or subsequent
1119 authentication, and incremented by one for each message
1120 sent/successfully verified. (Note, that there are two independent
1121 counters for sending and receiving.) The sequence number wraps around
1122 to 0 after 2**32-1.
1124 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
1125 received value; the message is discarded if they differ and as the
1126 result the connection being used MUST be dropped. The receiver's
1127 sequence counter is incremented if they match.
1129 2.4 Confidentiality Protection
1133 Leach & Newman Expires: March 2005 [Page 19]
1139 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1142 If the server sent a "cipher-opts" directive and the client responded
1143 with a "cipher" directive, then subsequent messages between the
1144 client and the server MUST be confidentiality protected. Using as a
1145 base session key the value of H(A1) as defined above the client and
1146 server calculate a pair of message integrity keys as follows.
1148 The key for confidentiality protecting messages from client to server
1149 is:
1151 Kcc = MD5({H(A1)[0..n-1],
1152 "Digest H(A1) to client-to-server sealing key magic constant"})
1154 The key for confidentiality protecting messages from server to client
1155 is:
1157 Kcs = MD5({H(A1)[0..n-1],
1158 "Digest H(A1) to server-to-client sealing key magic constant"})
1160 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
1161 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*"
1162 and "aes-cbc" ciphers is all 16 bytes of Kcc or Kcs.
1164 "aes-cbc" cipher works as described in section 2.4.1.
1166 rc4 cipher state MUST NOT be reset before sending/receiving a next
1167 buffer of protected data.
1170 If the blocksize of the chosen cipher is not 1 byte, the padding
1171 prefix is one or more octets each containing the number of padding
1172 bytes, such that the total length of the encrypted part of the
1173 message is a multiple of the blocksize.
1175 The MAC block is 16 bytes formatted as follows: the first 10 bytes of
1176 the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number
1177 in network byte order with value 1, and the 4-byte sequence number in
1178 network byte order.
1180 <<Proposal 1 ("explicit IV in each SASL block") is detailed below>>
1182 The padding and first 10 bytes of the MAC block are encrypted with
1183 the chosen cipher along with the message and explicit IV (if
1184 present).
1186 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {exp_iv, msg, pad, MAC})
1188 MAC(Ki, SeqNum, exp_iv, msg) = {HMAC(Ki, {SeqNum, exp_iv, msg})[0..9],
1189 packet_type_data, SeqNum}
1193 Leach & Newman Expires: March 2005 [Page 20]
1199 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1202 packet_type_data = 0x0001
1204 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
1205 messages sent by the client and Kis and Kcs for those sent by the
1206 server, exp_iv is empty string for rc4 ciphers and a randomly
1207 generated number R of the length 128 bit for the "aes-cbc" cipher.
1208 The sequence number (SeqNum) is an unsigned number initialized to
1209 zero after initial or subsequent authentication, and incremented by
1210 one for each message sent/successfully verified. (Note, that there
1211 are two independent counters for sending and receiving.) The sequence
1212 number wraps around to 0 after 2**32-1.
1214 Upon receipt, the message is decrypted, exp_iv is ignored (for the
1215 "aes-cbc" cipher only), HMAC(Ki, {SeqNum, msg}) is computed and
1216 compared with the received value; the padding and the packet type are
1217 verified. The message is discarded if the received and the
1218 calculated HMACs differ and/or the padding is invalid. See also
1219 section 3.8 for important information about MAC and padding
1220 verification. The receiver's sequence counter is then compared with
1221 the received SeqNum value; the message is discarded if they differ
1222 and, as the result, the connection being used MUST be dropped. The
1223 receiver's sequence counter is incremented if they match.
1226 <<Proposal 2 ("explicit IV in a separate SASL block") is detailed
1227 below:
1229 Instead of sending a single SASL block that contains encrypted
1230 (128bit of entropy, followed by cleartext), we can introduce a new
1231 block type, that will only contain the entropy. Clients that have
1232 limited CPU resources (or operate on a slow link) might choose to
1233 send these special blocks not for every block of encrypted data, but
1234 for every second (third, ...) block.
1236 So, instead of sending a single block SEAL(Ki, Kc, SeqNum, msg)
1237 described aboves there are two types of blocks:
1239 the first is a data block as in revision 02:
1240 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {msg, pad2, MAC})
1241 MAC(Ki, SeqNum, msg) = {HMAC(Ki, {SeqNum, msg})[0..9], packet_type_data, SeqNum}
1242 packet_type_data = 0x0001
1244 the second block type has a different type and contains encrypted IV:
1246 SEAL_IV(Ki, Kc, SeqNum) = CIPHER(Kc, {exp_iv, pad1, MAC_IV})
1247 MAC_IV(Ki, SeqNum, exp_iv) = {HMAC(Ki, {SeqNum, exp_iv})[0..9], packet_type_iv,
1248 SeqNum}
1249 packet_type_iv = 0x0002
1253 Leach & Newman Expires: March 2005 [Page 21]
1259 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1262 The second block is also protected by MAC that includes SeqNum. So,
1263 removing/replacing it will invalidate subsequent blocks.
1265 Advantages of this approach: 1) Less intrusive changes to already
1266 deployed code. Adding new block type might be easier. Also, the
1267 minimal block size is always 16 (with the proposal #1 it is either 16
1268 or 32). 2) Clients that want to sacrifice a bit of security in order
1269 to achieve faster performance can choose to send SEAL_IV blocks less
1270 frequently.
1272 Of course I am not a cryptographer, to judge if there are any issues
1273 with the alternative proposal.>>
1276 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 1]
1278 Unlike previous versions of DIGEST-MD5, this document uses an
1279 explicit IV for ciphers in CBC mode. This is done in order to prevent
1280 the attacks described by [CBCATT].
1282 For each buffer of cleartext data to be encrypted the sender performs
1283 the following procedure:
1285 0) For the very first SASL packet sent the IV is calculated as
1286 follows:
1288 The IV for the first SASL packet going from the client
1289 to the server (IVc) consists of 16 bytes calculated as follows:
1291 IVc = MD5({Kcc, "aes-128"})
1293 The IV for the first SASL packet going from the server
1294 to the client (IVs) consists of 16 bytes calculated as follows:
1296 IVs = MD5({Kcs, "aes-128"})
1298 For a subsequent packet: Em of the previous packet (see below)
1299 becomes the IV.
1301 1) Generate a cryptographically strong random number R of length 128
1302 bits (16 octets) and prepend it to the plaintext prior to
1303 encryption.
1305 2) padding and MAC block are constructed (see section 2.4) and
1306 appended to the end of the plaintext. After this step the data
1307 to be encrypted will look like:
1309 {R, msg, pad, MAC}
1313 Leach & Newman Expires: March 2005 [Page 22]
1319 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1322 As the total length of the data will be multiple of AES block size
1323 (i.e. 128 bit), this can also be represented as
1325 {P1, P2, P3, ..., Pm}
1327 where Pi is a chunk of data of the length 128 bit. Note, that
1328 P1 is R.
1330 3) Data is encrypted as follows:
1332 E1 = CIPHER ( Kc, P1 XOR IV )
1333 E2 = CIPHER ( Kc, P2 XOR E1 )
1334 E3 = CIPHER ( Kc, P3 XOR E2 )
1335 ...
1336 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1337 ...
1338 Em = CIPHER ( Kc, Pm XOR Em-1)
1340 This will generate ciphertext {E1, ..., Em} to be sent as a single
1341 SASL packet.
1344 The receiver performs the following steps:
1346 0) For the very first SASL packet sent the IV is calculated as
1347 in step 0 for the sender.
1349 For a subsequent packet: Em of the previous packet becomes
1350 the IV of the immediately following packet.
1352 1) Data is decrypted as follows:
1354 P1 = CIPHER ( Kc, E1 ) XOR IV
1355 P2 = CIPHER ( Kc, E2 ) XOR E1
1356 P3 = CIPHER ( Kc, E3 ) XOR E2
1357 ...
1358 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1359 ...
1360 Pm = CIPHER ( Kc, Em ) XOR Em-1
1362 Em becomes the IV for the decryption of the subsequent SASL
1363 packet.
1365 This will generate plaintext {P1, ..., Pm}. P1 is discarded,
1366 {P2, ..., Pm} is {msg, pad, MAC}.
1368 2) pad and MAC block are verified as described in section 2.4.
1373 Leach & Newman Expires: March 2005 [Page 23]
1379 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1382 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 2]
1384 Unlike previous versions of DIGEST-MD5, this document uses an
1385 explicit IV for ciphers in CBC mode. This is done in order to prevent
1386 the attacks described by [CBCATT].
1388 For each buffer of cleartext data to be encrypted the sender performs
1389 the following procedure:
1391 0) For the very first SASL packet sent the IV is calculated as
1392 follows:
1394 The IV for the first SASL packet going from the client
1395 to the server (IVc) consists of 16 bytes calculated as follows:
1397 IVc = MD5({Kcc, "aes-128"})
1399 The IV for the first SASL packet going from the server
1400 to the client (IVs) consists of 16 bytes calculated as follows:
1402 IVs = MD5({Kcs, "aes-128"})
1404 For a subsequent packet: Em of the previous packet (see below)
1405 becomes the IV.
1407 1) padding and MAC block are constructed (see section 2.4) and
1408 appended to the end of the plaintext. After this step the data
1409 to be encrypted will look like:
1411 {msg, pad, MAC}
1413 As the total length of the data will be multiple of AES block size
1414 (i.e. 128 bit), this can also be represented as
1416 {P1, P2, P3, ..., Pm}
1418 where Pi is a chunk of data of the length 128 bit.
1420 2) Data is encrypted as follows:
1422 E1 = CIPHER ( Kc, P1 XOR IV )
1423 E2 = CIPHER ( Kc, P2 XOR E1 )
1424 E3 = CIPHER ( Kc, P3 XOR E2 )
1425 ...
1426 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1427 ...
1428 Em = CIPHER ( Kc, Pm XOR Em-1)
1433 Leach & Newman Expires: March 2005 [Page 24]
1439 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1442 This will generate ciphertext {E1, ..., Em} to be sent as a single
1443 SASL packet.
1446 In order to mitigate the attacks described in [CBCATT] the sender
1447 should periodically send a new SASL packet that affects IV. This
1448 packet is constructed as follows:
1450 1) Generate a cryptographically strong random number R of length 128
1451 bits (16 octets) and prepend it to the plaintext prior to
1452 encryption.
1454 2) padding and MAC block are constructed (see section 2.4) and
1455 appended after R. After this step the data
1456 to be encrypted will look like:
1458 {R, pad, MAC_IV}
1460 As the total length of the data will be multiple of AES block size
1461 (i.e. 128 bit), this can also be represented as
1463 {P1, P2, P3, ..., Pm}
1465 where Pi is a chunk of data of the length 128 bit.
1467 3) Data is encrypted as follows (this is exactly the same procedure
1468 as for
1469 a data packets described above):
1471 E1 = CIPHER ( Kc, P1 XOR IV )
1472 E2 = CIPHER ( Kc, P2 XOR E1 )
1473 E3 = CIPHER ( Kc, P3 XOR E2 )
1474 ...
1475 Ei = CIPHER ( Kc, Pi XOR Ei-1)
1476 ...
1477 Em = CIPHER ( Kc, Pm XOR Em-1)
1479 This will generate ciphertext {E1, ..., Em} to be sent as a single
1480 SASL packet.
1482 The receiver performs the following steps:
1484 0) For the very first SASL packet sent the IV is calculated as
1485 in step 0 for the sender.
1487 For a subsequent packet: Em of the previous packet becomes
1488 the IV of the immediately following packet.
1493 Leach & Newman Expires: March 2005 [Page 25]
1499 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1502 1) Data is decrypted as follows:
1504 P1 = CIPHER ( Kc, E1 ) XOR IV
1505 P2 = CIPHER ( Kc, E2 ) XOR E1
1506 P3 = CIPHER ( Kc, E3 ) XOR E2
1507 ...
1508 Pi = CIPHER ( Kc, Ei ) XOR Ei-1
1509 ...
1510 Pm = CIPHER ( Kc, Em ) XOR Em-1
1512 Em becomes the IV for the decryption of the subsequent SASL
1513 packet.
1515 This will generate plaintext {P1, ..., Pm} or {msgX, pad, MACX}.
1517 Packet type is extracted from MACX. If the packet type is 0x0001,
1518 the plaintext represents a data block with padding and MAC.
1519 If the packet type is 0x0002, the packet contains a random value
1520 R which affects IV followed by padding and MAC_IV. The random
1521 value
1522 R is ignored by the receiver.
1524 2) For both pad and MAC block are verified as described in section
1525 2.4.
1553 Leach & Newman Expires: March 2005 [Page 26]
1559 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1562 3 Security Considerations
1564 General SASL security considerations apply to this mechanism.
1565 "stringprep" and Unicode security considerations also apply.
1567 Detailed discussion of other DIGEST-MD5 specific security issues is
1568 below.
1570 3.1 Authentication of Clients using Digest Authentication
1572 Digest Authentication does not provide a strong authentication
1573 mechanism, when compared to public key based mechanisms, for example.
1574 However, since it prevents chosen plaintext attacks, it is stronger
1575 than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC
1576 2244], POP and IMAP [RFC 2195]. It is intended to replace the much
1577 weaker and even more dangerous use of plaintext passwords; however,
1578 since it is still a password based mechanism it avoids some of the
1579 potential deployabilty issues with public-key, OTP or similar
1580 mechanisms.
1582 Digest Authentication offers no confidentiality protection beyond
1583 protecting the actual password. All of the rest of the challenge and
1584 response are available to an eavesdropper, including the user's name
1585 and authentication realm.
1587 3.2 Comparison of Digest with Plaintext Passwords
1589 The greatest threat to the type of transactions for which these
1590 protocols are used is network snooping. This kind of transaction
1591 might involve, for example, online access to a mail service whose use
1592 is restricted to paying subscribers. With plaintext password
1593 authentication an eavesdropper can obtain the password of the user.
1594 This not only permits him to access anything in the database, but,
1595 often worse, will permit access to anything else the user protects
1596 with the same password.
1598 3.3 Replay Attacks
1600 Replay attacks are defeated if the client or the server chooses a
1601 fresh nonce for each authentication, as this specification requires.
1603 As a security precaution, the server, when verifying a response from
1604 the client, must use the original server nonce ("nonce") it sent, not
1605 the one returned by the client in the response, as it might have been
1606 modified by an attacker.
1608 To prevent some redirection attacks it is recommended that the server
1609 verifies that the "serv-type" part of the "digest-uri" matches the
1613 Leach & Newman Expires: March 2005 [Page 27]
1619 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1622 service name and that the hostname/IP address belongs to the server.
1624 3.4 Online dictionary attacks
1626 If the attacker can eavesdrop, then it can test any overheard
1627 nonce/response pairs against a (potentially very large) list of
1628 common words. Such a list is usually much smaller than the total
1629 number of possible passwords. The cost of computing the response for
1630 each password on the list is paid once for each challenge.
1632 The server can mitigate this attack by not allowing users to select
1633 passwords that are in a dictionary.
1635 3.5 Offline dictionary attacks
1637 If the attacker can choose the challenge, then it can precompute the
1638 possible responses to that challenge for a list of common words. Such
1639 a list is usually much smaller than the total number of possible
1640 passwords. The cost of computing the response for each password on
1641 the list is paid just once.
1643 Offline dictionary attacks are defeated if the client chooses a fresh
1644 nonce for each authentication, as this specification requires.
1646 3.6 Man in the Middle
1648 Digest authentication is vulnerable to "man in the middle" (MITM)
1649 attacks. Clearly, a MITM would present all the problems of
1650 eavesdropping. But it also offers some additional opportunities to
1651 the attacker.
1653 A possible man-in-the-middle attack would be to substitute a weaker
1654 qop scheme for the one(s) sent by the server; the server will not be
1655 able to detect this attack. For this reason, the client should always
1656 use the strongest scheme that it understands from the choices
1657 offered, and should never choose a scheme that does not meet its
1658 minimum requirements.
1660 A man-in-the-middle attack may also make the client and the server
1661 that agreed to use confidentiality protection to use different (and
1662 possibly weaker) cipher's. This is because the chosen cipher is not
1663 used in the shared secret calculation.
1665 3.7 Chosen plaintext attacks
1667 A chosen plaintext attack is where a MITM or a malicious server can
1668 arbitrarily choose the challenge that the client will use to compute
1669 the response. The ability to choose the challenge is known to make
1673 Leach & Newman Expires: March 2005 [Page 28]
1679 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1682 cryptanalysis much easier [MD5].
1684 However, Digest does not permit the attack to choose the challenge as
1685 long as the client chooses a fresh nonce for each authentication, as
1686 this specification requires.
1688 3.8 CBC Mode attacks
1690 The following attack can be launched when the connection uses
1691 Confidentiality protection with ciphers in CBC mode. If bad padding
1692 is treated differently from bad MACs when decrypting a DIGEST-MD5
1693 buffer of protected data, the attacker may be able to launch
1694 Vaudenay's attack on padding.
1696 An error logfile will suffice to launch the attack if it reveals the
1697 type of error -- even if file permissions prevent the attacker from
1698 actually reading the file (the file length increase cause by the
1699 attack is likely to reveal which of the two errors occured).
1701 A different approach to distinguish these two error cases and launch
1702 the attack is to examine the timing of error responses: if the MAC
1703 verification is skipped when bad padding has been found, the error
1704 will appear quicker in the case of incorrect block cipher padding
1705 than in the case of an incorrect MAC.
1707 A countermeasure is to compute a MAC of the plaintext anyway, even if
1708 the usual padding removal step fails because of incorrect padding, to
1709 obtain (nearly) uniform timing.
1711 3.9 Spoofing by Counterfeit Servers
1713 If a user can be led to believe that she is connecting to a host
1714 containing information protected by a password she knows, when in
1715 fact she is connecting to a hostile server, then the hostile server
1716 can obtain challenge/response pairs where it was able to partly
1717 choose the challenge. There is no known way that this can be
1718 exploited.
1720 3.10 Storing passwords
1722 Digest authentication requires that the authenticating agent (usually
1723 the server) store some data derived from the user's name and password
1724 in a "password file" associated with a given realm. Normally this
1725 might contain pairs consisting of username and H({ username-value,
1726 ":", realm-value, ":", passwd }), which is adequate to compute H(A1)
1727 as described above without directly exposing the user's password.
1729 The security implications of this are that if this password file is
1733 Leach & Newman Expires: March 2005 [Page 29]
1739 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1742 compromised, then an attacker gains immediate access to documents on
1743 the server using this realm. Unlike, say a standard UNIX password
1744 file, this information need not be decrypted in order to access
1745 documents in the server realm associated with this file. On the other
1746 hand, decryption, or more likely a brute force attack, would be
1747 necessary to obtain the user's password. This is the reason that the
1748 realm is part of the digested data stored in the password file. It
1749 means that if one Digest authentication password file is compromised,
1750 it does not automatically compromise others with the same username
1751 and password (though it does expose them to brute force attack).
1753 There are two important security consequences of this. First the
1754 password file must be protected as if it contained plaintext
1755 passwords, because for the purpose of accessing documents in its
1756 realm, it effectively does.
1758 A second consequence of this is that the realm string should be
1759 unique among all realms that any single user is likely to use. In
1760 particular a realm string should include the name of the host doing
1761 the authentication.
1793 Leach & Newman Expires: March 2005 [Page 30]
1799 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1802 3.11 Multiple realms
1804 Use of multiple realms may mean both that compromise of a the
1805 security database for a single realm does not compromise all
1806 security, and that there are more things to protect in order to keep
1807 the whole system secure.
1809 3.11 Summary
1811 By modern cryptographic standards Digest Authentication is weak,
1812 compared to (say) public key based mechanisms. But for a large range
1813 of purposes it is valuable as a replacement for plaintext passwords.
1814 Its strength may vary depending on the implementation.
1817 4 Example
1819 This example shows the use of the Digest SASL mechanism with the
1820 IMAP4 AUTHENTICATE command [RFC 3501].
1822 In this example, "C:" and "S:" represent a line sent by the client or
1823 server respectively including a CRLF at the end. Linebreaks and
1824 indentation within a "C:" or "S:" are editorial and not part of the
1825 protocol. The password in this example was "secret". Note that the
1826 base64 encoding of the challenges and responses is part of the IMAP4
1827 AUTHENTICATE command, not part of the Digest specification itself.
1829 S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
1830 C: c CAPABILITY
1831 S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
1832 UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
1833 S: c OK Completed
1834 C: a AUTHENTICATE DIGEST-MD5
1835 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
1836 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
1837 cnNldD11dGYtOA==
1838 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
1839 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
1840 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
1841 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
1842 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
1843 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
1844 C:
1845 S: a OK User logged in
1846 ---
1848 The base64-decoded version of the SASL exchange is:
1853 Leach & Newman Expires: March 2005 [Page 31]
1859 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1862 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
1863 algorithm=md5-sess,charset=utf-8
1864 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1865 nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
1866 digest-uri="imap/elwood.innosoft.com",
1867 response=d388dad90d4bbd760a152321f2143af7,qop=auth
1868 S: rspauth=ea40f60335c427b5527b84dbabcdfffd
1870 The password in this example was "secret".
1872 This example shows the use of the Digest SASL mechanism with the
1873 ACAP, using the same notational conventions and password as in the
1874 previous example. Note that ACAP does not base64 encode and uses
1875 fewer round trips that IMAP4.
1877 S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
1878 "DIGEST-MD5" "PLAIN")
1879 C: a AUTHENTICATE "DIGEST-MD5"
1880 S: + {94}
1881 S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
1882 algorithm=md5-sess,charset=utf-8
1883 C: {206}
1884 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1885 nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
1886 digest-uri="acap/elwood.innosoft.com",
1887 response=6084c6db3fede7352c551284490fd0fc,qop=auth
1888 S: a OK (SASL {40}
1889 S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
1890 Completed"
1891 ---
1893 The server uses the values of all the directives, plus knowledge of
1894 the users password (or the hash of the user's name, server's realm
1895 and the user's password) to verify the computations above. If they
1896 check, then the user has authenticated.
1913 Leach & Newman Expires: March 2005 [Page 32]
1919 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1922 5 References
1924 5.1 Normative references
1926 [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
1927 Access Authentication", RFC 2617, June 1999.
1929 [ISO-8859] ISO-8859. International Standard--Information Processing--
1930 8-bit Single-Byte Coded Graphic Character Sets --
1931 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
1932 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
1933 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
1934 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
1935 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
1936 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
1937 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
1938 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
1939 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
1941 [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
1942 Text Messages," STD 11, RFC 822, August 1982.
1944 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1945 April 1992.
1947 [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1948 location of services (DNS SRV)", RFC 2052, October 1996.
1950 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1951 Hashing for Message Authentication", RFC 2104, February
1952 1997.
1954 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1955 Requirement Levels", BCP 14, RFC 2119, March 1997.
1957 [RFC 2222] Melnikov, A. (editor), "Simple Authentication and Security
1958 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work
1959 in progress.
1961 [RFC 3454] Hoffman, P., Blanchet, M., "Preparation of
1962 Internationalized Strings ("stringprep")", RFC 3454,
1963 December 2002.
1965 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1966 3.2.0", defined by: The Unicode Standard, Version 3.0
1967 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
1968 as amended by the Unicode Standard Annex #28: Unicode 3.2
1969 (http://www.unicode.org/reports/tr28/tr28-3.html).
1973 Leach & Newman Expires: March 2005 [Page 33]
1979 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
1982 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646",
1983 RFC 2279, Janyary 1998.
1985 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
1986 Code for Information Interchange. Standard ANSI X3.4-1986,
1987 ANSI, 1986.
1989 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1990 and passwords", Work in progress, draft-ietf-sasl-
1991 saslprep-XX.txt.
1993 [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
1994 Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
1996 <<We can't use RFC 3513, as ABNF productions got removed!>> [RFC
1997 2373] Hinden, R., Deering, S., "IP Version 6 Addressing
1998 Architecture", RFC 2373, July 1998.
2000 [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
2001 Resource Identifiers (URI): Generic Syntax", RFC 2396,
2002 August 1998.
2004 [FIPS] National Institute of Standards and Technology, "DES Modes
2005 of Operation", http://www.itl.nist.gov/fipspubs/fip81.htm,
2006 December 1980.
2008 [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",
2009 http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf,
2010 3rd September 1999.
2013 5.2 Informative references
2015 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
2016 AUTHorize Extension for Simple Challenge/Response", RFC
2017 2195, September 1997.
2019 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with
2020 MD5", CryptoBytes, Sping 1995, RSA Inc,
2021 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
2023 [RFC 2078] Linn, J., "Generic Security Service Application Program
2024 Interface, Version 2", RFC 2078, January 1997.
2026 [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version
2027 4rev1", RFC 3501, March 2003.
2029 [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
2033 Leach & Newman Expires: March 2005 [Page 34]
2039 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2042 Access Protocol", RFC 2244, November 1997.
2044 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2045 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext
2046 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2048 [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
2049 Problems and Countermeasures",
2050 http://www.openssl.org/~bodo/tls-cbc.txt.
2052 [CBCATT] Canvel, B., "Password Interception in a SSL/TLS Channel",
2053 published 2003-02-20:
2054 http://lasecwww.epfl.ch/memo_ssl.shtml
2093 Leach & Newman Expires: March 2005 [Page 35]
2099 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2102 6 Authors' Addresses
2104 Paul Leach
2105 Microsoft
2106 1 Microsoft Way
2107 Redmond, WA 98052, USA
2109 EMail: paulle@microsoft.com
2112 Chris Newman
2113 Sun Microsystems
2114 1050 Lakes Drive
2115 West Covina, CA 91790, USA
2117 EMail: Chris.Newman@Sun.COM
2120 Alexey Melnikov
2121 Isode Ltd.
2122 5 Castle Business Village,
2123 36 Station Road,
2124 Hampton,
2125 Middlesex,
2126 TW12 2BX,
2127 United Kingdom
2129 Email: Alexey.Melnikov@isode.com
2153 Leach & Newman Expires: March 2005 [Page 36]
2159 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2162 7 ABNF
2164 What follows is the definition of the notation as is used in the
2165 HTTP/1.1 specification [RFC 2616] and the HTTP authentication
2166 specification [Digest]; it is reproduced here for ease of reference.
2167 Since it is intended that a single Digest implementation can support
2168 both HTTP and SASL-based protocols, the same notation is used in both
2169 to facilitate comparison and prevention of unwanted differences.
2170 Since it is cut-and-paste from the HTTP specifications, not all
2171 productions may be used in this specification. It is also not quite
2172 legal ABNF; again, the errors were copied from the HTTP
2173 specifications.
2175 7.1 Augmented BNF
2177 All of the mechanisms specified in this document are described in
2178 both prose and an augmented Backus-Naur Form (BNF) similar to that
2179 used by RFC 822 [RFC 822]. Implementers will need to be familiar with
2180 the notation in order to understand this specification.
2182 The augmented BNF includes the following constructs:
2184 name = definition
2185 The name of a rule is simply the name itself (without any
2186 enclosing "<" and ">") and is separated from its definition by the
2187 equal "=" character. White space is only significant in that
2188 indentation of continuation lines is used to indicate a rule
2189 definition that spans more than one line. Certain basic rules are
2190 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
2191 brackets are used within definitions whenever their presence will
2192 facilitate discerning the use of rule names.
2194 "literal"
2195 Quotation marks surround literal text. Unless stated otherwise,
2196 the text is case-insensitive.
2198 rule1 | rule2
2199 Elements separated by a bar ("|") are alternatives, e.g., "yes |
2200 no" will accept yes or no.
2202 (rule1 rule2)
2203 Elements enclosed in parentheses are treated as a single element.
2204 Thus, "(elem (foo | bar) elem)" allows the token sequences
2205 "elem foo elem" and "elem bar elem".
2207 *rule
2208 The character "*" preceding an element indicates repetition. The
2209 full form is "<n>*<m>element" indicating at least <n> and at most
2213 Leach & Newman Expires: March 2005 [Page 37]
2219 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2222 <m> occurrences of element. Default values are 0 and infinity so
2223 that "*(element)" allows any number, including zero; "1*element"
2224 requires at least one; and "1*2element" allows one or two.
2226 [rule]
2227 Square brackets enclose optional elements; "[foo bar]" is
2228 equivalent to "*1(foo bar)".
2230 N rule
2231 Specific repetition: "<n>(element)" is equivalent to
2232 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
2233 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
2234 alphabetic characters.
2236 #rule
2237 A construct "#" is defined, similar to "*", for defining lists of
2238 elements. The full form is "<n>#<m>element" indicating at least
2239 <n> and at most <m> elements, each separated by one or more commas
2240 (",") and OPTIONAL linear white space (LWS). This makes the usual
2241 form of lists very easy; a rule such as
2242 ( *LWS element *( *LWS "," *LWS element ) *LWS )
2243 can be shown as
2244 1#element
2245 Wherever this construct is used, null elements are allowed, but do
2246 not contribute to the count of elements present. That is,
2247 "(element), , (element) " is permitted, but counts as only two
2248 elements. Therefore, where at least one element is required, at
2249 least one non-null element MUST be present. Default values are 0
2250 and infinity so that "#element" allows any number, including zero;
2251 "1#element" requires at least one; and "1#2element" allows one or
2252 two.
2254 ; comment
2255 A semi-colon, set off some distance to the right of rule text,
2256 starts a comment that continues to the end of line. This is a
2257 simple way of including useful notes in parallel with the
2258 specifications.
2260 implied *LWS
2261 The grammar described by this specification is word-based. Except
2262 where noted otherwise, linear white space (LWS) can be included
2263 between any two adjacent words (token or quoted-string), and
2264 between adjacent words and separators, without changing the
2265 interpretation of a field. At least one delimiter (LWS and/or
2266 separators) MUST exist between any two tokens (for the definition
2267 of "token" below), since they would otherwise be interpreted as a
2268 single token.
2273 Leach & Newman Expires: March 2005 [Page 38]
2279 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2282 7.2 Basic Rules
2284 The following rules are used throughout this specification to
2285 describe basic parsing constructs. The US-ASCII coded character set
2286 is defined by ANSI X3.4-1986 [USASCII].
2288 OCTET = <any 8-bit character>
2289 CHAR = <any US-ASCII character (octets 0 - 127)>
2290 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
2291 LOALPHA = <any US-ASCII lowercase letter "a".."z">
2292 ALPHA = UPALPHA | LOALPHA
2293 DIGIT = <any US-ASCII digit "0".."9">
2294 CTL = <any US-ASCII control character
2295 (octets 0 - 31) and DEL (127)>
2296 CR = <US-ASCII CR, carriage return (13)>
2297 LF = <US-ASCII LF, linefeed (10)>
2298 SP = <US-ASCII SP, space (32)>
2299 HT = <US-ASCII HT, horizontal-tab (9)>
2300 <"> = <US-ASCII double-quote mark (34)>
2301 TEXTCHAR = <any OCTET except CTLs, but including HT>
2302 CRLF = CR LF
2304 All linear white space, including folding, has the same semantics as
2305 SP. A recipient MAY replace any linear white space with a single SP
2306 before interpreting the field value or forwarding the message
2307 downstream.
2309 LWS = [CRLF] 1*( SP | HT )
2311 The TEXT rule is only used for descriptive field contents and values
2312 that are not intended to be interpreted by the message parser. Words
2313 of TEXT contains characters either from ISO-8859-1 [ISO-8859]
2314 character set or UTF-8 [UTF-8].
2316 TEXT = <any *OCTET except CTLs,
2317 but including LWS>
2319 A CRLF is allowed in the definition of TEXT only as part of a header
2320 field continuation. It is expected that the folding LWS will be
2321 replaced with a single SP before interpretation of the TEXT value.
2323 Hexadecimal numeric characters are used in several protocol elements.
2325 HEX = "A" | "B" | "C" | "D" | "E" | "F"
2326 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
2328 Many HTTP/1.1 header field values consist of words separated by LWS
2329 or special characters. These special characters MUST be in a quoted
2333 Leach & Newman Expires: March 2005 [Page 39]
2339 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2342 string to be used within a parameter value.
2344 token = 1*TOKENCHAR
2345 separators = "(" | ")" | "<" | ">" | "@"
2346 | "," | ";" | ":" | "\" | <">
2347 | "/" | "[" | "]" | "?" | "="
2348 | "{" | "}" | SP | HT
2349 TOKENCHAR = <any CHAR except CTLs or separators>
2351 A string of text is parsed as a single word if it is quoted using
2352 double-quote marks.
2354 quoted-string = ( <"> qdstr-val <"> )
2355 qdstr-val = *( qdtext | quoted-pair )
2356 qdtext = <any TEXTCHAR except <"> and "\">
2358 Note that LWS is NOT implicit between the double-quote marks (<">)
2359 surrounding a qdstr-val and the qdstr-val; any LWS will be considered
2360 part of the qdstr-val. This is also the case for quotation marks
2361 surrounding any other construct.
2363 The backslash character ("\") MAY be used as a single-character
2364 quoting mechanism only within qdstr-val and comment constructs.
2366 quoted-pair = "\" CHAR
2368 The value of this construct is CHAR. Note that an effect of this rule
2369 is that backslash itself MUST be quoted.
2393 Leach & Newman Expires: March 2005 [Page 40]
2399 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2402 8 Sample Code
2404 The sample implementation in [Digest] also applies to DIGEST-MD5.
2406 The following code implements the conversion from UTF-8 to 8859-1 if
2407 necessary.
2409 /* if the string is entirely in the 8859-1 subset of UTF-8, then
2410 * translate to 8859-1 prior to MD5
2411 */
2412 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
2413 int len)
2414 {
2415 const unsigned char *scan, *end;
2416 unsigned char cbuf;
2418 end = base + len;
2419 for (scan = base; scan < end; ++scan) {
2420 if (*scan > 0xC3) break; /* abort if outside 8859-1 */
2421 if (*scan >= 0xC0 && *scan <= 0xC3) {
2422 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
2423 break;
2424 }
2425 }
2426 /* if we found a character outside 8859-1, don't alter string
2427 */
2428 if (scan < end) {
2429 MD5Update(ctx, base, len);
2430 return;
2431 }
2433 /* convert to 8859-1 prior to applying hash
2434 */
2435 do {
2436 for (scan = base; scan < end && *scan < 0xC0; ++scan)
2437 ;
2438 if (scan != base) MD5Update(ctx, base, scan - base);
2439 if (scan + 1 >= end) break;
2440 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
2441 MD5Update(ctx, &cbuf, 1);
2442 base = scan + 2;
2443 } while (base < end);
2444 }
2453 Leach & Newman Expires: March 2005 [Page 41]
2459 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2462 10 Acknowledgements
2464 The following people had substantial contributions to the development
2465 and/or refinement of this document:
2467 Lawrence Greenfield
2468 John Gardiner Myers
2469 Simon Josefsson
2470 RL Bob Morgan
2471 Jeff Hodges
2472 Claus Assmann
2473 Tony Hansen
2474 Ken Murchison
2475 Sam Hartman
2476 Kurt D. Zeilenga
2477 Hallvard B. Furuseth
2479 as well as other members of the SASL mailing list.
2481 The text used is section 3.8 was taken from [TLS-CBC] by Bodo Moeller.
2513 Leach & Newman Expires: March 2005 [Page 42]
2519 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2522 11 Full Copyright Statement
2524 Copyright (C) The Internet Society (2004). This document is subject
2525 to the rights, licenses and restrictions contained in BCP 78, and
2526 except as set forth therein, the authors retain all their rights.
2528 This document and the information contained herein are provided on an
2529 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2530 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2531 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2532 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2533 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2534 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2536 Acknowledgement
2538 Funding for the RFC Editor function is currently provided by the
2539 Internet Society.
2541 12 Intellectual Property
2543 The IETF takes no position regarding the validity or scope of any
2544 Intellectual Property Rights or other rights that might be claimed to
2545 pertain to the implementation or use of the technology described in
2546 this document or the extent to which any license under such rights
2547 might or might not be available; nor does it represent that it has
2548 made any independent effort to identify any such rights. Information
2549 on the procedures with respect to rights in RFC documents can be
2550 found in BCP 78 and BCP 79.
2552 Copies of IPR disclosures made to the IETF Secretariat and any
2553 assurances of licenses to be made available, or the result of an
2554 attempt made to obtain a general license or permission for the use of
2555 such proprietary rights by implementers or users of this
2556 specification can be obtained from the IETF on-line IPR repository at
2557 http://www.ietf.org/ipr.
2559 The IETF invites any interested party to bring to its attention any
2560 copyrights, patents or patent applications, or other proprietary
2561 rights that may cover technology that may be required to implement
2562 this standard. Please address the information to the IETF at ietf-
2563 ipr@ietf.org.
2573 Leach & Newman Expires: March 2005 [Page 43]
2579 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2582 Appendix A: Changes from 2831
2584 1). Fixed various typos in formulas.
2586 2). Dropped DES as mandatory to implement cipher (rc4 is mandatory to
2587 implement). Removed "des" and "3des" ciphers because of known
2588 interoperability problems and vulnerability to CBC mode attack.
2590 3). Tighten ABNF. Fixed some bugs.
2592 4). Clarified nc-value verification and which side is aborting
2593 exchange.
2595 5). Added text saying that for interoperability
2596 username/password/realm MUST be prepared using the "SASLPrep"
2597 profile [SASLPrep] of the "stringprep" algorithm [RFC 3454].
2599 6). Clarified that unquoted version of the username, etc. used in A1
2600 calculation.
2602 7). Various cleanup to References section. Split all references to
2603 Normative and Informative.
2605 8). Added minimal and maximal limits on maxbuf. Clarified how to
2606 calculate max sender size.
2608 9). Change ABNF for host to allow for IPv6 addresses. ABNF now
2609 references RFC 3513 and RFC 2396.
2611 10). Added man-in-the-middle considerations for ciphers.
2613 11). Clarified how sequence counters are updated.
2615 12). Addition warnings about preventing reply/redirection attacks.
2617 13). Specified that "charset" directive affects "realm" and doesn't
2618 affect "authzid".
2620 14). Removed text that described that "authzid" is in Unicode in
2621 Normalization Form KC, encoded as UTF-8.
2623 15). Clarified that rc4 state is not reset between two consecutive
2624 sent/received buffers of protected data.
2626 16). Clarified how "maximal sender size" is calculated.
2628 17). Prohibit an empty authzid, as this caused interoperability
2629 problems.
2633 Leach & Newman Expires: March 2005 [Page 44]
2639 INTERNET DRAFT DIGEST-MD5 SASL Mechanism September 2004
2642 18). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL
2643 mechanism" document (expired draft-ietf-sasl-digest-aes-00.txt).
2645 19). Use explicit IV with aes cipher in CBC mode.
2647 20). Changed "aes" cipher option name to "aes-cbc", because -03
2648 introduces new encryption procedure.
2650 21). Cleaned up Confidentiality protection section. Added step by
2651 step exlanation how CBC mode is used.
2653 22). Added clarification which end and under what conditions has to
2654 perform SASLPrep (still work in progress).
2656 23). Clarified how UIs should present realms.
2658 24). Clarified client behavior, if it recognizes no ciphers.
2660 25). Clarified that the server is not required to advertise all
2661 realms it supports.
2663 26). Changed some informative text to normative MUST/SHOULDs.
2665 And other minor text clarifications.
2668 Appendix B: Open Issues/ToDo List
2670 1). The latest revision prohibits escaped characters in nonce/cnonce.
2671 This is different
2672 from HTTP Digest. Any objections?
2674 2). Do we need/want a new stringprep profile for "realm"?
2676 3). Resolve ISO-8859-1 and SaslPrep interaction issue as reported by
2677 Simon Josefsson.
2679 4). Replace ABNF with the reference to RFC 2234?
2681 5). Pick a way to fix CBC mode attack.
2683 6). Normative vs. Informative references must be carefully rechecked.
2693 Leach & Newman Expires: March 2005 [Page 45]