7 INTERNET-DRAFT P. Leach
8 Obsoletes: 2831 Microsoft
9 Intended category: Standards track C. Newman
15 Using Digest Authentication as a SASL Mechanism
16 draft-ietf-sasl-rfc2831bis-02.txt
20 This document is an Internet-Draft and is in full conformance with
21 all provisions of Section 10 of RFC 2026.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that other
25 groups may also distribute working documents as Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
40 Copyright (C) The Internet Society (2003). All Rights Reserved.
44 This specification defines how HTTP Digest Authentication [Digest]
45 can be used as a SASL [RFC 2222] mechanism for any protocol that has
46 a SASL profile. It is intended both as an improvement over CRAM-MD5
47 [RFC 2195] and as a convenient way to support a single authentication
48 mechanism for web, mail, LDAP, and other protocols.
58 Leach & Newman Expires: December 2003 [Page 1]
64 INTERNET DRAFT Digest SASL Mechanism June 2003
69 1 INTRODUCTION.....................................................3
70 1.1 CONVENTIONS AND NOTATION......................................3
71 1.2 REQUIREMENTS..................................................4
72 2 AUTHENTICATION...................................................5
73 2.1 INITIAL AUTHENTICATION........................................5
74 2.1.1 Step One...................................................5
75 2.1.2 Step Two...................................................9
76 2.1.3 Step Three................................................16
77 2.2 SUBSEQUENT AUTHENTICATION....................................17
78 2.2.1 Step one..................................................17
79 2.2.2 Step Two..................................................17
80 2.3 INTEGRITY PROTECTION.........................................18
81 2.4 CONFIDENTIALITY PROTECTION...................................18
82 3 SECURITY CONSIDERATIONS.........................................21
83 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21
84 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21
85 3.3 REPLAY ATTACKS...............................................21
86 3.4 ONLINE DICTIONARY ATTACKS....................................22
87 3.5 OFFLINE DICTIONARY ATTACKS...................................22
88 3.6 MAN IN THE MIDDLE............................................22
89 3.7 CHOSEN PLAINTEXT ATTACKS.....................................22
90 3.8 CBC MODE ATTACKS.............................................
91 3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23
92 3.10 STORING PASSWORDS...........................................23
93 3.11 MULTIPLE REALMS.............................................24
94 3.12 SUMMARY.....................................................24
95 4 EXAMPLE.........................................................24
96 5 REFERENCES......................................................26
97 5.1 NORMATIVE REFERENCES.........................................26
98 5.2 INFORMATIVE REFERENCES.......................................27
99 6 AUTHORS' ADDRESSES..............................................28
100 7 ABNF............................................................29
101 7.1 AUGMENTED BNF................................................29
102 7.2 BASIC RULES..................................................31
103 8 SAMPLE CODE.....................................................33
104 9 INTEROPERABILITY CONSIDERATIONS.................................34
105 9.1 Implementing DES cipher in CBC mode..........................34
106 10 ACKNOWLEDGEMENTS..............................................34
107 11 FULL COPYRIGHT STATEMENT.......................................35
108 Appendix A: Changes from 2831.....................................36
109 Appendix B: Open Issues...........................................37
118 Leach & Newman Expires: December 2003 [Page 2]
124 INTERNET DRAFT Digest SASL Mechanism June 2003
129 This specification describes the use of HTTP Digest Access
130 Authentication as a SASL mechanism. The authentication type
131 associated with the Digest SASL mechanism is "DIGEST-MD5".
133 This specification is intended to be upward compatible with the
134 "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication
135 specified in [Digest]. The only difference in the "md5-sess"
136 algorithm is that some directives not needed in a SASL mechanism have
137 had their values defaulted.
139 There is one new feature for use as a SASL mechanism: integrity
140 protection on application protocol messages after an authentication
143 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext
144 attacks, and permits the use of third party authentication servers,
145 mutual authentication, and optimized reauthentication if a client has
146 recently authenticated to a server.
148 1.1 Conventions and Notation
150 This specification uses the same ABNF notation and lexical
151 conventions as HTTP/1.1 specification; see section 7.
153 Let { a, b, ... } be the concatenation of the octet strings a, b, ...
155 Let ** denote the power operation.
157 Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
159 Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string
160 k, a colon and the string s.
162 Let HEX(n) be the representation of the 16 octet MD5 hash n as a
163 string of 32 hex digits (with alphabetic characters always in lower
164 case, since MD5 is case sensitive).
166 Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet
167 string s using the octet string k as a key.
178 Leach & Newman Expires: December 2003 [Page 3]
184 INTERNET DRAFT Digest SASL Mechanism June 2003
187 Let unq(X) be the value of the quoted-string X without the
188 surrounding quotes and with all escape characters "\\" removed. For
189 example for the quoted-string "Babylon" the value of unq("Babylon")
190 is Babylon; for the quoted string "ABC\"123\\" the value of
191 unq("ABC\"123\\") is ABC"123\.
193 The value of a quoted string constant as an octet string does not
194 include any terminating null character.
198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
200 document are to be interpreted as described in RFC 2119 [RFC 2119].
202 An implementation is not compliant if it fails to satisfy one or more
203 of the MUST level requirements for the protocols it implements. An
204 implementation that satisfies all the MUST level and all the SHOULD
205 level requirements for its protocols is said to be "unconditionally
206 compliant"; one that satisfies all the MUST level requirements but
207 not all the SHOULD level requirements for its protocols is said to be
208 "conditionally compliant."
238 Leach & Newman Expires: December 2003 [Page 4]
244 INTERNET DRAFT Digest SASL Mechanism June 2003
249 The following sections describe how to use Digest as a SASL
250 authentication mechanism.
252 2.1 Initial Authentication
254 If the client has not recently authenticated to the server, then it
255 must perform "initial authentication", as defined in this section. If
256 it has recently authenticated, then a more efficient form is
257 available, defined in the next section.
261 The server starts by sending a challenge. The data encoded in the
262 challenge contains a string formatted according to the rules for a
263 "digest-challenge" defined as follows:
298 Leach & Newman Expires: December 2003 [Page 5]
304 INTERNET DRAFT Digest SASL Mechanism June 2003
308 1#( realm | nonce | qop-options | stale | server_maxbuf | charset
309 algorithm | cipher-opts | auth-param )
311 realm = "realm" "=" <"> realm-value <">
312 realm-value = qdstr-val
313 nonce = "nonce" "=" <"> nonce-value <">
314 nonce-value = *qdtext
315 qop-options = "qop" "=" <"> qop-list <">
316 qop-list = 1#qop-value
317 qop-value = "auth" | "auth-int" | "auth-conf" |
319 stale = "stale" "=" "true"
320 server_maxbuf = "maxbuf" "=" maxbuf-value
321 maxbuf-value = 1*DIGIT
322 charset = "charset" "=" "utf-8"
323 algorithm = "algorithm" "=" "md5-sess"
324 cipher-opts = "cipher" "=" <"> 1#cipher-value <">
325 cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
326 "rc4-56" | "aes" | token
327 auth-param = token "=" ( token | quoted-string )
329 The meanings of the values of the directives used above are as
333 Mechanistically, a string which can enable users to know which
334 username and password to use, in case they might have different
335 ones for different servers. Conceptually, it is the name of a
336 collection of accounts that might include the user's account. This
337 string should contain at least the name of the host performing the
338 authentication and might additionally indicate the collection of
339 users who might have access. An example might be
340 "registered_users@gotham.news.example.com". This directive is
341 optional; if not present, the client SHOULD solicit it from the
342 user or be able to compute a default; a plausible default might be
343 the realm supplied by the user when they logged in to the client
344 system. Multiple realm directives are allowed, in which case the
345 user or client must choose one as the realm for which to supply to
346 username and password.
348 If at least one realm is present and the charset directive is also
349 specified (which means that realm(s) are encoded as UTF-8), the
350 client should prepare each instance of realm using the "SASLPrep"
351 profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If
352 preparation of a realm instance fails or results in an empty
353 string, the client should abort the authentication exchange.
358 Leach & Newman Expires: December 2003 [Page 6]
364 INTERNET DRAFT Digest SASL Mechanism June 2003
368 A server-specified data string which MUST be different each time a
369 digest-challenge is sent as part of initial authentication. It is
370 recommended that this string be base64 or hexadecimal data. Note
371 that since the string is passed as a quoted string, the
372 double-quote character is not allowed unless escaped (see section
373 7.2). The contents of the nonce are implementation dependent. The
374 security of the implementation depends on a good choice. It is
375 RECOMMENDED that it contain at least 64 bits of entropy. The nonce
376 is opaque to the client. This directive is required and MUST
377 appear exactly once; if not present, or if multiple instances are
378 present, the client should abort the authentication exchange.
381 A quoted string of one or more tokens indicating the "quality of
382 protection" values supported by the server. The value "auth"
383 indicates authentication; the value "auth-int" indicates
384 authentication with integrity protection; the value "auth-conf"
385 indicates authentication with integrity protection and encryption.
386 This directive is optional; if not present it defaults to "auth".
387 The client MUST ignore unrecognized options; if the client
388 recognizes no option, it should abort the authentication exchange.
391 The "stale" directive is not used in initial authentication. See
392 the next section for its use in subsequent authentications. This
393 directive may appear at most once; if multiple instances are
394 present, the client should abort the authentication exchange.
396 server_maxbuf ("maximal ciphertext buffer size")
397 A number indicating the size of the largest buffer the server is
398 able to receive when using "auth-int" or "auth-conf". The value
399 MUST be bigger than 16 and smaller or equal to 16777215 (i.e.
400 2**24-1). If this directive is missing, the default value is
401 65536. This directive may appear at most once; if multiple
402 instances are present, the client MUST abort the authentication
405 Let call "maximal cleartext buffer size" (or "maximal sender
406 size") the maximal size of a cleartext buffer that, after being
407 transformed by integrity (section 2.3) or confidentiality (section
408 2.4) protection function, will produce a SASL block of the maxbuf
409 size. As it should be clear from the name, the sender MUST never
410 pass a block of data bigger than the "maximal sender size" through
411 the selected protection function. This will guaranty that the
412 receiver will never get a block bigger than the maxbuf.
418 Leach & Newman Expires: December 2003 [Page 7]
424 INTERNET DRAFT Digest SASL Mechanism June 2003
428 This directive, if present, specifies that the server supports
429 UTF-8 [UTF-8] encoding for the username, realm and password. If
430 present, the username, realm and password are in Unicode, prepared
431 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
432 algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not
433 present, the username, realm and password MUST be encoded in ISO
434 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). The
435 directive is needed for backwards compatibility with HTTP Digest,
436 which only supports ISO 8859-1. This directive may appear at most
437 once; if multiple instances are present, the client should abort
438 the authentication exchange.
440 Note, that this directive doesn't affect authorization id
444 This directive is required for backwards compatibility with HTTP
445 Digest, which supports other algorithms. This directive is
446 required and MUST appear exactly once; if not present, or if
447 multiple instances are present, the client should abort the
448 authentication exchange.
451 A list of ciphers that the server supports. This directive must be
452 present exactly once if "auth-conf" is offered in the
453 "qop-options" directive, in which case the "3des" cipher is
454 mandatory-to-implement. The client MUST ignore unrecognized
455 options; if the client recognizes no option, it should abort the
456 authentication exchange. See section 2.4 for more detailed
457 description of the ciphers.
460 the Data Encryption Standard (DES) cipher [FIPS] in cipher
461 block chaining (CBC) mode with a 56 bit key.
464 the "triple DES" cipher in CBC mode with EDE
465 (Encrypt,Decrypt,Encrypt) with the same key for each E stage
466 (aka "two keys mode") for a total key length of 112 bits.
469 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
473 the Advanced Encryption Standard (AES) cipher [AES] in cipher
474 block chaining (CBC) mode with a 128 bit key. This mode
478 Leach & Newman Expires: December 2003 [Page 8]
484 INTERNET DRAFT Digest SASL Mechanism June 2003
487 requires an Initialization Vector (IV) that has the same size
491 This construct allows for future extensions; it may appear more
492 than once. The client MUST ignore any unrecognized directives.
494 For use as a SASL mechanism, note that the following changes are made
495 to "digest-challenge" from HTTP: the following Digest options (called
496 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
497 and MUST be ignored if received):
502 The size of a digest-challenge MUST be less than 2048 bytes.
506 The client makes note of the "digest-challenge" and then responds
507 with a string formatted and computed according to the rules for a
508 "digest-response" defined as follows:
510 digest-response = 1#( username | realm | nonce | cnonce |
511 nonce-count | qop | digest-uri | response |
512 client_maxbuf | charset | cipher | authzid |
515 username = "username" "=" <"> username-value <">
516 username-value = qdstr-val
517 cnonce = "cnonce" "=" <"> cnonce-value <">
518 cnonce-value = *qdtext
519 nonce-count = "nc" "=" nc-value
521 client_maxbuf = "maxbuf" "=" maxbuf-value
522 qop = "qop" "=" qop-value
523 digest-uri = "digest-uri" "=" <"> digest-uri-value <">
524 digest-uri-value = serv-type "/" host [ "/" serv-name ]
527 response = "response" "=" response-value
528 response-value = 32LHEX
529 LHEX = "0" | "1" | "2" | "3" |
530 "4" | "5" | "6" | "7" |
531 "8" | "9" | "a" | "b" |
532 "c" | "d" | "e" | "f"
533 cipher = "cipher" "=" cipher-value
534 authzid = "authzid" "=" <"> authzid-value <">
538 Leach & Newman Expires: December 2003 [Page 9]
544 INTERNET DRAFT Digest SASL Mechanism June 2003
547 authzid-value = qdstr-val
549 The 'host' non-terminal is defined in [RFC 2732] as
551 host = hostname | IPv4address | IPv6reference
552 ipv6reference = "[" IPv6address "]"
554 where IPv6address and IPv4address are defined in [RFC 2373]
555 and 'hostname' is defined in [RFC 2396].
558 The user's name in the specified realm, encoded according to the
559 value of the "charset" directive. This directive is required and
560 MUST be present exactly once; otherwise, authentication fails.
562 Upon the receipt of this value and if the charset directive is
563 also specified (which means that the username is encoded as
564 UTF-8), the server MUST prepare the username using the "SASLPrep"
565 profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If
566 preparation of the username fails or results in an empty string,
567 the server MUST fail the authentication exchange.
570 The realm containing the user's account, encoded according to the
571 value of the "charset" directive. This directive is required if
572 the server provided any realms in the
573 "digest-challenge", in which case it may appear exactly once and
574 its value SHOULD be one of those realms. If the directive is
575 missing, "realm-value" will set to the empty string when computing
576 A1 (see below for details).
578 If realm was provided by the client and if the charset directive
579 was also specified (which means that the realm is encoded as
580 UTF-8), the server MUST prepare the realm using the "SASLPrep"
581 profile [SASLPrep] of the "stringprep" algorithm [StringPrep]. If
582 preparation of the realm fails or results in an empty string, the
583 server MUST fail the authentication exchange.
586 The server-specified data string received in the preceding digest-
587 challenge. This directive is required and MUST be present exactly
588 once; otherwise, authentication fails.
598 Leach & Newman Expires: December 2003 [Page 10]
604 INTERNET DRAFT Digest SASL Mechanism June 2003
608 A client-specified data string which MUST be different each time a
609 digest-response is sent as part of initial authentication. The
610 cnonce-value is an opaque quoted string value provided by the
611 client and used by both client and server to avoid chosen
612 plaintext attacks, and to provide mutual authentication. The
613 security of the implementation depends on a good choice. It is
614 RECOMMENDED that it contain at least 64 bits of entropy. This
615 directive is required and MUST be present exactly once; otherwise,
616 authentication fails.
619 The nc-value is the hexadecimal count of the number of requests
620 (including the current request) that the client has sent with the
621 nonce value in this request. For example, in the first request
622 sent in response to a given nonce value, the client sends
623 "nc=00000001". The purpose of this directive is to allow the
624 server to detect request replays by maintaining its own copy of
625 this count - if the same nc-value is seen twice, then the request
626 is a replay. See the description below of the construction of the
627 response value. This directive is required and MUST be present
628 exactly once; otherwise, authentication fails.
631 Indicates what "quality of protection" the client accepted. If
632 present, it may appear exactly once and its value MUST be one of
633 the alternatives in qop-options. If not present, it defaults to
634 "auth". These values affect the computation of the response. Note
635 that this is a single token, not a quoted list of alternatives.
638 Indicates the type of service, such as "http" for web service,
639 "ftp" for FTP service, "smtp" for mail delivery service, etc. The
640 service name as defined in the SASL profile for the protocol see
641 section 4 of [RFC 2222], registered in the IANA registry of
642 "service" elements for the GSSAPI host-based service name form
646 The DNS host name or IP (IPv4 or IPv6) address for the service
647 requested. The DNS host name must be the fully-qualified
648 canonical name of the host. The DNS host name is the preferred
649 form; see notes on server processing of the digest-uri.
658 Leach & Newman Expires: December 2003 [Page 11]
664 INTERNET DRAFT Digest SASL Mechanism June 2003
668 Indicates the name of the service if it is replicated. The service
669 is considered to be replicated if the client's service-location
670 process involves resolution using standard DNS lookup operations,
671 and if these operations involve DNS records (such as SRV [RFC
672 2052], or MX) which resolve one DNS name into a set of other DNS
673 names. In this case, the initial name used by the client is the
674 "serv-name", and the final name is the "host" component. For
675 example, the incoming mail service for "example.com" may be
676 replicated through the use of MX records stored in the DNS, one of
677 which points at an SMTP server called "mail3.example.com"; it's
678 "serv-name" would be "example.com", it's "host" would be
679 "mail3.example.com". If the service is not replicated, or the
680 serv-name is identical to the host, then the serv-name component
684 Indicates the principal name of the service with which the client
685 wishes to connect, formed from the serv-type, host, and serv-name.
686 For example, the FTP service on "ftp.example.com" would have a
687 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
688 the example above would have a "digest-uri" value of
689 "SMTP/mail3.example.com/example.com".
691 Servers SHOULD check that the supplied value is correct. This will
692 detect accidental connection to the incorrect server, as well as some
693 redirection attacks. It is also so that clients will be trained to
694 provide values that will work with implementations that use a shared
695 back-end authentication service that can provide server
698 The serv-type component should match the service being offered. The
699 host component should match one of the host names of the host on
700 which the service is running, or it's IP address. Servers SHOULD NOT
701 normally support the IP address form, because server authentication
702 by IP address is not very useful; they should only do so if the DNS
703 is unavailable or unreliable. The serv-name component should match
704 one of the service's configured service names.
706 This directive may appear at most once; if multiple instances are
707 present, the client should abort the authentication exchange.
709 Note: In the HTTP use of Digest authentication, the digest-uri is the
710 URI (usually a URL) of the resource requested -- hence the name of
718 Leach & Newman Expires: December 2003 [Page 12]
724 INTERNET DRAFT Digest SASL Mechanism June 2003
728 A string of 32 hex digits computed as defined below, which proves
729 that the user knows a password. This directive is required and
730 MUST be present exactly once; otherwise, authentication fails.
733 A number indicating the size of the largest ciphertext buffer the
734 client is able to receive when using "auth-int" or "auth-conf". If
735 this directive is missing, the default value is 65536. This
736 directive may appear at most once; if multiple instances are
737 present, the server MUST abort the authentication exchange. If the
738 value is less or equal to 16 or bigger than 16777215 (i.e.
739 2**24-1), the server MUST abort the authentication exchange.
741 Upon processing/sending of the client_maxbuf value both the server
742 and the client calculate their "maximal ciphertext buffer size" as
743 the minimum of the server_maxbuf (Step One) and the client_maxbuf
744 (Step Two). The "maximal sender size" can be calculated by
745 subtracting 16 from the calculated "maximal ciphertext buffer
748 When sending a block of data the client/server MUST NOT pass more
749 than the "maximal sender size" bytes of data to the selected
750 protection function (2.3 or 2.4).
753 This directive, if present, specifies that the client has used
754 UTF-8 [UTF-8] encoding for the username, realm and password. If
755 present, the username, realm and password are in Unicode, prepared
756 using the "SASLPrep" profile [SASLPrep] of the "stringprep"
757 algorithm [StringPrep] and than encoded as UTF-8 [UTF-8]. If not
758 present, the username and password must be encoded in ISO 8859-1
760 US-ASCII [USASCII] is a subset). The client should send this
761 directive only if the server has indicated it supports UTF-8
762 [UTF-8]. The directive is needed for backwards compatibility with
763 HTTP Digest, which only supports ISO 8859-1.
765 Note, that this directive doesn't affect authorization id
769 32 hex digits, where the alphabetic characters MUST be lower case,
770 because MD5 is not case insensitive.
773 The cipher chosen by the client. This directive MUST appear
774 exactly once if "auth-conf" is negotiated; if required and not
778 Leach & Newman Expires: December 2003 [Page 13]
784 INTERNET DRAFT Digest SASL Mechanism June 2003
787 present, authentication fails.
790 The "authorization ID" directive is optional. If present, and the
791 authenticating user has sufficient privilege, and the server
792 supports it, then after authentication the server will use this
793 identity for making all accesses and access checks. If the client
794 specifies it, and the server does not support it, then the
795 response-value calculated on the server will not match the one
796 calculated on the client and authentication will fail.
798 The authzid MUST NOT be an empty string.
800 The authorization identifier MUST NOT be converted to ISO 8859-1
801 even if the authentication identifier ("username") is converted
802 for compatibility as directed by "charset" directive.
804 The server SHOULD verify the correctness of an authzid as
805 specified by the corresponding SASL protocol profile.
807 The size of a digest-response MUST be less than 4096 bytes.
809 2.1.2.1 Response-value
811 The definition of "response-value" above indicates the encoding for
812 its value -- 32 lower case hex characters. The following definitions
813 show how the value is computed.
815 Although qop-value and components of digest-uri-value may be
816 case-insensitive, the case which the client supplies in step two is
817 preserved for the purpose of computing and verifying the
821 HEX( KD ( HEX(H(A1)),
822 { nonce-value, ":" nc-value, ":",
823 cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
825 If authzid is specified, then A1 is
828 A1 = { H( { unq(username-value), ":", unq(realm-value), ":", passwd } ),
829 ":", nonce-value, ":", cnonce-value, ":", unq(authzid-value) }
831 If authzid is not specified, then A1 is
834 A1 = { H( { unq(username-value), ":", unq(realm-value), ":", passwd } ),
838 Leach & Newman Expires: December 2003 [Page 14]
844 INTERNET DRAFT Digest SASL Mechanism June 2003
847 ":", nonce-value, ":", cnonce-value }
853 The "username-value", "realm-value" and "passwd" are encoded
854 according to the value of the "charset" directive. If "charset=UTF-8"
855 is present, and all the characters of "username-value" are, after
856 preparing using the "SASLPrep" profile [SASLPrep] of the "stringprep"
857 algorithm [StringPrep], in the ISO 8859-1 character set, then it must
858 be converted to ISO 8859-1 before being hashed. The same
859 transformation has to be done for "realm-value" and "passwd". This is
860 so that authentication databases that store the hashed username,
861 realm and password (which is common) can be shared compatibly with
862 HTTP, which specifies ISO 8859-1. A sample implementation of this
863 conversion is in section 8.
865 If the "qop" directive's value is "auth", then A2 is:
867 A2 = { "AUTHENTICATE:", digest-uri-value }
898 Leach & Newman Expires: December 2003 [Page 15]
904 INTERNET DRAFT Digest SASL Mechanism June 2003
907 If the "qop" value is "auth-int" or "auth-conf" then A2 is:
909 A2 = { "AUTHENTICATE:", digest-uri-value,
910 ":00000000000000000000000000000000" }
912 Note that "AUTHENTICATE:" must be in upper case, and the second
913 string constant is a string with a colon followed by 32 zeros.
915 These apparently strange values of A2 are for compatibility with
916 HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and
917 the hash of the entity body to zero in the HTTP digest calculation of
920 Also, in the HTTP usage of Digest, several directives in the
921 "digest-challenge" sent by the server have to be returned by the
922 client in the "digest-response". These are:
927 These directives are not needed when Digest is used as a SASL
928 mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
932 The server receives and validates the "digest-response". The server
933 checks that the nonce-count is "00000001". If it supports subsequent
934 authentication (see section 2.2), it saves the value of the nonce and
935 the nonce-count. It sends a message formatted as follows:
937 response-auth = "rspauth" "=" response-value
939 where response-value is calculated as above, using the values sent in
940 step two, except that if qop is "auth", then A2 is
942 A2 = { ":", digest-uri-value }
944 And if qop is "auth-int" or "auth-conf" then A2 is
946 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
948 Compared to its use in HTTP, the following Digest directives in the
949 "digest-response" are unused:
958 Leach & Newman Expires: December 2003 [Page 16]
964 INTERNET DRAFT Digest SASL Mechanism June 2003
967 2.2 Subsequent Authentication
969 If the client has previously authenticated to the server, and
970 remembers the values of username, realm, nonce, nonce-count, cnonce,
971 and qop that it used in that authentication, and the SASL profile for
972 a protocol permits an initial client response, then it MAY perform
973 "subsequent authentication", as defined in this section.
977 The client uses the values from the previous authentication and sends
978 an initial response with a string formatted and computed according to
979 the rules for a "digest-response", as defined above, but with a
980 nonce-count one greater than used in the last "digest-response".
984 The server receives the "digest-response". If the server does not
985 support subsequent authentication, then it sends a
986 "digest-challenge", and authentication proceeds as in initial
987 authentication. If the server has no saved nonce and nonce-count from
988 a previous authentication, then it sends a "digest-challenge", and
989 authentication proceeds as in initial authentication. Otherwise, the
990 server validates the "digest-response", checks that the nonce-count
991 is one greater than that used in the previous authentication using
992 that nonce, and saves the new value of nonce-count.
994 If the response is invalid, then the server sends a
995 "digest-challenge", and authentication proceeds as in initial
996 authentication (and should be configurable to log an authentication
997 failure in some sort of security audit log, since the failure may be
998 a symptom of an attack). The nonce-count MUST NOT be incremented in
999 this case: to do so would allow a denial of service attack by sending
1000 an out-of-order nonce-count.
1002 If the response is valid, the server MAY choose to deem that
1003 authentication has succeeded. However, if it has been too long since
1004 the previous authentication, or for any o including the next
1005 subsequent authentication, between the client and the server MUST be
1006 integrity protected. Using as a base session key the value of H(A1)
1007 as defined above the client and server calculate a pair of message
1008 integrity keys as follows.
1010 The key for integrity protecting messages from client to server is:
1013 "Digest session key to client-to-server signing key magic constant"})
1018 Leach & Newman Expires: December 2003 [Page 17]
1024 INTERNET DRAFT Digest SASL Mechanism June 2003
1027 The key for integrity protecting messages from server to client is:
1030 "Digest session key to server-to-client signing key magic constant"})
1032 where MD5 is as specified in [RFC 1321]. If message integrity is
1033 negotiated, a MAC block for each message is appended to the message.
1034 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC
1035 2104] of the message, a 2-byte message type number in network byte
1036 order with value 1, and the 4-byte sequence number in network byte
1037 order. The message type is to allow for future extensions such as
1040 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
1043 where Ki is Kic for messages sent by the client and Kis for those
1044 sent by the server. The sequence number (SeqNum) is an unsigned
1045 number initialized to zero after initial or subsequent
1046 authentication, and incremented by one for each message
1047 sent/successfully verified. (Note, that there are two independent
1048 counters for sending and receiving.) The sequence number wraps around
1051 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
1052 received value; the message is discarded if they differ. The
1053 receiver's sequence counter is incremented if they match.
1055 2.4 Confidentiality Protection
1057 If the server sent a "cipher-opts" directive and the client responded
1058 with a "cipher" directive, then subsequent messages between the
1059 client and the server MUST be confidentiality protected. Using as a
1060 base session key the value of H(A1) as defined above the client and
1061 server calculate a pair of message integrity keys as follows.
1063 The key for confidentiality protecting messages from client to server
1066 Kcc = MD5({H(A1)[0..n-1],
1067 "Digest H(A1) to client-to-server sealing key magic constant"})
1069 The key for confidentiality protecting messages from server to client
1072 Kcs = MD5({H(A1)[0..n-1],
1073 "Digest H(A1) to server-to-client sealing key magic constant"})
1078 Leach & Newman Expires: December 2003 [Page 18]
1084 INTERNET DRAFT Digest SASL Mechanism June 2003
1087 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
1088 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*"
1089 and "aes" ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is
1090 the first 7 bytes; the key for "3des" is the first 14 bytes.
1092 The IV used to send/receive the initial buffer of security encoded
1093 data for "des" and "3des" is the last 8 bytes of Kcc or Kcs. For all
1094 subsequent buffers the last 8 bytes of the ciphertext of the buffer
1095 NNN is used as the IV for the buffer (NNN + 1).
1097 The IV for the "aes" cipher in CBC mode for messages going from the
1098 client to the server (IVc) consists of 16 bytes calculated as
1101 IVc = MD5({Kcc, "aes-128"})
1103 The IV for the "aes" cipher in CBC mode for messages going from the
1104 server to the client (IVs) consists of 16 bytes calculated as
1107 IVs = MD5({Kcs, "aes-128"})
1109 The IV is XOR'd with the first plaintext block before it is encrypted
1110 with "aes". Then for successive blocks, the previous ciphertext
1111 block is XOR'd with the current plaintext, before it is encrypted.
1113 rc4 cipher state MUST NOT be reset before sending/receiving a next
1114 buffer of security encoded data.
1116 The MAC block is a variable length padding prefix followed by 16
1117 bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC
1118 2104] of the message, a 2-byte message type number in network byte
1119 order with value 1, and the 4-byte sequence number in network byte
1120 order. If the blocksize of the chosen cipher is not 1 byte, the
1121 padding prefix is one or more octets each containing the number of
1122 padding bytes, such that total length of the encrypted part of the
1123 message is a multiple of the blocksize. The padding and first 10
1124 bytes of the MAC block are encrypted with the chosen cipher along
1127 SEAL(Ki, Kc, SeqNum, msg) =
1128 {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001,
1131 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for
1132 messages sent by the client and Kis and Kcs for those sent by the
1133 server. The sequence number (SeqNum) is an unsigned number
1134 initialized to zero after initial or subsequent authentication, and
1138 Leach & Newman Expires: December 2003 [Page 19]
1144 INTERNET DRAFT Digest SASL Mechanism June 2003
1147 incremented by one for each message sent/successfully verified.
1148 (Note, that there are two independent counters for sending and
1149 receiving.) The sequence number wraps around to 0 after 2**32-1.
1151 Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is
1152 computed and compared with the received value; the padding is
1153 verified. The message is discarded if the received and the
1154 calculated HMACs differ and/or the padding is invalid. See also
1155 section 3.8 for important information about MAC and padding
1156 verification. The receiver's sequence counter is then compared with
1157 the received SeqNum value; the message is discarded if they differ.
1158 The receiver's sequence counter is incremented if they match.
1198 Leach & Newman Expires: December 2003 [Page 20]
1204 INTERNET DRAFT Digest SASL Mechanism June 2003
1207 3 Security Considerations
1209 General SASL security considerations apply to this mechanism.
1210 "stringprep" and Unicode security considerations also apply.
1212 Detailed discussion of other DIGEST-MD5 specific security issues is
1215 3.1 Authentication of Clients using Digest Authentication
1217 Digest Authentication does not provide a strong authentication
1218 mechanism, when compared to public key based mechanisms, for example.
1219 However, since it prevents chosen plaintext attacks, it is stronger
1220 than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC
1221 2244], POP and IMAP [RFC 2195]. It is intended to replace the much
1222 weaker and even more dangerous use of plaintext passwords; however,
1223 since it is still a password based mechanism it avoids some of the
1224 potential deployabilty issues with public-key, OTP or similar
1227 Digest Authentication offers no confidentiality protection beyond
1228 protecting the actual password. All of the rest of the challenge and
1229 response are available to an eavesdropper, including the user's name
1230 and authentication realm.
1232 3.2 Comparison of Digest with Plaintext Passwords
1234 The greatest threat to the type of transactions for which these
1235 protocols are used is network snooping. This kind of transaction
1236 might involve, for example, online access to a mail service whose use
1237 is restricted to paying subscribers. With plaintext password
1238 authentication an eavesdropper can obtain the password of the user.
1239 This not only permits him to access anything in the database, but,
1240 often worse, will permit access to anything else the user protects
1241 with the same password.
1245 Replay attacks are defeated if the client or the server chooses a
1246 fresh nonce for each authentication, as this specification requires.
1248 As a security precaution, the server, when verifying a response from
1249 the client, must use the original server nonce ("nonce") it sent, not
1250 the one returned by the client in the response, as it might have been
1251 modified by an attacker.
1253 To prevent some redirection attacks it is recommended that the server
1254 verifies that the "serv-type" part of the "digest-uri" matches the
1258 Leach & Newman Expires: December 2003 [Page 21]
1264 INTERNET DRAFT Digest SASL Mechanism June 2003
1267 service name and that the hostname/IP address belongs to the server.
1269 3.4 Online dictionary attacks
1271 If the attacker can eavesdrop, then it can test any overheard
1272 nonce/response pairs against a (potentially very large) list of
1273 common words. Such a list is usually much smaller than the total
1274 number of possible passwords. The cost of computing the response for
1275 each password on the list is paid once for each challenge.
1277 The server can mitigate this attack by not allowing users to select
1278 passwords that are in a dictionary.
1280 3.5 Offline dictionary attacks
1282 If the attacker can choose the challenge, then it can precompute the
1283 possible responses to that challenge for a list of common words. Such
1284 a list is usually much smaller than the total number of possible
1285 passwords. The cost of computing the response for each password on
1286 the list is paid just once.
1288 Offline dictionary attacks are defeated if the client chooses a fresh
1289 nonce for each authentication, as this specification requires.
1291 3.6 Man in the Middle
1293 Digest authentication is vulnerable to "man in the middle" (MITM)
1294 attacks. Clearly, a MITM would present all the problems of
1295 eavesdropping. But it also offers some additional opportunities to
1298 A possible man-in-the-middle attack would be to substitute a weaker
1299 qop scheme for the one(s) sent by the server; the server will not be
1300 able to detect this attack. For this reason, the client should always
1301 use the strongest scheme that it understands from the choices
1302 offered, and should never choose a scheme that does not meet its
1303 minimum requirements.
1305 A man-in-the-middle attack may also make the client and the server
1306 that agreed to use confidentiality protection to use different (and
1307 possibly weaker) cipher's. This is because the chosen cipher is not
1308 used in the shared secret calculation.
1310 3.7 Chosen plaintext attacks
1312 A chosen plaintext attack is where a MITM or a malicious server can
1313 arbitrarily choose the challenge that the client will use to compute
1314 the response. The ability to choose the challenge is known to make
1318 Leach & Newman Expires: December 2003 [Page 22]
1324 INTERNET DRAFT Digest SASL Mechanism June 2003
1327 cryptanalysis much easier [MD5].
1329 However, Digest does not permit the attack to choose the challenge as
1330 long as the client chooses a fresh nonce for each authentication, as
1331 this specification requires.
1333 3.8 CBC Mode attacks
1335 The following attack can be launched when the connection uses
1336 Confidentiality protection with ciphers in CBC mode. If bad padding
1337 is treated differently from bad MACs when decrypting a DIGEST-MD5
1338 buffer of security encoded data, the attacker may be able to launch
1339 Vaudenay's attack on padding.
1341 An error logfile will suffice to launch the attack if it reveals the
1342 type of error -- even if file permissions prevent the attacker from
1343 actually reading the file (the file length increase cause by the
1344 attack is likely to reveal which of the two errors occured).
1346 A different approach to distinguish these two error cases and launch
1347 the attack is to examine the timing of error responses: if the MAC
1348 verification is skipped when bad padding has been found, the error
1349 will appear quicker in the case of incorrect block cipher padding
1350 than in the case of an incorrect MAC.
1352 A countermeasure is to compute a MAC of the plaintext anyway, even if
1353 the usual padding removal step fails because of incorrect padding, to
1354 obtain (nearly) uniform timing.
1356 3.9 Spoofing by Counterfeit Servers
1358 If a user can be led to believe that she is connecting to a host
1359 containing information protected by a password she knows, when in
1360 fact she is connecting to a hostile server, then the hostile server
1361 can obtain challenge/response pairs where it was able to partly
1362 choose the challenge. There is no known way that this can be
1365 3.10 Storing passwords
1367 Digest authentication requires that the authenticating agent (usually
1368 the server) store some data derived from the user's name and password
1369 in a "password file" associated with a given realm. Normally this
1370 might contain pairs consisting of username and H({ username-value,
1371 ":", realm-value, ":", passwd }), which is adequate to compute H(A1)
1372 as described above without directly exposing the user's password.
1374 The security implications of this are that if this password file is
1378 Leach & Newman Expires: December 2003 [Page 23]
1384 INTERNET DRAFT Digest SASL Mechanism June 2003
1387 compromised, then an attacker gains immediate access to documents on
1388 the server using this realm. Unlike, say a standard UNIX password
1389 file, this information need not be decrypted in order to access
1390 documents in the server realm associated with this file. On the other
1391 hand, decryption, or more likely a brute force attack, would be
1392 necessary to obtain the user's password. This is the reason that the
1393 realm is part of the digested data stored in the password file. It
1394 means that if one Digest authentication password file is compromised,
1395 it does not automatically compromise others with the same username
1396 and password (though it does expose them to brute force attack).
1398 There are two important security consequences of this. First the
1399 password file must be protected as if it contained plaintext
1400 passwords, because for the purpose of accessing documents in its
1401 realm, it effectively does.
1403 A second consequence of this is that the realm string should be
1404 unique among all realms that any single user is likely to use. In
1405 particular a realm string should include the name of the host doing
1438 Leach & Newman Expires: December 2003 [Page 24]
1444 INTERNET DRAFT Digest SASL Mechanism June 2003
1447 3.11 Multiple realms
1449 Use of multiple realms may mean both that compromise of a the
1450 security database for a single realm does not compromise all
1451 security, and that there are more things to protect in order to keep
1452 the whole system secure.
1456 By modern cryptographic standards Digest Authentication is weak,
1457 compared to (say) public key based mechanisms. But for a large range
1458 of purposes it is valuable as a replacement for plaintext passwords.
1459 Its strength may vary depending on the implementation.
1464 This example shows the use of the Digest SASL mechanism with the
1465 IMAP4 AUTHENTICATE command [RFC 3501].
1467 In this example, "C:" and "S:" represent a line sent by the client or
1468 server respectively including a CRLF at the end. Linebreaks and
1469 indentation within a "C:" or "S:" are editorial and not part of the
1470 protocol. The password in this example was "secret". Note that the
1471 base64 encoding of the challenges and responses is part of the IMAP4
1472 AUTHENTICATE command, not part of the Digest specification itself.
1474 S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9
1476 S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA
1477 UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN
1479 C: a AUTHENTICATE DIGEST-MD5
1480 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
1481 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
1483 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
1484 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
1485 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
1486 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
1487 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
1488 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
1490 S: a OK User logged in
1493 The base64-decoded version of the SASL exchange is:
1498 Leach & Newman Expires: December 2003 [Page 25]
1504 INTERNET DRAFT Digest SASL Mechanism June 2003
1507 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth",
1508 algorithm=md5-sess,charset=utf-8
1509 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1510 nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk",
1511 digest-uri="imap/elwood.innosoft.com",
1512 response=d388dad90d4bbd760a152321f2143af7,qop=auth
1513 S: rspauth=ea40f60335c427b5527b84dbabcdfffd
1515 The password in this example was "secret".
1517 This example shows the use of the Digest SASL mechanism with the
1518 ACAP, using the same notational conventions and password as in the
1519 previous example. Note that ACAP does not base64 encode and uses
1520 fewer round trips that IMAP4.
1522 S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
1523 "DIGEST-MD5" "PLAIN")
1524 C: a AUTHENTICATE "DIGEST-MD5"
1526 S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
1527 algorithm=md5-sess,charset=utf-8
1529 C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
1530 nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
1531 digest-uri="acap/elwood.innosoft.com",
1532 response=6084c6db3fede7352c551284490fd0fc,qop=auth
1534 S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
1538 The server uses the values of all the directives, plus knowledge of
1539 the users password (or the hash of the user's name, server's realm
1540 and the user's password) to verify the computations above. If they
1541 check, then the user has authenticated.
1558 Leach & Newman Expires: December 2003 [Page 26]
1564 INTERNET DRAFT Digest SASL Mechanism June 2003
1569 5.1 Normative references
1571 [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest
1572 Access Authentication", RFC 2617, June 1999.
1574 [ISO-8859] ISO-8859. International Standard--Information Processing--
1575 8-bit Single-Byte Coded Graphic Character Sets --
1576 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
1577 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
1578 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
1579 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
1580 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
1581 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
1582 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
1583 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
1584 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
1586 [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet
1587 Text Messages," STD 11, RFC 822, August 1982.
1589 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1592 [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1593 location of services (DNS SRV)", RFC 2052, October 1996.
1595 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1596 Hashing for Message Authentication", RFC 2104, February
1599 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1600 Requirement Levels", BCP 14, RFC 2119, March 1997.
1602 [RFC 2222] Myers, J., "Simple Authentication and Security Layer
1603 (SASL)", RFC 2222, October 1997.
1605 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of
1606 Internationalized Strings ("stringprep")", RFC 3454,
1609 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1610 3.2.0", defined by: The Unicode Standard, Version 3.0
1611 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
1612 as amended by the Unicode Standard Annex #28: Unicode 3.2
1613 (http://www.unicode.org/reports/tr28/tr28-3.html).
1618 Leach & Newman Expires: December 2003 [Page 27]
1624 INTERNET DRAFT Digest SASL Mechanism June 2003
1627 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
1630 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
1631 Code for Information Interchange. Standard ANSI X3.4-1986,
1634 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1635 and passwords", Work in progress, draft-ietf-sasl-
1638 [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
1639 Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
1641 [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing
1642 Architecture", RFC 2373, July 1998.
1644 [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
1645 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1648 [FIPS] National Institute of Standards and Technology, "DES Modes of
1649 Operation", http://www.itl.nist.gov/fipspubs/fip81.htm,
1652 [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",
1653 http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf,
1657 5.2 Informative references
1659 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
1660 AUTHorize Extension for Simple Challenge/Response", RFC
1661 2195, September 1997.
1663 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5",
1664 CryptoBytes, Sping 1995, RSA Inc,
1665 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
1667 [RFC 2078] Linn, J., "Generic Security Service Application Program
1668 Interface, Version 2", RFC 2078, January 1997.
1670 [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version
1671 4rev1", RFC 3501, March 2003.
1673 [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
1674 Access Protocol", RFC 2244, November 1997.
1678 Leach & Newman Expires: December 2003 [Page 28]
1684 INTERNET DRAFT Digest SASL Mechanism June 2003
1687 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1688 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext
1689 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1691 [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
1692 Problems and Countermeasures",
1693 http://www.openssl.org/~bodo/tls-cbc.txt.
1738 Leach & Newman Expires: December 2003 [Page 29]
1744 INTERNET DRAFT Digest SASL Mechanism June 2003
1747 6 Authors' Addresses
1752 Redmond, WA 98052, USA
1754 EMail: paulle@microsoft.com
1760 West Covina, CA 91790, USA
1762 EMail: Chris.Newman@Sun.COM
1768 Teddington, Middlesex, TW11 0NU, UK
1770 Email: mel@isode.com
1798 Leach & Newman Expires: December 2003 [Page 30]
1804 INTERNET DRAFT Digest SASL Mechanism June 2003
1809 What follows is the definition of the notation as is used in the
1810 HTTP/1.1 specification [RFC 2616] and the HTTP authentication
1811 specification [Digest]; it is reproduced here for ease of reference.
1812 Since it is intended that a single Digest implementation can support
1813 both HTTP and SASL-based protocols, the same notation is used in both
1814 to facilitate comparison and prevention of unwanted differences.
1815 Since it is cut-and-paste from the HTTP specifications, not all
1816 productions may be used in this specification. It is also not quite
1817 legal ABNF; again, the errors were copied from the HTTP
1822 All of the mechanisms specified in this document are described in
1823 both prose and an augmented Backus-Naur Form (BNF) similar to that
1824 used by RFC 822 [RFC 822]. Implementers will need to be familiar with
1825 the notation in order to understand this specification.
1827 The augmented BNF includes the following constructs:
1830 The name of a rule is simply the name itself (without any
1831 enclosing "<" and ">") and is separated from its definition by the
1832 equal "=" character. White space is only significant in that
1833 indentation of continuation lines is used to indicate a rule
1834 definition that spans more than one line. Certain basic rules are
1835 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
1836 brackets are used within definitions whenever their presence will
1837 facilitate discerning the use of rule names.
1840 Quotation marks surround literal text. Unless stated otherwise,
1841 the text is case-insensitive.
1844 Elements separated by a bar ("|") are alternatives, e.g., "yes |
1845 no" will accept yes or no.
1848 Elements enclosed in parentheses are treated as a single element.
1849 Thus, "(elem (foo | bar) elem)" allows the token sequences
1850 "elem foo elem" and "elem bar elem".
1853 The character "*" preceding an element indicates repetition. The
1854 full form is "<n>*<m>element" indicating at least <n> and at most
1858 Leach & Newman Expires: December 2003 [Page 31]
1864 INTERNET DRAFT Digest SASL Mechanism June 2003
1867 <m> occurrences of element. Default values are 0 and infinity so
1868 that "*(element)" allows any number, including zero; "1*element"
1869 requires at least one; and "1*2element" allows one or two.
1872 Square brackets enclose optional elements; "[foo bar]" is
1873 equivalent to "*1(foo bar)".
1876 Specific repetition: "<n>(element)" is equivalent to
1877 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
1878 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
1879 alphabetic characters.
1882 A construct "#" is defined, similar to "*", for defining lists of
1883 elements. The full form is "<n>#<m>element" indicating at least
1884 <n> and at most <m> elements, each separated by one or more commas
1885 (",") and OPTIONAL linear white space (LWS). This makes the usual
1886 form of lists very easy; a rule such as
1887 ( *LWS element *( *LWS "," *LWS element ))
1890 Wherever this construct is used, null elements are allowed, but do
1891 not contribute to the count of elements present. That is,
1892 "(element), , (element) " is permitted, but counts as only two
1893 elements. Therefore, where at least one element is required, at
1894 least one non-null element MUST be present. Default values are 0
1895 and infinity so that "#element" allows any number, including zero;
1896 "1#element" requires at least one; and "1#2element" allows one or
1900 A semi-colon, set off some distance to the right of rule text,
1901 starts a comment that continues to the end of line. This is a
1902 simple way of including useful notes in parallel with the
1906 The grammar described by this specification is word-based. Except
1907 where noted otherwise, linear white space (LWS) can be included
1908 between any two adjacent words (token or quoted-string), and
1909 between adjacent words and separators, without changing the
1910 interpretation of a field. At least one delimiter (LWS and/or
1911 separators) MUST exist between any two tokens (for the definition
1912 of "token" below), since they would otherwise be interpreted as a
1918 Leach & Newman Expires: December 2003 [Page 32]
1924 INTERNET DRAFT Digest SASL Mechanism June 2003
1929 The following rules are used throughout this specification to
1930 describe basic parsing constructs. The US-ASCII coded character set
1931 is defined by ANSI X3.4-1986 [USASCII].
1933 OCTET = <any 8-bit character>
1934 CHAR = <any US-ASCII character (octets 0 - 127)>
1935 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
1936 LOALPHA = <any US-ASCII lowercase letter "a".."z">
1937 ALPHA = UPALPHA | LOALPHA
1938 DIGIT = <any US-ASCII digit "0".."9">
1939 CTL = <any US-ASCII control character
1940 (octets 0 - 31) and DEL (127)>
1941 CR = <US-ASCII CR, carriage return (13)>
1942 LF = <US-ASCII LF, linefeed (10)>
1943 SP = <US-ASCII SP, space (32)>
1944 HT = <US-ASCII HT, horizontal-tab (9)>
1945 <"> = <US-ASCII double-quote mark (34)>
1946 TEXTCHAR = <any OCTET except CTLs, but including HT>
1949 All linear white space, including folding, has the same semantics as
1950 SP. A recipient MAY replace any linear white space with a single SP
1951 before interpreting the field value or forwarding the message
1954 LWS = [CRLF] 1*( SP | HT )
1956 The TEXT rule is only used for descriptive field contents and values
1957 that are not intended to be interpreted by the message parser. Words
1958 of TEXT contains characters either from ISO-8859-1 [ISO-8859]
1959 character set or UTF-8 [UTF-8].
1961 TEXT = <any *OCTET except CTLs,
1964 A CRLF is allowed in the definition of TEXT only as part of a header
1965 field continuation. It is expected that the folding LWS will be
1966 replaced with a single SP before interpretation of the TEXT value.
1968 Hexadecimal numeric characters are used in several protocol elements.
1970 HEX = "A" | "B" | "C" | "D" | "E" | "F"
1971 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
1973 Many HTTP/1.1 header field values consist of words separated by LWS
1974 or special characters. These special characters MUST be in a quoted
1978 Leach & Newman Expires: December 2003 [Page 33]
1984 INTERNET DRAFT Digest SASL Mechanism June 2003
1987 string to be used within a parameter value.
1990 separators = "(" | ")" | "<" | ">" | "@"
1991 | "," | ";" | ":" | "\" | <">
1992 | "/" | "[" | "]" | "?" | "="
1993 | "{" | "}" | SP | HT
1994 TOKENCHAR = <any CHAR except CTLs or separators>
1996 A string of text is parsed as a single word if it is quoted using
1999 quoted-string = ( <"> qdstr-val <"> )
2000 qdstr-val = *( qdtext | quoted-pair )
2001 qdtext = <any TEXTCHAR except <"> and "\">
2003 Note that LWS is NOT implicit between the double-quote marks (<">)
2004 surrounding a qdstr-val and the qdstr-val; any LWS will be considered
2005 part of the qdstr-val. This is also the case for quotation marks
2006 surrounding any other construct.
2008 The backslash character ("\") MAY be used as a single-character
2009 quoting mechanism only within qdstr-val and comment constructs.
2011 quoted-pair = "\" CHAR
2013 The value of this construct is CHAR. Note that an effect of this rule
2014 is that backslash itself MUST be quoted.
2038 Leach & Newman Expires: December 2003 [Page 34]
2044 INTERNET DRAFT Digest SASL Mechanism June 2003
2049 The sample implementation in [Digest] also applies to DIGEST-MD5.
2051 The following code implements the conversion from UTF-8 to 8859-1 if
2054 /* if the string is entirely in the 8859-1 subset of UTF-8, then
2055 * translate to 8859-1 prior to MD5
2057 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
2060 const unsigned char *scan, *end;
2064 for (scan = base; scan < end; ++scan) {
2065 if (*scan > 0xC3) break; /* abort if outside 8859-1 */
2066 if (*scan >= 0xC0 && *scan <= 0xC3) {
2067 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
2071 /* if we found a character outside 8859-1, don't alter string
2074 MD5Update(ctx, base, len);
2078 /* convert to 8859-1 prior to applying hash
2081 for (scan = base; scan < end && *scan < 0xC0; ++scan)
2083 if (scan != base) MD5Update(ctx, base, scan - base);
2084 if (scan + 1 >= end) break;
2085 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
2086 MD5Update(ctx, &cbuf, 1);
2088 } while (base < end);
2098 Leach & Newman Expires: December 2003 [Page 35]
2104 INTERNET DRAFT Digest SASL Mechanism June 2003
2107 9 Interoperability considerations
2109 9.1 Implementing DES cipher in CBC mode
2111 Several cryptographic libraries (Ebones, OpenSSL) provide a convenience
2112 function des_cbc_encrypt for implementing DES cipher in CBC mode.
2113 There is a documented bug in this function: the function doesn't update
2114 IV before returning. If an implementation uses this function to implement
2115 DES cipher in CBC mode, it MUST update IV by copying the last 8 bytes of
2116 the des_cbc_encrypt's output to the IV buffer.
2117 Note that the function des_ede2_cbc_encrypt that may be used to implement
2118 3DES (in "two keys mode") in CBC mode works as expected.
2120 Care must be taken when configuring the DES keys for most DES
2121 libraries. This specification gives 56 bits for the DES key (or 112
2122 bits for the 3DES key); libraries generally expect the key to be given
2123 in a 64 bit (128 bit for 3DES) form.
2125 The following C function can be used to convert a 56 bit DES key into a
2126 form acceptable for the libraries. The low order bit in each byte
2127 would contain parity information and will be corrected by the library.
2129 /* slide the first 7 bytes of 'inbuf' into the high seven bits of the
2130 first 8 bytes of 'keybuf'. 'keybuf' better be 8 bytes long or longer. */
2131 void slidebits(unsigned char *keybuf, unsigned char *inbuf)
2133 keybuf[0] = inbuf[0];
2134 keybuf[1] = (inbuf[0]<<7) | (inbuf[1]>>1);
2135 keybuf[2] = (inbuf[1]<<6) | (inbuf[2]>>2);
2136 keybuf[3] = (inbuf[2]<<5) | (inbuf[3]>>3);
2137 keybuf[4] = (inbuf[3]<<4) | (inbuf[4]>>4);
2138 keybuf[5] = (inbuf[4]<<3) | (inbuf[5]>>5);
2139 keybuf[6] = (inbuf[5]<<2) | (inbuf[6]>>6);
2140 keybuf[7] = (inbuf[6]<<1);
2145 The following people had substantial contributions to the development
2146 and/or refinement of this document:
2148 Lawrence Greenfield John Gardiner Myers Simon Josefsson RL Bob Morgan
2149 Jeff Hodges Claus Assmann Tony Hansen Sam Hartman
2151 as well as other members of the SASL mailing list.
2153 The text used is section 3.8 was taken from [TLS-CBC] by Bodo
2158 Leach & Newman Expires: December 2003 [Page 36]
2164 INTERNET DRAFT Digest SASL Mechanism June 2003
2167 11 Full Copyright Statement
2169 Copyright (C) The Internet Society (2003). All Rights Reserved.
2171 This document and translations of it may be copied and furnished to
2172 others, and derivative works that comment on or otherwise explain it
2173 or assist in its implementation may be prepared, copied, published
2174 and distributed, in whole or in part, without restriction of any
2175 kind, provided that the above copyright notice and this paragraph are
2176 included on all such copies and derivative works. However, this
2177 document itself may not be modified in any way, such as by removing
2178 the copyright notice or references to the Internet Society or other
2179 Internet organizations, except as needed for the purpose of
2180 developing Internet standards in which case the procedures for
2181 copyrights defined in the Internet Standards process must be
2182 followed, or as required to translate it into languages other than
2185 The limited permissions granted above are perpetual and will not be
2186 revoked by the Internet Society or its successors or assigns.
2188 This document and the information contained herein is provided on an
2189 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2190 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2191 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2192 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2193 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2197 Funding for the RFC Editor function is currently provided by the
2218 Leach & Newman Expires: December 2003 [Page 37]
2224 INTERNET DRAFT Digest SASL Mechanism June 2003
2227 Appendix A: Changes from 2831
2229 1). Fixed various typos in formulas.
2231 2). Dropped DES as mandatory to implement cipher (3DES is mandatory
2234 3). Tighten ABNF. Fixed some bugs.
2236 4). Clarified nc-value verification and which side is aborting
2239 5). Added text saying that for interoperability
2240 username/password/realm MUST be prepared using the "SASLPrep" profile
2241 [SASLPrep] of the "stringprep" algorithm [StringPrep].
2243 6). Clarified that unquoted version of the username, etc. used in A1
2246 7). Various cleanup to References section. Split all references to
2247 Normative and Informative.
2249 8). Added minimal and maximal limits on maxbuf. Clarified how to
2250 calculate max sender size.
2252 9). Change ABNF for host to allow for IPv6 addresses. ABNF now
2253 references RFC 2373 and RFC 2396.
2255 10). Added DES cipher interoperability section.
2257 11). Added man-in-the-middle considerations for ciphers.
2259 12). Clarified how sequence counters are modified.
2261 13). Addition warnings about preventing reply/redirection attacks.
2263 14). Specified that "charset" directive affects "realm" and doesn't
2267 15). Removed text that described that "authzid" is in Unicode in
2269 Form KC, encoded as UTF-8.
2271 16). Clarified that rc4 state is not reset between two sent/received
2278 Leach & Newman Expires: December 2003 [Page 38]
2284 INTERNET DRAFT Digest SASL Mechanism June 2003
2287 17). Clarified that for DES/3DES the IV for the next buffer of
2289 the last 8 bytes of the ciphertext.
2291 18). Clarified how "maximal sender size" is calculated.
2293 19). Prohibit an empty authzid.
2295 20). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL
2297 document (expired draft-ietf-sasl-digest-aes-00.txt).
2299 21). Minor text clarifications.
2301 Appendix B: Open Issues/ToDo List
2303 1). The latest revision prohibits escaped characters in nonce/cnonce.
2305 from HTTP Digest. Any objections?
2307 2). Do we need/want a new stringprep profile for "realm"?
2309 3). What to do about CBC mode attack that affects TLS document and
2312 One of the proposals is to drop DES/3DES ciphers and define a new one
2313 (e.g. AES) in such a way that is not susceptible to this kind of
2316 AES cipher has to be fixed to prevent this attack.
2318 4). Add reference to CBC mode attack:
2320 This problem is described in LASEC Memo "Password Interception in a
2321 SSL/TLS Channel" by Brice Canvel, published 2003-02-20:
2322 http://lasecwww.epfl.ch/memo_ssl.shtml
2324 5). Normative vs. Informative references must be carefully rechecked.
2338 Leach & Newman Expires: December 2003 [Page 39]