Network Working Group                                           P. LeachRequest for Comments: 2831                                     MicrosoftCategory: Standards Track                                      C. Newman                                                                Innosoft                                                                May 2000            Using Digest Authentication as a SASL MechanismStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2000).  All Rights Reserved.Abstract   This specification defines how HTTP Digest Authentication [Digest]   can be used as a SASL [RFC 2222] mechanism for any protocol that has   a SASL profile. It is intended both as an improvement over CRAM-MD5   [RFC 2195] and as a convenient way to support a single authentication   mechanism for web, mail, LDAP, and other protocols.Table of Contents   1 INTRODUCTION.....................................................2    1.1 CONVENTIONS AND NOTATION......................................2    1.2 REQUIREMENTS..................................................3   2 AUTHENTICATION...................................................3    2.1 INITIAL AUTHENTICATION........................................3     2.1.1 Step One...................................................3     2.1.2 Step Two...................................................6     2.1.3 Step Three................................................12    2.2 SUBSEQUENT AUTHENTICATION....................................12     2.2.1 Step one..................................................13     2.2.2 Step Two..................................................13    2.3 INTEGRITY PROTECTION.........................................13    2.4 CONFIDENTIALITY PROTECTION...................................14   3 SECURITY CONSIDERATIONS.........................................15    3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........15    3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................16    3.3 REPLAY ATTACKS...............................................16Leach & Newman              Standards Track                     [Page 1]RFC 2831                 Digest SASL Mechanism                  May 2000    3.4 ONLINE DICTIONARY ATTACKS....................................16    3.5 OFFLINE DICTIONARY ATTACKS...................................16    3.6 MAN IN THE MIDDLE............................................17    3.7 CHOSEN PLAINTEXT ATTACKS.....................................17    3.8 SPOOFING BY COUNTERFEIT SERVERS..............................17    3.9 STORING PASSWORDS............................................17    3.10 MULTIPLE REALMS.............................................18    3.11 SUMMARY.....................................................18   4 EXAMPLE.........................................................18   5 REFERENCES......................................................20   6 AUTHORS' ADDRESSES..............................................21   7 ABNF............................................................21    7.1 AUGMENTED BNF................................................21    7.2 BASIC RULES..................................................23   8 SAMPLE CODE.....................................................25   9 FULL COPYRIGHT STATEMENT........................................271  Introduction   This specification describes the use of HTTP Digest Access   Authentication as a SASL mechanism. The authentication type   associated with the Digest SASL mechanism is "DIGEST-MD5".   This specification is intended to be upward compatible with the   "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication   specified in [Digest]. The only difference in the "md5-sess"   algorithm is that some directives not needed in a SASL mechanism have   had their values defaulted.   There is one new feature for use as a SASL mechanism: integrity   protection on application protocol messages after an authentication   exchange.   Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext   attacks, and permits the use of third party authentication servers,   mutual authentication, and optimized reauthentication if a client has   recently authenticated to a server.1.1  Conventions and Notation   This specification uses the same ABNF notation and lexical   conventions as HTTP/1.1 specification; see appendix A.   Let { a, b, ... } be the concatenation of the octet strings a, b, ...   Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.Leach & Newman              Standards Track                     [Page 2]RFC 2831                 Digest SASL Mechanism                  May 2000   Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string   k, a colon and the string s.   Let HEX(n) be the representation of the 16 octet MD5 hash n as a   string of 32 hex digits (with alphabetic characters always in lower   case, since MD5 is case sensitive).   Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet   string s using the octet string k as a key.   The value of a quoted string constant as an octet string does not   include any terminating null character.1.2  Requirements   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in RFC 2119 [RFC 2119].   An implementation is not compliant if it fails to satisfy one or more   of the MUST level requirements for the protocols it implements. An   implementation that satisfies all the MUST level and all the SHOULD   level requirements for its protocols is said to be "unconditionally   compliant"; one that satisfies all the MUST level requirements but   not all the SHOULD level requirements for its protocols is said to be   "conditionally compliant."2  Authentication   The following sections describe how to use Digest as a SASL   authentication mechanism.2.1  Initial Authentication   If the client has not recently authenticated to the server, then it   must perform "initial authentication", as defined in this section. If   it has recently authenticated, then a more efficient form is   available, defined in the next section.2.1.1  Step One   The server starts by sending a challenge. The data encoded in the   challenge contains a string formatted according to the rules for a   "digest-challenge" defined as follows:Leach & Newman              Standards Track                     [Page 3]RFC 2831                 Digest SASL Mechanism                  May 2000   digest-challenge  =         1#( realm | nonce | qop-options | stale | maxbuf | charset               algorithm | cipher-opts | auth-param )        realm             = "realm" "=" <"> realm-value <">        realm-value       = qdstr-val        nonce             = "nonce" "=" <"> nonce-value <">        nonce-value       = qdstr-val        qop-options       = "qop" "=" <"> qop-list <">        qop-list          = 1#qop-value        qop-value         = "auth" | "auth-int" | "auth-conf" |                             token        stale             = "stale" "=" "true"        maxbuf            = "maxbuf" "=" maxbuf-value        maxbuf-value      = 1*DIGIT        charset           = "charset" "=" "utf-8"        algorithm         = "algorithm" "=" "md5-sess"        cipher-opts       = "cipher" "=" <"> 1#cipher-value <">        cipher-value      = "3des" | "des" | "rc4-40" | "rc4" |                            "rc4-56" | token        auth-param        = token "=" ( token | quoted-string )   The meanings of the values of the directives used above are as   follows:   realm      Mechanistically, a string which can enable users to know which      username and password to use, in case they might have different      ones for different servers. Conceptually, it is the name of a      collection of accounts that might include the user's account. This      string should contain at least the name of the host performing the      authentication and might additionally indicate the collection of      users who might have access. An example might be      "registered_users@gotham.news.example.com".  This directive is      optional; if not present, the client SHOULD solicit it from the      user or be able to compute a default; a plausible default might be      the realm supplied by the user when they logged in to the client      system. Multiple realm directives are allowed, in which case the      user or client must choose one as the realm for which to supply to      username and password.   nonce      A server-specified data string which MUST be different each time a      digest-challenge is sent as part of initial authentication.  It is      recommended that this string be base64 or hexadecimal data. Note      that since the string is passed as a quoted string, the      double-quote character is not allowed unless escaped (see section      7.2). The contents of the nonce are implementation dependent. TheLeach & Newman              Standards Track                     [Page 4]RFC 2831                 Digest SASL Mechanism                  May 2000      security of the implementation depends on a good choice. It is      RECOMMENDED that it contain at least 64 bits of entropy. The nonce      is opaque to the client. This directive is required and MUST      appear exactly once; if not present, or if multiple instances are      present, the client should abort the authentication exchange.   qop-options      A quoted string of one or more tokens indicating the "quality of      protection" values supported by the server.  The value "auth"      indicates authentication; the value "auth-int" indicates      authentication with integrity protection; the value "auth-conf"      indicates authentication with integrity protection and encryption.      This directive is optional; if not present it defaults to "auth".      The client MUST ignore unrecognized options; if the client      recognizes no option, it should abort the authentication exchange.   stale      The "stale" directive is not used in initial authentication. See      the next section for its use in subsequent authentications. This      directive may appear at most once; if multiple instances are      present, the client should abort the authentication exchange.   maxbuf      A number indicating the size of the largest buffer the server is      able to receive when using "auth-int" or "auth-conf". If this      directive is missing, the default value is 65536. This directive      may appear at most once; if multiple instances are present, the      client should abort the authentication exchange.   charset      This directive, if present, specifies that the server supports      UTF-8 encoding for the username and password. If not present, the      username and password must be encoded in ISO 8859-1 (of which      US-ASCII is a subset). The directive is needed for backwards      compatibility with HTTP Digest, which only supports ISO 8859-1.      This directive may appear at most once; if multiple instances are      present, the client should abort the authentication exchange.   algorithm      This directive is required for backwards compatibility with HTTP      Digest., which supports other algorithms. . This directive is      required and MUST appear exactly once; if not present, or if      multiple instances are present, the client should abort the      authentication exchange.Leach & Newman              Standards Track                     [Page 5]RFC 2831                 Digest SASL Mechanism                  May 2000   cipher-opts      A list of ciphers that the server supports. This directive must be      present exactly once if "auth-conf" is offered in the      "qop-options" directive, in which case the "3des" and "des" modes      are mandatory-to-implement. The client MUST ignore unrecognized      options; if the client recognizes no option, it should abort the      authentication exchange.      des         the Data Encryption Standard (DES) cipher [FIPS] in cipher         block chaining (CBC) mode with a 56 bit key.      3des         the "triple DES" cipher in CBC mode with EDE with the same key         for each E stage (aka "two keys mode") for a total key length         of 112 bits.      rc4, rc4-40, rc4-56         the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,         respectively.   auth-param This construct allows for future extensions; it may appear      more than once. The client MUST ignore any unrecognized      directives.   For use as a SASL mechanism, note that the following changes are made   to "digest-challenge" from HTTP: the following Digest options (called   "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,   and MUST be ignored if received):    opaque    domain   The size of a digest-challenge MUST be less than 2048 bytes.2.1.2  Step Two   The client makes note of the "digest-challenge" and then responds   with a string formatted and computed according to the rules for a   "digest-response" defined as follows:Leach & Newman              Standards Track                     [Page 6]RFC 2831                 Digest SASL Mechanism                  May 2000   digest-response  = 1#( username | realm | nonce | cnonce |                          nonce-count | qop | digest-uri | response |                          maxbuf | charset | cipher | authzid |                          auth-param )       username         = "username" "=" <"> username-value <">       username-value   = qdstr-val       cnonce           = "cnonce" "=" <"> cnonce-value <">       cnonce-value     = qdstr-val       nonce-count      = "nc" "=" nc-value       nc-value         = 8LHEX       qop              = "qop" "=" qop-value       digest-uri       = "digest-uri" "=" <"> digest-uri-value <">       digest-uri-value  = serv-type "/" host [ "/" serv-name ]       serv-type        = 1*ALPHA       host             = 1*( ALPHA | DIGIT | "-" | "." )       serv-name        = host       response         = "response" "=" response-value       response-value   = 32LHEX       LHEX             = "0" | "1" | "2" | "3" |                          "4" | "5" | "6" | "7" |                          "8" | "9" | "a" | "b" |                          "c" | "d" | "e" | "f"       cipher           = "cipher" "=" cipher-value       authzid          = "authzid" "=" <"> authzid-value <">       authzid-value    = qdstr-val   username      The user's name in the specified realm, encoded according to the      value of the "charset" directive. This directive is required and      MUST be present exactly once; otherwise, authentication fails.   realm      The realm containing the user's account. This directive is      required if the server provided any realms in the      "digest-challenge", in which case it may appear exactly once and