INTERNET-DRAFT P. Leach Obsoletes: 2831 Microsoft Intended category: Standards track C. Newman Sun Microsystems A. Melnikov Isode Ltd. April 2005 Using Digest Authentication as a SASL Mechanism draft-ietf-sasl-rfc2831bis-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). 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. Leach & Newman Expires: October 2005 [Page 1]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 Table of Contents 1 INTRODUCTION.....................................................3 1.1 CONVENTIONS AND NOTATION......................................3 1.2 REQUIREMENTS..................................................4 2 AUTHENTICATION...................................................5 2.1 INITIAL AUTHENTICATION........................................5 2.1.1 Step One...................................................5 2.1.2 Step Two...................................................9 2.1.3 Step Three................................................16 2.2 SUBSEQUENT AUTHENTICATION....................................17 2.2.1 Step one..................................................17 2.2.2 Step Two..................................................17 2.3 INTEGRITY PROTECTION.........................................18 2.4 CONFIDENTIALITY PROTECTION...................................18 3 SECURITY CONSIDERATIONS.........................................21 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21 3.3 REPLAY ATTACKS...............................................21 3.4 ONLINE DICTIONARY ATTACKS....................................22 3.5 OFFLINE DICTIONARY ATTACKS...................................22 3.6 MAN IN THE MIDDLE............................................22 3.7 CHOSEN PLAINTEXT ATTACKS.....................................22 3.8 CBC MODE ATTACKS............................................. 3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23 3.10 STORING PASSWORDS...........................................23 3.11 MULTIPLE REALMS.............................................24 3.12 SUMMARY.....................................................24 4 EXAMPLE.........................................................24 5 REFERENCES......................................................26 5.1 NORMATIVE REFERENCES.........................................26 5.2 INFORMATIVE REFERENCES.......................................27 6 AUTHORS' ADDRESSES..............................................28 7 ABNF............................................................29 7.1 AUGMENTED BNF................................................29 7.2 BASIC RULES..................................................31 8 SAMPLE CODE.....................................................33 10 ACKNOWLEDGEMENTS..............................................34 11 FULL COPYRIGHT STATEMENT.......................................35 Appendix A: Changes from 2831.....................................36 Appendix B: Open Issues...........................................37 <<Page numbers are all wrong, sorry>> Leach & Newman Expires: October 2005 [Page 2]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 1 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 section 7. Let { a, b, ... } be the concatenation of the octet strings a, b, ... Let ** denote the power operation. Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s. 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. Leach & Newman Expires: October 2005 [Page 3]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 Let unq(X) be the value of the quoted-string X without the surrounding quotes and with all escape characters "\\" removed. For example for the quoted-string "Babylon" the value of unq("Babylon") is Babylon; for the quoted string "ABC\"123\\" the value of unq("ABC\"123\\") is ABC"123\. The value of a quoted string constant as an octet string does not include any terminating null character. <<Other terms like "protocol profile" are defined in RFC2222.>> 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." Leach & Newman Expires: October 2005 [Page 4]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 2 Authentication DIGEST-MD5 can operate in two modes. Initial authentication (section 2.1) is usually used when a client authenticates to a server for the first time. If protocol profile supports initial client response (see "Protocol profile requirements" in [RFC 2222]) and the client supports reauthentication and it has successfully authenticated to the server before, the client may be able to use the more efficient fast reauthentication mode as described in section 2.2. The following sections describe these two modes in details. 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 is formatted according to the rules for the "digest- challenge" defined as follows: Leach & Newman Expires: October 2005 [Page 5]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 digest-challenge = 1#( realm | nonce | qop-options | stale | server_maxbuf | charset algorithm | cipher-opts | auth-param ) realm = "realm" "=" <"> realm-value <"> realm-value = qdstr-val nonce = "nonce" "=" <"> nonce-value <"> nonce-value = *qdtext qop-options = "qop" "=" <"> qop-list <"> qop-list = 1#qop-value qop-value = "auth" | "auth-int" | "auth-conf" | qop-token ;; qop-token is reserved for identifying future ;; extensions to DIGEST-MD5 qop-token = token stale = "stale" "=" "true" server_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" | "aes-cbc" | cipher-token ;; "des" and "3des" ciphers are obsolete. ;; cipher-token is reserved for new ciphersuites cipher-token = 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 enables users to decide which username and password to use, in case they 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 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". Note that the server MAY not advertise some or all realms it supports. Other examples: 1) "dc=gotham, dc=news, dc=example, dc=com". 2) If there are two servers (e.g. server1.example.com and server2.example.com) that share authentication database, they Leach & Newman Expires: October 2005 [Page 6]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 both may advertise "example.com" as the realm. A server implementation that uses a fixed string as the advertised realm is compliant with this specification, however this is not recommended. See also sections 3.10 "Storing passwords" and 3.11 "Multiple realms" for discussion. The value of this directive is case-sensitive. 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 username and password. Requirements on UIs: UIs MUST allow users to enter arbitrary user names and realm names. In order to achieve this, UIs MAY present two separate edit boxes. Alternatively, UIs MAY present a single edit box and allow user to enter a special character that separates user name from the realm name. In the latter case, UIs MUST be able to escape the special character and they need to present their escape rules to the user. UIs MUST also present the list of realms advertised by the server. If at least one realm is present and the charset directive is also specified (which means that realm(s) are encoded as UTF-8), the client SHOULD prepare each instance of realm using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If preparation of a realm instance fails or results in an empty string (unless the realm instance was the empty string), the client SHOULD abort the authentication exchange. Note, that if the client picks one of the realms provided by the server, it MUST send it exactly as received from the server, even if the prepared version of the realm differs from the received version. 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 the whole string is enclosed in double-quote characters, however quote-characters or escape characters are not allowed in the string, even when quoted. This is different from the RFC 2821. The contents of the nonce are implementation dependent. The security of the implementation depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy. The nonce Leach & Newman Expires: October 2005 [Page 7]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 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 comma-separated 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 MUST abort the authentication exchange. <<What if this directive is present multiple times? Error, or take the union of all values?>> 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 MUST abort the authentication exchange. server_maxbuf ("maximal ciphertext buffer size") A number indicating the size of the largest buffer (in bytes) the server is able to receive when using "auth-int" or "auth-conf". The value MUST be bigger than 16 (32 for Confidentiality protection with the "aes-cbc" cipher) and smaller or equal to 16777215 (i.e. 2**24-1). If this directive is missing, the default value is 65536. This directive may appear at most once; if multiple instances are present, or the value is out of range the client MUST abort the authentication exchange. Let "maximal cleartext buffer size" (or "maximal sender size") be the maximal size of a cleartext buffer that, after being transformed by integrity (section 2.3) or confidentiality (section 2.4) protection function, will produce a SASL block of the maxbuf size. As it should be clear from the name, the sender MUST never pass a block of data bigger than the "maximal sender size" through the selected protection function. This will guarantee that the receiver will never get a block bigger than the maxbuf. Leach & Newman Expires: October 2005 [Page 8]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 charset This directive, if present, specifies that the server supports UTF-8 [UTF-8] encoding for the username, realm and password. If present, the username, realm and password are in Unicode, prepared using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454] and than encoded as UTF-8 [UTF-8]. If not present, the username, realm and password used by the client in Step 2 MUST be encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII [USASCII] 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 MUST abort the authentication exchange. Note, that this directive doesn't affect authorization id ("authzid"). 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. 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 "rc4" cipher is mandatory-to-implement. The client MUST ignore unrecognized ciphers; if the client recognizes no cipher, it MUST behave as if "auth-conf" qop option wasn't provided by the server. If the client recognizes no cipher and the server only advertised "auth- conf" in the qop option, the client MUST abort the authentication exchange. See section 2.4 for more detailed description of the ciphers. rc4, rc4-40, rc4-56 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively. aes-cbc the Advanced Encryption Standard (AES) cipher [AES] in cipher block chaining (CBC) mode with a 128 bit key and explicit Initialization Vector (IV). This mode requires an IV that has the same size as the block size. auth-param This construct allows for future extensions; it may appear more than once. The client MUST ignore any unrecognized directives. Leach & Newman Expires: October 2005 [Page 9]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 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: digest-response = 1#( username | realm | nonce | cnonce | nonce-count | qop | digest-uri | response | client_maxbuf | charset | cipher | authzid | auth-param ) username = "username" "=" <"> username-value <"> username-value = qdstr-val cnonce = "cnonce" "=" <"> cnonce-value <"> cnonce-value = *qdtext nonce-count = "nc" "=" nc-value nc-value = 8LHEX client_maxbuf = "maxbuf" "=" maxbuf-value qop = "qop" "=" qop-value digest-uri = "digest-uri" "=" <"> digest-uri-value <"> digest-uri-value = serv-type "/" host [ "/" serv-name ] serv-type = 1*ALPHA 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 The 'host' non-terminal is defined in [RFC 2732] as host = hostname | IPv4address | IPv6reference ipv6reference = "[" IPv6address "]" Leach & Newman Expires: October 2005 [Page 10]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 where IPv6address and IPv4address are defined in [RFC 2373] and 'hostname' is defined in [RFC 2396]. 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. If the charset directive is also specified (which means that the username is encoded as UTF-8) The client MUST first check if all the characters of the username are in the ISO 8859-1 character set. If they are, no further changes are performed. Otherwise, the client MUST prepare the username using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If the preparation of the username fails or results in an empty string, the client SHOULD abort the authentication exchange. If the preparation succeeds, the prepared value will be sent to the server. Upon the receipt of this value and if the charset directive is also specified (which means that the username is encoded as UTF-8), the server MUST prepare the username using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If preparation of the username fails or results in an empty string, the server MUST fail the authentication exchange. realm The realm containing the user's account, encoded according to the value of the "charset" directive. This directive is required if the server provided any realms in the "digest-challenge", in which case it may appear exactly once and 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). If realm was provided by the client and if the charset directive was also specified (which means that the realm is encoded as UTF-8), the server MUST prepare the realm using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. If preparation of the realm fails or results in an empty string (unless already the empty string), the server MUST fail the authentication exchange. <<The server has to do this only if the client has sent a realm, that wasn't one of realms advertised by the server>> nonce The server-specified data string received in the preceding digest- Leach & Newman Expires: October 2005 [Page 11]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 challenge. This directive is required and MUST be present exactly once; otherwise, authentication fails. 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. Note that the whole string is enclosed in double-quote characters, however quote-characters or escape characters are not allowed in the string, even when quoted. This is different from the RFC 2821. 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 is required and MUST be present exactly once; otherwise, or if the value is 0, authentication fails. 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 "http" 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 (IPv4 or IPv6) address for the service requested. The DNS host name must be the fully-qualified Leach & Newman Expires: October 2005 [Page 12]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 canonical name of the host. The DNS host name is the preferred form; see notes on server processing of the digest-uri. 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 [RFC 2052], 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, as well as some redirection attacks. 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 is required and MUST be present exactly once; if multiple instances are present, the server MUST 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 Leach & Newman Expires: October 2005 [Page 13]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 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. client_maxbuf A number indicating the size of the largest ciphertext buffer the client 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 server MUST abort the authentication exchange. If the value is less or equal to 16 (<<32 for aes-cbc>>) or bigger than 16777215 (i.e. 2**24-1), the server MUST abort the authentication exchange. Upon processing/sending of the client_maxbuf value both the server and the client calculate their "maximal ciphertext buffer size" as the minimum of the server_maxbuf (Step One) and the client_maxbuf (Step Two). The "maximal sender size" can be calculated by subtracting 16 (<<32 for aes-cbc>>) from the calculated "maximal ciphertext buffer size". When sending a block of data the client/server MUST NOT pass more than the "maximal sender size" bytes of data to the selected protection function (2.3 or 2.4). charset This directive, if present, specifies that the client has used UTF-8 [UTF-8] encoding for the username, realm and password. If present, the username, realm and password are in Unicode, prepared using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454] and than encoded as UTF-8 [UTF-8]. If not present, the username and password must be encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset). The client should send this directive only if the server has indicated it supports UTF-8 [UTF-8]. The directive is needed for backwards compatibility with HTTP Digest, which only supports ISO 8859-1. <<Need to explain, that SASLPrep on "realm" is ONLY performed when the client selected a realm itself (the server hasn't provided any). If the server has sent a list of realms and the client has picked one of them, the client MUST NOT change the selected realm (i.e. MUST NOT SASLPrep it).>> Note, that this directive doesn't affect authorization id Leach & Newman Expires: October 2005 [Page 14]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 ("authzid"). 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. If the cipher chosen by the client is not one of the ciphers advertised by the server, authentication fails. authzid The "authorization ID" (authzid) directive may appear at most once; if multiple instances are present, the server MUST abort the authentication exchange. 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 calculated on the server will not match the one calculated on the client and authentication will fail. The authzid MUST NOT be an empty string. The authorization identifier MUST NOT be converted to ISO 8859-1 even if the authentication identifier ("username") is converted for compatibility as directed by "charset" directive. The server SHOULD verify the correctness of an authzid as specified by the corresponding SASL protocol profile. 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 = HEX( KD ( HEX(H(A1)), Leach & Newman Expires: October 2005 [Page 15]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 { nonce-value, ":" nc-value, ":", cnonce-value, ":", qop-value, ":", HEX(H(A2)) })) If authzid is specified, then A1 is A1 = { SS, ":", nonce-value, ":", cnonce-value, ":", unq(authzid-value) } If authzid is not specified, then A1 is A1 = { SS, ":", nonce-value, ":", cnonce-value } where passwd = *OCTET SS = H( { unq(username-value), ":", unq(realm-value), ":", passwd } ) <<Note about empty authzid-value versa missing authzid-value and how this affects hash>> 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 "username-value" are, before preparing using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454], in the ISO 8859-1 character set, then it must be converted to ISO 8859-1 before being hashed (and no SASLPrep is to be done). Otherwise the SASLPrep MUST be performed. The same transformation has to be done for "realm-value" (only if the "realm- value" was obtained by the client). If the "realm-value" was picked from a list of realms supported by the server, it MUST NOT be prepared with SASLPrep) and "passwd". 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 } Leach & Newman Expires: October 2005 [Page 16]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 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 the "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: auth-info = 1#( response-auth | auth-param ) 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" } Note that only one occurance of the "response-auth" is allowed. If more than one is found, the client MUST treat this as an authentication error. Compared to its use in HTTP, the following Digest directives in the Leach & Newman Expires: October 2005 [Page 17]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 "auth-info" are unused: nextnonce qop cnonce nonce-count The size of an auth-info MUST be less than 2048 bytes. 2.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" or "fast reauthentication", as defined in this section. Note, that a subsequent authentication can be done on a different connection, or on the same connection, if the protocol profile also permits multiple authentications. 2.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 Leach & Newman Expires: October 2005 [Page 18]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 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 server 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) where Ki is Kic for messages sent by the client and Kis for those sent by the server. The sequence number (SeqNum) is an unsigned number initialized to zero after initial or subsequent authentication, and incremented by one for each message sent/successfully verified. (Note, that there are two independent Leach & Newman Expires: October 2005 [Page 19]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 counters for sending and receiving.) The sequence number wraps around to 0 after 2**32-1. Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the received value; the message is discarded if they differ and as the result the connection being used MUST be dropped. The receiver's sequence counter is incremented if they match. 2.4 Confidentiality Protection If the server sent a "cipher-opts" directive and the client responded with a "cipher" directive, then subsequent messages between the client and the server MUST be confidentiality 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 confidentiality protecting messages from client to server is: Kcc = MD5({H(A1)[0..n-1], "Digest H(A1) to client-to-server sealing key magic constant"}) The key for confidentiality protecting messages from server to client is: Kcs = MD5({H(A1)[0..n-1], "Digest H(A1) to server-to-client sealing key magic constant"}) where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*" and "aes-cbc" ciphers is all 16 bytes of Kcc or Kcs. "aes-cbc" cipher works as described in section 2.4.1. rc4 cipher state MUST NOT be reset before sending/receiving a next buffer of protected data. If the blocksize of the chosen cipher is not 1 byte, the padding prefix is one or more octets each containing the number of padding bytes, such that the total length of the encrypted part of the message is a multiple of the blocksize. The MAC block is 16 bytes formatted as follows: 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. Leach & Newman Expires: October 2005 [Page 20]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 <<Proposal 1 ("explicit IV in each SASL block") is detailed below>> The padding and first 10 bytes of the MAC block are encrypted with the chosen cipher along with the message and explicit IV (if present). SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {exp_iv, msg, pad, MAC}) MAC(Ki, SeqNum, exp_iv, msg) = {HMAC(Ki, {SeqNum, exp_iv, msg})[0..9], packet_type_data, SeqNum} packet_type_data = 0x0001 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for messages sent by the client and Kis and Kcs for those sent by the server, exp_iv is empty string for rc4 ciphers and a randomly generated number R of the length 128 bit for the "aes-cbc" cipher. The sequence number (SeqNum) is an unsigned number initialized to zero after initial or subsequent authentication, and incremented by one for each message sent/successfully verified. (Note, that there are two independent counters for sending and receiving.) The sequence number wraps around to 0 after 2**32-1. Upon receipt, the message is decrypted, exp_iv is ignored (for the "aes-cbc" cipher only), HMAC(Ki, {SeqNum, msg}) is computed and compared with the received value; the padding and the packet type are verified. The message is discarded if the received and the calculated HMACs differ and/or the padding is invalid. See also section 3.8 for important information about MAC and padding verification. The receiver's sequence counter is then compared with the received SeqNum value; the message is discarded if they differ and, as the result, the connection being used MUST be dropped. The receiver's sequence counter is incremented if they match. <<Proposal 2 ("explicit IV in a separate SASL block") is detailed below: Instead of sending a single SASL block that contains encrypted (128bit of entropy, followed by cleartext), we can introduce a new block type, that will only contain the entropy. Clients that have limited CPU resources (or operate on a slow link) might choose to send these special blocks not for every block of encrypted data, but for every second (third, ...) block. So, instead of sending a single block SEAL(Ki, Kc, SeqNum, msg) described aboves there are two types of blocks: Leach & Newman Expires: October 2005 [Page 21]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 the first is a data block as in revision 02: SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {msg, pad2, MAC}) MAC(Ki, SeqNum, msg) = {HMAC(Ki, {SeqNum, msg})[0..9], packet_type_data, SeqNum} packet_type_data = 0x0001 the second block type has a different type and contains encrypted IV: SEAL_IV(Ki, Kc, SeqNum) = CIPHER(Kc, {exp_iv, pad1, MAC_IV}) MAC_IV(Ki, SeqNum, exp_iv) = {HMAC(Ki, {SeqNum, exp_iv})[0..9], packet_type_iv, SeqNum} packet_type_iv = 0x0002 The second block is also protected by MAC that includes SeqNum. So, removing/replacing it will invalidate subsequent blocks. Advantages of this approach: 1) Less intrusive changes to already deployed code. Adding new block type might be easier. Also, the minimal block size is always 16 (with the proposal #1 it is either 16 or 32). 2) Clients that want to sacrifice a bit of security in order to achieve faster performance can choose to send SEAL_IV blocks less frequently. Of course I am not a cryptographer, to judge if there are any issues with the alternative proposal.>> 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 1] Unlike previous versions of DIGEST-MD5, this document uses an explicit IV for ciphers in CBC mode. This is done in order to prevent the attacks described by [CBCATT]. For each buffer of cleartext data to be encrypted the sender performs the following procedure: 0) For the very first SASL packet sent the IV is calculated as follows: The IV for the first SASL packet going from the client to the server (IVc) consists of 16 bytes calculated as follows: IVc = MD5({Kcc, "aes-128"}) The IV for the first SASL packet going from the server to the client (IVs) consists of 16 bytes calculated as follows: IVs = MD5({Kcs, "aes-128"}) Leach & Newman Expires: October 2005 [Page 22]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 For a subsequent packet: Em of the previous packet (see below) becomes the IV. 1) Generate a cryptographically strong random number R of length 128 bits (16 octets) and prepend it to the plaintext prior to encryption. 2) padding and MAC block are constructed (see section 2.4) and appended to the end of the plaintext. After this step the data to be encrypted will look like: {R, msg, pad, MAC} As the total length of the data will be multiple of AES block size (i.e. 128 bit), this can also be represented as {P1, P2, P3, ..., Pm} where Pi is a chunk of data of the length 128 bit. Note, that P1 is R. 3) Data is encrypted as follows: E1 = CIPHER ( Kc, P1 XOR IV ) E2 = CIPHER ( Kc, P2 XOR E1 ) E3 = CIPHER ( Kc, P3 XOR E2 ) ... Ei = CIPHER ( Kc, Pi XOR Ei-1) ... Em = CIPHER ( Kc, Pm XOR Em-1) This will generate ciphertext {E1, ..., Em} to be sent as a single SASL packet. The receiver performs the following steps: 0) For the very first SASL packet sent the IV is calculated as in step 0 for the sender. For a subsequent packet: Em of the previous packet becomes the IV of the immediately following packet. 1) Data is decrypted as follows: P1 = CIPHER ( Kc, E1 ) XOR IV P2 = CIPHER ( Kc, E2 ) XOR E1 P3 = CIPHER ( Kc, E3 ) XOR E2 Leach & Newman Expires: October 2005 [Page 23]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 ... Pi = CIPHER ( Kc, Ei ) XOR Ei-1 ... Pm = CIPHER ( Kc, Em ) XOR Em-1 Em becomes the IV for the decryption of the subsequent SASL packet. This will generate plaintext {P1, ..., Pm}. P1 is discarded, {P2, ..., Pm} is {msg, pad, MAC}. 2) pad and MAC block are verified as described in section 2.4. 2.4.1 AES cipher in CBC mode with explicit IV ("aes-cbc") [proposal 2] Unlike previous versions of DIGEST-MD5, this document uses an explicit IV for ciphers in CBC mode. This is done in order to prevent the attacks described by [CBCATT]. For each buffer of cleartext data to be encrypted the sender performs the following procedure: 0) For the very first SASL packet sent the IV is calculated as follows: The IV for the first SASL packet going from the client to the server (IVc) consists of 16 bytes calculated as follows: IVc = MD5({Kcc, "aes-128"}) The IV for the first SASL packet going from the server to the client (IVs) consists of 16 bytes calculated as follows: IVs = MD5({Kcs, "aes-128"}) For a subsequent packet: Em of the previous packet (see below) becomes the IV. 1) padding and MAC block are constructed (see section 2.4) and appended to the end of the plaintext. After this step the data to be encrypted will look like: {msg, pad, MAC} As the total length of the data will be multiple of AES block size (i.e. 128 bit), this can also be represented as {P1, P2, P3, ..., Pm} Leach & Newman Expires: October 2005 [Page 24]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 where Pi is a chunk of data of the length 128 bit. 2) Data is encrypted as follows: E1 = CIPHER ( Kc, P1 XOR IV ) E2 = CIPHER ( Kc, P2 XOR E1 ) E3 = CIPHER ( Kc, P3 XOR E2 ) ... Ei = CIPHER ( Kc, Pi XOR Ei-1) ... Em = CIPHER ( Kc, Pm XOR Em-1) This will generate ciphertext {E1, ..., Em} to be sent as a single SASL packet. In order to mitigate the attacks described in [CBCATT] the sender should periodically send a new SASL packet that affects IV. This packet is constructed as follows: 1) Generate a cryptographically strong random number R of length 128 bits (16 octets) and prepend it to the plaintext prior to encryption. 2) padding and MAC block are constructed (see section 2.4) and appended after R. After this step the data to be encrypted will look like: {R, pad, MAC_IV} As the total length of the data will be multiple of AES block size (i.e. 128 bit), this can also be represented as {P1, P2, P3, ..., Pm} where Pi is a chunk of data of the length 128 bit. 3) Data is encrypted as follows (this is exactly the same procedure as for a data packets described above): E1 = CIPHER ( Kc, P1 XOR IV ) E2 = CIPHER ( Kc, P2 XOR E1 ) E3 = CIPHER ( Kc, P3 XOR E2 ) ... Ei = CIPHER ( Kc, Pi XOR Ei-1) ... Em = CIPHER ( Kc, Pm XOR Em-1) Leach & Newman Expires: October 2005 [Page 25]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 This will generate ciphertext {E1, ..., Em} to be sent as a single SASL packet. The receiver performs the following steps: 0) For the very first SASL packet sent the IV is calculated as in step 0 for the sender. For a subsequent packet: Em of the previous packet becomes the IV of the immediately following packet. 1) Data is decrypted as follows: P1 = CIPHER ( Kc, E1 ) XOR IV P2 = CIPHER ( Kc, E2 ) XOR E1 P3 = CIPHER ( Kc, E3 ) XOR E2 ... Pi = CIPHER ( Kc, Ei ) XOR Ei-1 ... Pm = CIPHER ( Kc, Em ) XOR Em-1 Em becomes the IV for the decryption of the subsequent SASL packet. This will generate plaintext {P1, ..., Pm} or {msgX, pad, MACX}. Packet type is extracted from MACX. If the packet type is 0x0001, the plaintext represents a data block with padding and MAC. If the packet type is 0x0002, the packet contains a random value R which affects IV followed by padding and MAC_IV. The random value R is ignored by the receiver. 2) For both pad and MAC block are verified as described in section 2.4. Leach & Newman Expires: October 2005 [Page 26]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 3 Security Considerations General SASL security considerations apply to this mechanism. "stringprep" and Unicode security considerations also apply. Detailed discussion of other DIGEST-MD5 specific security issues is below. 3.1 Authentication of Clients using Digest Authentication Digest Authentication does not provide a strong authentication mechanism, when compared to public key based mechanisms, for example. However, since it prevents chosen plaintext attacks, it is stronger than (e.g.) CRAM-MD5, which has been proposed for use with ACAP [RFC 2244], POP and IMAP [RFC 2195]. It is intended to replace the much weaker and even more dangerous use of plaintext passwords; however, since it is still a password based mechanism it avoids some of the potential deployability issues with public-key, OTP or similar mechanisms. Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the challenge and response are available to an eavesdropper, including the user's name and authentication realm. 3.2 Comparison of Digest with Plaintext Passwords The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a mail service whose use is restricted to paying subscribers. With plaintext password authentication an eavesdropper can obtain the password of the user. This not only permits him to access anything in the database, but, often worse, will permit access to anything else the user protects with the same password. 3.3 Replay Attacks Replay attacks are defeated if the client or the server chooses a fresh nonce for each authentication, as this specification requires. As a security precaution, the server, when verifying a response from the client, must use the original server nonce ("nonce") it sent, not the one returned by the client in the response, as it might have been modified by an attacker. To prevent some redirection attacks it is recommended that the server verifies that the "serv-type" part of the "digest-uri" matches the Leach & Newman Expires: October 2005 [Page 27]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 service name and that the hostname/IP address belongs to the server. 3.4 Online dictionary attacks If the attacker can eavesdrop, then it can test any overheard nonce/response pairs against a (potentially very large) list of common words. Such a list is usually much smaller than the total number of possible passwords. The cost of computing the response for each password on the list is paid once for each challenge. The server can mitigate this attack by not allowing users to select passwords that are in a dictionary. 3.5 Offline dictionary attacks If the attacker can choose the challenge, then it can precompute the possible responses to that challenge for a list of common words. Such a list is usually much smaller than the total number of possible passwords. The cost of computing the response for each password on the list is paid just once. Offline dictionary attacks are defeated if the client chooses a fresh nonce for each authentication, as this specification requires. 3.6 Man in the Middle Digest authentication is vulnerable to "man in the middle" (MITM) attacks. Clearly, a MITM would present all the problems of eavesdropping. But it also offers some additional opportunities to the attacker. A possible man-in-the-middle attack would be to substitute a weaker qop scheme for the one(s) sent by the server; the server will not be able to detect this attack. For this reason, the client should always use the strongest scheme that it understands from the choices offered, and should never choose a scheme that does not meet its minimum requirements. A man-in-the-middle attack may also make the client and the server that agreed to use confidentiality protection to use different (and possibly weaker) cipher's. This is because the chosen cipher is not used in the shared secret calculation. 3.7 Chosen plaintext attacks A chosen plaintext attack is where a MITM or a malicious server can arbitrarily choose the challenge that the client will use to compute the response. The ability to choose the challenge is known to make Leach & Newman Expires: October 2005 [Page 28]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 cryptanalysis much easier [MD5]. However, Digest does not permit the attack to choose the challenge as long as the client chooses a fresh nonce for each authentication, as this specification requires. 3.8 CBC Mode attacks The following attack can be launched when the connection uses Confidentiality protection with ciphers in CBC mode. If bad padding is treated differently from bad MACs when decrypting a DIGEST-MD5 buffer of protected data, the attacker may be able to launch Vaudenay's attack on padding. An error logfile will suffice to launch the attack if it reveals the type of error -- even if file permissions prevent the attacker from actually reading the file (the file length increase cause by the attack is likely to reveal which of the two errors occured). A different approach to distinguish these two error cases and launch the attack is to examine the timing of error responses: if the MAC verification is skipped when bad padding has been found, the error will appear quicker in the case of incorrect block cipher padding than in the case of an incorrect MAC. A countermeasure is to compute a MAC of the plaintext anyway, even if the usual padding removal step fails because of incorrect padding, to obtain (nearly) uniform timing. 3.9 Spoofing by Counterfeit Servers If a user can be led to believe that she is connecting to a host containing information protected by a password she knows, when in fact she is connecting to a hostile server, then the hostile server can obtain challenge/response pairs where it was able to partly choose the challenge. There is no known way that this can be exploited. 3.10 Storing passwords Digest authentication requires that the authenticating agent (usually the server) store some data derived from the user's name and password in a "password file" associated with a given realm. Normally this might contain pairs consisting of username and H({ username-value, ":", realm-value, ":", passwd }), which is adequate to compute H(A1) as described above without directly exposing the user's password. The security implications of this are that if this password file is Leach & Newman Expires: October 2005 [Page 29]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say a standard UNIX password file, this information need not be decrypted in order to access documents in the server realm associated with this file. On the other hand, decryption, or more likely a brute force attack, would be necessary to obtain the user's password. This is the reason that the realm is part of the digested data stored in the password file. It means that if one Digest authentication password file is compromised, it does not automatically compromise others with the same username and password (though it does expose them to brute force attack). There are two important security consequences of this. First the password file must be protected as if it contained plaintext passwords, because for the purpose of accessing documents in its realm, it effectively does. A second consequence of this is that the realm string should be unique among all realms that any single user is likely to use. In particular a realm string should include the name of the host doing the authentication. Leach & Newman Expires: October 2005 [Page 30]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 3.11 Multiple realms Use of multiple realms may mean both that compromise of a the security database for a single realm does not compromise all security, and that there are more things to protect in order to keep the whole system secure. 3.11 Summary By modern cryptographic standards Digest Authentication is weak, compared to (say) public key based mechanisms. But for a large range of purposes it is valuable as a replacement for plaintext passwords. Its strength may vary depending on the implementation. 4 Example This example shows the use of the Digest SASL mechanism with the IMAP4 AUTHENTICATE command [RFC 3501]. In this example, "C:" and "S:" represent a line sent by the client or server respectively including a CRLF at the end. Linebreaks and indentation within a "C:" or "S:" are editorial and not part of the protocol. The password in this example was "secret". Note that the base64 encoding of the challenges and responses is part of the IMAP4 AUTHENTICATE command, not part of the Digest specification itself. S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9 C: c CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN S: c OK Completed C: a AUTHENTICATE DIGEST-MD5 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh cnNldD11dGYtOA== C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== C: S: a OK User logged in --- The base64-decoded version of the SASL exchange is: Leach & Newman Expires: October 2005 [Page 31]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth", algorithm=md5-sess,charset=utf-8 C: charset=utf-8,username="chris",realm="elwood.innosoft.com", nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", digest-uri="imap/elwood.innosoft.com", response=d388dad90d4bbd760a152321f2143af7,qop=auth S: rspauth=ea40f60335c427b5527b84dbabcdfffd The password in this example was "secret". This example shows the use of the Digest SASL mechanism with the ACAP, using the same notational conventions and password as in the previous example. Note that ACAP does not base64 encode and uses fewer round trips that IMAP4. S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5" "DIGEST-MD5" "PLAIN") C: a AUTHENTICATE "DIGEST-MD5" S: + {94} S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth", algorithm=md5-sess,charset=utf-8 C: {206} C: charset=utf-8,username="chris",realm="elwood.innosoft.com", nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m", digest-uri="acap/elwood.innosoft.com", response=6084c6db3fede7352c551284490fd0fc,qop=auth S: a OK (SASL {40} S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE Completed" --- The server uses the values of all the directives, plus knowledge of the users password (or the hash of the user's name, server's realm and the user's password) to verify the computations above. If they check, then the user has authenticated. Leach & Newman Expires: October 2005 [Page 32]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 5 References 5.1 Normative references [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [ISO-8859] ISO-8859. International Standard--Information Processing-- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. [RFC 822] Crocker, D., "Standard for The Format of ARPA Internet Text Messages," STD 11, RFC 822, August 1982. [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2222] Melnikov, A. (editor), "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. [RFC 3454] Hoffman, P., Blanchet, M., "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", defined by: The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/tr28-3.html). Leach & Newman Expires: October 2005 [Page 33]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, Janyary 1998. [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", Work in progress, draft-ietf-sasl- saslprep-XX.txt. [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. <<We can't use RFC 3513, as ABNF productions got removed!>> [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [FIPS] National Institute of Standards and Technology, "DES Modes of Operation", http://www.itl.nist.gov/fipspubs/fip81.htm, December 1980. [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher", http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf, 3rd September 1999. 5.2 Informative references [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", CryptoBytes, Sping 1995, RSA Inc, (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) [RFC 2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration Leach & Newman Expires: October 2005 [Page 34]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 Access Protocol", RFC 2244, November 1997. [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures", http://www.openssl.org/~bodo/tls-cbc.txt. [CBCATT] Canvel, B., "Password Interception in a SSL/TLS Channel", published 2003-02-20: http://lasecwww.epfl.ch/memo_ssl.shtml Leach & Newman Expires: October 2005 [Page 35]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 6 Authors' Addresses Paul Leach Microsoft 1 Microsoft Way Redmond, WA 98052, USA EMail: paulle@microsoft.com Chris Newman Sun Microsystems 1050 Lakes Drive West Covina, CA 91790, USA EMail: Chris.Newman@Sun.COM Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom Email: Alexey.Melnikov@isode.com Leach & Newman Expires: October 2005 [Page 36]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 7 ABNF What follows is the definition of the notation as is used in the HTTP/1.1 specification [RFC 2616] and the HTTP authentication specification [Digest]; it is reproduced here for ease of reference. Since it is intended that a single Digest implementation can support both HTTP and SASL-based protocols, the same notation is used in both to facilitate comparison and prevention of unwanted differences. Since it is cut-and-paste from the HTTP specifications, not all productions may be used in this specification. 7.1 Augmented BNF All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [RFC 822]. Implementers will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs: <<Can this be dropped in favor of ABNF?>> name = definition The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names. "literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive. rule1 | rule2 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no. (rule1 rule2) Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem". *rule The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so Leach & Newman Expires: October 2005 [Page 37]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two. [rule] Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)". N rule Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. #rule A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as ( *LWS element *( *LWS "," *LWS element ) *LWS ) can be shown as 1#element Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two. ; comment A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications. implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token. 7.2 Basic Rules Leach & Newman Expires: October 2005 [Page 38]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [USASCII]. OCTET = <any 8-bit character> CHAR = <any US-ASCII character (octets 0 - 127)> UPALPHA = <any US-ASCII uppercase letter "A".."Z"> LOALPHA = <any US-ASCII lowercase letter "a".."z"> ALPHA = UPALPHA | LOALPHA DIGIT = <any US-ASCII digit "0".."9"> CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)> CR = <US-ASCII CR, carriage return (13)> LF = <US-ASCII LF, linefeed (10)> SP = <US-ASCII SP, space (32)> HT = <US-ASCII HT, horizontal-tab (9)> <"> = <US-ASCII double-quote mark (34)> TEXTCHAR = <any OCTET except CTLs, but including HT> CRLF = CR LF All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. LWS = [CRLF] 1*( SP | HT ) The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of TEXT contains characters either from ISO-8859-1 [ISO-8859] character set or UTF-8 [UTF-8]. TEXT = <any *OCTET except CTLs, but including LWS> A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value. Hexadecimal numeric characters are used in several protocol elements. HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value. Leach & Newman Expires: October 2005 [Page 39]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 token = 1*TOKENCHAR separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT TOKENCHAR = <any CHAR except CTLs or separators> A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( <"> qdstr-val <"> ) qdstr-val = *( qdtext | quoted-pair ) qdtext = <any TEXTCHAR except <"> and "\"> Note that LWS is NOT implicit between the double-quote marks (<">) surrounding a qdstr-val and the qdstr-val; any LWS will be considered part of the qdstr-val. This is also the case for quotation marks surrounding any other construct. The backslash character ("\") MAY be used as a single-character quoting mechanism only within qdstr-val and comment constructs. quoted-pair = "\" CHAR The value of this construct is CHAR. Note that an effect of this rule is that backslash itself MUST be quoted. Leach & Newman Expires: October 2005 [Page 40]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 8 Sample Code The sample implementation in [Digest] also applies to DIGEST-MD5. The following code implements the conversion from UTF-8 to 8859-1 if necessary. /* if the string is entirely in the 8859-1 subset of UTF-8, then * translate to 8859-1 prior to MD5 */ void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, int len) { const unsigned char *scan, *end; unsigned char cbuf; end = base + len; for (scan = base; scan < end; ++scan) { if (*scan > 0xC3) break; /* abort if outside 8859-1 */ if (*scan >= 0xC0 && *scan <= 0xC3) { if (++scan == end || *scan < 0x80 || *scan > 0xBF) break; } } /* if we found a character outside 8859-1, don't alter string */ if (scan < end) { MD5Update(ctx, base, len); return; } /* convert to 8859-1 prior to applying hash */ do { for (scan = base; scan < end && *scan < 0xC0; ++scan) ; if (scan != base) MD5Update(ctx, base, scan - base); if (scan + 1 >= end) break; cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f); MD5Update(ctx, &cbuf, 1); base = scan + 2; } while (base < end); } Leach & Newman Expires: October 2005 [Page 41]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 10 Acknowledgements The following people had substantial contributions to the development and/or refinement of this document: Lawrence Greenfield John Gardiner Myers Simon Josefsson RL Bob Morgan Jeff Hodges Claus Assmann Tony Hansen Ken Murchison Sam Hartman Kurt D. Zeilenga Hallvard B. Furuseth Abhijit Menon-Sen as well as other members of the SASL mailing list. The text used is section 3.8 was taken from [TLS-CBC] by Bodo Moeller. Leach & Newman Expires: October 2005 [Page 42]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 11 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 12 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Leach & Newman Expires: October 2005 [Page 43]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 Appendix A: Changes from 2831 1). Fixed various typos in formulas. 2). Dropped DES as mandatory to implement cipher (rc4 is mandatory to implement). Removed "des" and "3des" ciphers because of known interoperability problems and vulnerability to CBC mode attack. 3). Tighten ABNF. Fixed some bugs. 4). Clarified nc-value verification and which side is aborting exchange. 5). Added text saying that for interoperability username/password/realm MUST be prepared using the "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [RFC 3454]. 6). Clarified that unquoted version of the username, etc. used in A1 calculation. 7). Various cleanup to References section. Split all references to Normative and Informative. 8). Added minimal and maximal limits on maxbuf. Clarified how to calculate max sender size. 9). Change ABNF for host to allow for IPv6 addresses. ABNF now references RFC 3513 and RFC 2396. 10). Added man-in-the-middle considerations for ciphers. 11). Clarified how sequence counters are updated. 12). Addition warnings about preventing reply/redirection attacks. 13). Specified that "charset" directive affects "realm" and doesn't affect "authzid". 14). Removed text that described that "authzid" is in Unicode in Normalization Form KC, encoded as UTF-8. 15). Clarified that rc4 state is not reset between two consecutive sent/received buffers of protected data. 16). Clarified how "maximal sender size" is calculated. 17). Prohibit an empty authzid, as this caused interoperability problems. Leach & Newman Expires: October 2005 [Page 44]
INTERNET DRAFT DIGEST-MD5 SASL Mechanism April 2005 18). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL mechanism" document (expired draft-ietf-sasl-digest-aes-00.txt). 19). Use explicit IV with aes cipher in CBC mode. 20). Changed "aes" cipher option name to "aes-cbc", because -03 introduces new encryption procedure. 21). Cleaned up Confidentiality protection section. Added step by step exlanation how CBC mode is used. 22). Added clarification which end and under what conditions has to perform SASLPrep (still work in progress). 23). Clarified how UIs should present realms. 24). Clarified client behavior, if it recognizes no ciphers. 25). Clarified that the server is not required to advertise all realms it supports. 26). Changed some informative text to normative MUST/SHOULDs. 27). Allow for extensibility in step 3. Use "auth-info" as in RFC 2617. And other minor text clarifications. Appendix B: Open Issues/ToDo List 1). The latest revision prohibits escaped characters in nonce/cnonce. This is different from HTTP Digest. Any objections? 2). Do we need/want a new stringprep profile for "realm"? 3). Resolve ISO-8859-1 and SaslPrep interaction issue as reported by Simon Josefsson. 4). Replace ABNF with the reference to RFC 2234? 5). Pick a way to fix CBC mode attack. 6). Normative vs. Informative references must be carefully rechecked. Leach & Newman Expires: October 2005 [Page 45]
