its value SHOULD be one of those realms. If the directive is      missing, "realm-value" will set to the empty string when computing      A1 (see below for details).   nonce      The server-specified data string received in the preceding      digest-challenge. This directive is required and MUST be present      exactly once; otherwise, authentication fails.Leach & Newman              Standards Track                     [Page 7]RFC 2831                 Digest SASL Mechanism                  May 2000   cnonce      A client-specified data string which MUST be different each time a      digest-response is sent as part of initial authentication. The      cnonce-value is an opaque quoted string value provided by the      client and used by both client and server to avoid chosen      plaintext attacks, and to provide mutual authentication. The      security of the implementation depends on a good choice. It is      RECOMMENDED that it contain at least 64 bits of entropy. This      directive is required and MUST be present exactly once; otherwise,      authentication fails.   nonce-count      The nc-value is the hexadecimal count of the number of requests      (including the current request) that the client has sent with the      nonce value in this request.  For example, in the first request      sent in response to a given nonce value, the client sends      "nc=00000001". The purpose of this directive is to allow the      server to detect request replays by maintaining its own copy of      this count - if the same nc-value is seen twice, then the request      is a replay.   See the description below of the construction of      the response value. This directive may appear at most once; if      multiple instances are present, the client should abort the      authentication exchange.   qop      Indicates what "quality of protection" the client accepted. If      present, it may appear exactly once and  its value MUST be one of      the alternatives in qop-options. If not present, it defaults to      "auth". These values affect the computation of the response. Note      that this is a single token, not a quoted list of alternatives.   serv-type      Indicates the type of service, such as "www" for web service,      "ftp" for FTP service, "smtp" for mail delivery service, etc. The      service name as defined in the SASL profile for the protocol see      section 4 of [RFC 2222], registered in the IANA registry of      "service" elements for the GSSAPI host-based service name form      [RFC 2078].   host      The DNS host name or IP address for the service requested.  The      DNS host name must be the fully-qualified canonical name of the      host. The DNS host name is the preferred form; see notes on server      processing of the digest-uri.Leach & Newman              Standards Track                     [Page 8]RFC 2831                 Digest SASL Mechanism                  May 2000   serv-name      Indicates the name of the service if it is replicated. The service      is considered to be replicated if the client's service-location      process involves resolution using standard DNS lookup operations,      and if these operations involve DNS records (such as SRV, or MX)      which resolve one DNS name into a set of other DNS names. In this      case, the initial name used by the client is the "serv-name", and      the final name is the "host" component. For example, the incoming      mail service for "example.com" may be replicated through the use      of MX records stored in the DNS, one of which points at an SMTP      server called "mail3.example.com"; it's "serv-name" would be      "example.com", it's "host" would be "mail3.example.com". If the      service is not replicated, or the serv-name is identical to the      host, then the serv-name component MUST be omitted.   digest-uri      Indicates the principal name of the service with which the client      wishes to connect, formed from the serv-type, host, and serv-name.      For example, the FTP service on "ftp.example.com" would have a      "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from      the example above would have a "digest-uri" value of      "smtp/mail3.example.com/example.com".   Servers SHOULD check that the supplied value is correct. This will   detect accidental connection to the incorrect server. It is also so   that clients will be trained to provide values that will work with   implementations that use a shared back-end authentication service   that can provide server authentication.   The serv-type component should match the service being offered. The   host component should match one of the host names of the host on   which the service is running, or it's IP address. Servers SHOULD NOT   normally support the IP address form, because server authentication   by IP address is not very useful; they should only do so if the DNS   is unavailable or unreliable. The serv-name component should match   one of the service's configured service names.   This directive may appear at most once; if multiple instances are   present, the client should abort the authentication exchange.   Note: In the HTTP use of Digest authentication, the digest-uri is the   URI (usually a URL) of the resource requested -- hence the name of   the directive.   response      A string of 32 hex digits computed as defined below, which proves      that the user knows a password. This directive is required and      MUST be present exactly once; otherwise, authentication fails.Leach & Newman              Standards Track                     [Page 9]RFC 2831                 Digest SASL Mechanism                  May 2000   maxbuf      A number indicating the size of the largest buffer the client is      able to receive. If this directive is missing, the default value      is 65536. This directive may appear at most once; if multiple      instances are present, the server should abort the authentication      exchange.   charset      This directive, if present, specifies that the client has used      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 client should send this directive only      if the server has indicated it supports UTF-8. The directive is      needed for backwards compatibility with HTTP Digest, which only      supports ISO 8859-1.   LHEX      32 hex digits, where the alphabetic characters MUST be lower case,      because MD5 is not case insensitive.   cipher      The cipher chosen by the client. This directive MUST appear      exactly once if "auth-conf" is negotiated; if required and not      present, authentication fails.   authzid      The "authorization ID" as per RFC 2222, encoded in UTF-8. This      directive is optional. If present, and the authenticating user has      sufficient privilege, and the server supports it, then after      authentication the server will use this identity for making all      accesses and access checks. If the client specifies it, and the      server does not support it, then the response-value will be      incorrect, and authentication will fail.   The size of a digest-response MUST be less than 4096 bytes.2.1.2.1   Response-value   The definition of "response-value" above indicates the encoding for   its value -- 32 lower case hex characters. The following definitions   show how the value is computed.   Although qop-value and components of digest-uri-value may be   case-insensitive, the case which the client supplies in step two is   preserved for the purpose of computing and verifying the   response-value.      response-value  =Leach & Newman              Standards Track                    [Page 10]RFC 2831                 Digest SASL Mechanism                  May 2000         HEX( KD ( HEX(H(A1)),                 { nonce-value, ":" nc-value, ":",                   cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))   If authzid is specified, then A1 is      A1 = { H( { username-value, ":", realm-value, ":", passwd } ),           ":", nonce-value, ":", cnonce-value, ":", authzid-value }   If authzid is not specified, then A1 is      A1 = { H( { username-value, ":", realm-value, ":", passwd } ),           ":", nonce-value, ":", cnonce-value }   where         passwd   = *OCTET   The "username-value", "realm-value" and "passwd" are encoded   according to the value of the "charset" directive. If "charset=UTF-8"   is present, and all the characters of either "username-value" or   "passwd" are in the ISO 8859-1 character set, then it must be   converted to ISO 8859-1 before being hashed. This is so that   authentication databases that store the hashed username, realm and   password (which is common) can be shared compatibly with HTTP, which   specifies ISO 8859-1. A sample implementation of this conversion is   in section 8.   If the "qop" directive's value is "auth", then A2 is:      A2       = { "AUTHENTICATE:", digest-uri-value }   If the "qop" value is "auth-int" or "auth-conf" then A2 is:      A2       = { "AUTHENTICATE:", digest-uri-value,               ":00000000000000000000000000000000" }   Note that "AUTHENTICATE:" must be in upper case, and the second   string constant is a string with a colon followed by 32 zeros.   These apparently strange values of A2 are for compatibility with   HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and   the hash of the entity body to zero in the HTTP digest calculation of   A2.   Also, in the HTTP usage of Digest, several directives in theLeach & Newman              Standards Track                    [Page 11]RFC 2831                 Digest SASL Mechanism                  May 2000   "digest-challenge" sent by the server have to be returned by the   client in the "digest-response". These are:    opaque    algorithm   These directives are not needed when Digest is used as a SASL   mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).2.1.3  Step Three   The server receives and validates the "digest-response". The server   checks that the nonce-count is "00000001". If it supports subsequent   authentication (see section 2.2), it saves the value of the nonce and   the nonce-count. It sends a message formatted as follows:    response-auth = "rspauth" "=" response-value   where response-value is calculated as above, using the values sent in   step two, except that if qop is "auth", then A2 is       A2 = { ":", digest-uri-value }   And if qop is "auth-int" or "auth-conf" then A2 is       A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }   Compared to its use in HTTP, the following Digest directives in the   "digest-response" are unused:       nextnonce       qop       cnonce       nonce-count2.2  Subsequent Authentication   If the client has previously authenticated to the server, and   remembers the values of username, realm, nonce, nonce-count, cnonce,   and qop that it used in that authentication, and the SASL profile for   a protocol permits an initial client response, then it MAY perform   "subsequent authentication", as defined in this section.Leach & Newman              Standards Track                    [Page 12]RFC 2831                 Digest SASL Mechanism                  May 20002.2.1  Step one   The client uses the values from the previous authentication and sends   an initial response with a string formatted and computed according to   the rules for a "digest-response", as defined above, but with a   nonce-count one greater than used in the last "digest-response".2.2.2  Step Two   The server receives the "digest-response". If the server does not   support subsequent authentication, then it sends a   "digest-challenge", and authentication proceeds as in initial   authentication. If the server has no saved nonce and nonce-count from   a previous authentication, then it sends a "digest-challenge", and   authentication proceeds as in initial authentication. Otherwise, the   server validates the "digest-response", checks that the nonce-count   is one greater than that used in the previous authentication using   that nonce, and saves the new value of nonce-count.   If the response is invalid, then the server sends a   "digest-challenge", and authentication proceeds as in initial   authentication (and should be configurable to log an authentication   failure in some sort of security audit log, since the failure may be   a symptom of an attack). The nonce-count MUST NOT be incremented in   this case: to do so would allow a denial of service attack by sending   an out-of-order nonce-count.   If the response is valid, the server MAY choose to deem that   authentication has succeeded. However, if it has been too long since   the previous authentication, or for any other reason, the server MAY   send a new "digest-challenge" with a new value for nonce. The   challenge MAY contain a "stale" directive with value "true", which   says that the client may respond to the challenge using the password   it used in the previous response; otherwise, the client must solicit   the password anew from the user. This permits the server to make sure   that the user has presented their password recently. (The directive   name refers to the previous nonce being stale, not to the last use of   the password.) Except for the handling of "stale", after sending the   "digest-challenge" authentication proceeds as in the case of initial   authentication.2.3   Integrity Protection   If the server offered "qop=auth-int" and the client responded   "qop=auth-int", then subsequent messages, up to but not including the   next subsequent authentication, between the client and the serverLeach & Newman              Standards Track                    [Page 13]RFC 2831                 Digest SASL Mechanism                  May 2000   MUST be integrity protected. Using as a base session key the value of   H(A1) as defined above the client and server calculate a pair of   message integrity keys as follows.   The key for integrity protecting messages from client to server is:   Kic = MD5({H(A1),   "Digest session key to client-to-server signing key magic constant"})   The key for integrity protecting messages from server to client is:   Kis = MD5({H(A1),   "Digest session key to server-to-client signing key magic constant"})   where MD5 is as specified in [RFC 1321]. If message integrity is   negotiated, a MAC block for each message is appended to the message.   The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC   2104] of the message, a 2-byte message type number in network byte   order with value 1, and the 4-byte sequence number in network byte   order. The message type is to allow for future extensions such as   rekeying.   MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,   SeqNum)