summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorSimon Josefsson <simon@josefsson.org>2006-11-16 13:33:40 +0000
committerSimon Josefsson <simon@josefsson.org>2006-11-16 13:33:40 +0000
commit7e832e237fee58a5908e97e3a5c74c1f5360fea9 (patch)
tree0665b7acd0f41af259071fb48244fe71dd6f78b4 /doc
parent556bb6b5299d58ed39edae199f9898ccdc159c50 (diff)
downloadgnutls-7e832e237fee58a5908e97e3a5c74c1f5360fea9.tar.gz
Add.
Diffstat (limited to 'doc')
-rw-r--r--doc/protocol/draft-ietf-sasl-rfc2831bis-11.txt2760
1 files changed, 2760 insertions, 0 deletions
diff --git a/doc/protocol/draft-ietf-sasl-rfc2831bis-11.txt b/doc/protocol/draft-ietf-sasl-rfc2831bis-11.txt
new file mode 100644
index 0000000000..6c35ada46b
--- /dev/null
+++ b/doc/protocol/draft-ietf-sasl-rfc2831bis-11.txt
@@ -0,0 +1,2760 @@
+
+
+
+
+
+
+INTERNET-DRAFT A. Melnikov (Ed.)
+Obsoletes: 2831 Isode Ltd.
+Intended category: Standards track November 2006
+
+ Using Digest Authentication as a SASL Mechanism
+ draft-ietf-sasl-rfc2831bis-11.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 (2006).
+
+Abstract
+
+ This specification defines how HTTP Digest Authentication (RFC 2617)
+ can be used as a Simple Authentication and Security Layer (SASL, RFC
+ 4422) 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.
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 1]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+Table of Contents
+
+ 1 INTRODUCTION.....................................................3
+ 1.1 CONVENTIONS AND NOTATION......................................3
+ 1.2 CHANNEL BINDINGS..............................................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 IANA CONSIDERATIONS.............................................28
+ 7 ABNF............................................................29
+ 7.1 AUGMENTED BNF................................................29
+ 7.2 BASIC RULES..................................................31
+ 8 SAMPLE CODE.....................................................33
+ 9 AUTHORS' ADDRESSES..............................................XX
+ 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.
+ Section ordering should be changed too>>
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 2]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+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
+ and confidentiality 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
+
+ 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].
+
+ <<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.
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 3]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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 nul (0x00) character.
+
+ Let prep(X) be the value returned by the preparation function (see
+ description of "prep" directive in section 2.1.1).
+
+ Other terms like "protocol profile" are defined in RFC4422.
+
+1.2 Channel Bindings
+
+
+ "Channel binding" is a concept described in [GSS-API] and which
+ refers to the act of cryptographically binding authentication at one
+ network layer to a secure channel at another layer and where the end-
+ points at both layers are the same entities. In the context of the
+ DIGEST-MD5 SASL mechanism this means ensuring that the challenge and
+ response messages include the "channel bindings" of any cryptographic
+ channel (e.g. TLS) over which the DIGEST-MD5 exchange is transported,
+ and that the inputs to the digest function include the same as well.
+ The "channel bindings" of a channel here refer to information which
+ securely identifies one instance of such a channel to both endpoints
+ such that MITM attacks are detectable. For more discussions of
+ channel bindings, and the syntax of the channel binding data for
+ various security protocols, see [CHANNEL-BINDINGS].
+
+ Channel bindings are herein added to DIGEST-MD5 by overloading the
+ nonce and cnonce fields of the digest-challenge and digest-response
+ messages, respectively. Because these nonces are treated as opaque
+ octet strings in previous versions of this mechanism such overloading
+ is backwards compatible. Because these nonces are used in the
+ construction of the response-value (i.e., as input to the digest
+ function) using these fields for carrying channel bindings data makes
+ the channel binding operation possible without requiring incompatible
+ changes to the message formats. The fact that the odds that older
+ implementations may select random nonces that resemble actual channel
+ bindings data are so low allows new implementations to detect old
+ peers and to decide whether to allow such peers or reject them
+ according to local policy.
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 4]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+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 [SASL]) 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 5]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ digest-challenge =
+ 1#( realm / nonce / qop-options / stale / server_maxbuf /
+ charset / prep / algorithm / cipher-opts / auth-param )
+
+ realm = "realm" "=" realm-value
+ realm-value = quoted-string
+ nonce = "nonce" "=" nonce-value
+ nonce-value = quoted-string
+ ;; contains data described by "nonce-data"
+ qop-options = "qop" "=" DQUOTE qop-list DQUOTE
+ 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"
+ prep = "prep" "=" DQUOTE prep-mechs DQUOTE
+ prep-mechs = 1#prep-mech
+ prep-mech = "rfc4013"
+ algorithm = "algorithm" "=" "md5-sess"
+ cipher-opts = "cipher" "=" DQUOTE cipher-list DQUOTE
+ cipher-list = 1#cipher-value
+ cipher-value = "rc4-40" / "rc4" / "rc4-56" /
+ "aes-ctr" / cipher-token
+ ;; cipher-token is reserved for
+ ;; new ciphersuites
+ cipher-token = token
+ auth-param = token "=" ( token / quoted-string )
+ nonce-data = new-nonce-data / obs-nonce-data
+ new-nonce-data = "CB-" channel-type ":" channel-bindings
+ ":" qop-list ":" cipher-list
+ ":" nonce-octets
+ obs-nonce-data = nonce-octets
+ ;; nonce value as defined in RFC 2831.
+ ;; SHOULD be accepted. MUST NOT be
+ ;; generated.
+ <<channel-type = "TLS" / channel-type-ext
+ ;; Should be taken from
+ ;; [CHANNEL-BINDINGS].
+ channel-type-ext = 1*(ALPHA / DIGIT)
+ ;; for future channel bindings>>
+ channel-bindings = 1*TEXTCHAR
+ ;; channel binding data as defined by
+ ;; the channel type
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 6]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ nonce-octets = 1*TEXTCHAR
+
+ 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 (hide) 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
+ 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.
+
+ nonce
+ A server-specified string erstwhile intended to add entropy to the
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 7]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ challenge. The nonce field may be used to exchange channel
+ binding data.
+
+ 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.
+
+ Older implementations typically generate some random or pseudo-
+ random data and base64 [RFC 4648] or hexadecimally encode it.
+ When channel binding is not used the nonce string MUST be
+ different each time a digest-challenge is sent as part of initial
+ authentication. It is RECOMMENDED that the random data contain at
+ least 64 bits of entropy.
+
+ When channel binding is performed, the nonce must be generated
+ from: the channel type, the bindings to the channel being bound
+ to, copy of the server specified qop-list (*), copy of the server
+ specified list of ciphers or empty string if none were specified
+ and an actual nonce consisting of 64-bits or more of entropy and
+ base64-encoded, and formatted as follows:
+
+ "CB-" <channel type> ":" <channel bindings> ":" <qop-list> ":"
+ <cipher-list> ":" <nonce octets>
+
+ See [CHANNEL-BINDINGS] for the syntax of the channel binding data
+ for various security protocols.
+
+ An actual nonce is included in order to allow for channel bindings
+ to possible future channels with channel bindings data which is
+ not necessarily unique for each instance.
+
+ When channel bindings are in use, clients MUST reject challenges
+ that contain server nonce values of this form and whose channel
+ bindings do not match those of the actual underlying channel as
+ observed by the client. Also clients MUST reject challenges that
+ contain server nonce values of this form and that contain qop-list
+ and/or cipher-list that don't match the values sent in the
+ qop/cipher directives respectively.
+
+ (*) - Note that if the server specified multiple "qop" directives,
+ this field MUST be constructed by extracting all qop-list values
+ (in the order they were specified) and inserting "," between them.
+ For example, if the server sent:
+ qop="auth",qop="auth-int" this field must have the value
+ "auth,auth-int" (with no quotes).
+
+ qop-options
+ A quoted string of one or more comma-separated tokens indicating
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 8]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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.
+
+ If this directive is present multiple times the client MUST treat
+ it as if it received a single qop directive containing a comma
+ separated value from all instances. I.e., 'qop="auth",qop="auth-
+ int"' is the same as 'qop="auth,auth-int"'.
+
+ 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 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.
+
+ 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 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
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 9]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ exchange.
+
+ Note, that this directive doesn't affect authorization id
+ ("authzid").
+
+ prep
+ Servers compliant with this specification MUST include this
+ directive.
+
+ If present, it contains a comma separated list of
+ username/password preparation algorithms supported by the server.
+ That is, if user credentials are stored as one or more "SS" (see
+ section 2.1.2.1) values, then the server signals to the client
+ which username/password preparation algorithms were used when the
+ "SS" value(s) were created. If cleartext user password is stored,
+ the server returns "rfc4013" (see below) as the value of this
+ directive.
+
+ This document defines only a single value "rfc4013", which means
+ that the server supports "SASLPrep" profile [SASLPrep] of the
+ "stringprep" algorithm [RFC 3454].
+
+ <<This directive MUST be ignored, unless the "charset" directive
+ is also present and contains the value "utf-8".
+
+ <<An alternative: if this directive is present and the charset is
+ not, abort authentication exchange.>>
+
+ <<Another alternative: this directive implies charset=utf-8.
+ However this would mean that an older client (which doesn't
+ recognize the prep directive will think that the server doesn't
+ support UTF-8.>> >>
+
+ If this directive is missing, the server doesn't support any
+ preparation algorithm, i.e. the server is an RFC 2831 only server.
+
+ If this directive is present multiple times the client MUST treat
+ it as if it received a single prep directive containing a comma
+ separated value from all instances.
+
+ 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
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 10]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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 "aes-ctr" 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-ctr
+ the Advanced Encryption Standard (AES) cipher [AES] in counter
+ (CTR) mode with a 128 bit key. 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.
+
+ 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 validates "digest-challenge" as described in the previous
+ section. In particular, when channel bindings are in use, client MUST
+ reject "digest-challenge" that contain server nonce whose channel
+ bindings do not match those of the actual underlying channel as
+ observed by the client.
+
+ 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 /
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 11]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ response-v2 / client_maxbuf / charset / prep /
+ cipher / authzid / auth-param )
+
+ username = "username" "=" username-value
+ username-value = quoted-string
+ cnonce = "cnonce" "=" cnonce-value
+ cnonce-value = nonce-value
+ nonce-count = "nc" "=" nc-value
+ nc-value = 8LHEX
+ client_maxbuf = "maxbuf" "=" maxbuf-value
+ qop = "qop" "=" qop-value
+ digest-uri = "digest-uri" "="
+ DQUOTE digest-uri-value DQUOTE
+ digest-uri-value = serv-type "/" host [ "/" serv-name ]
+ serv-type = 1*ALPHA
+ serv-name = host
+ prep = "prep" "=" prep-mech
+ response = "response" "=" response-value
+ response-v2 = "response-v2" "=" response-value
+ response-value = 32LHEX
+ LHEX = DIGIT / "a" / "b" /
+ "c" / "d" / "e" / "f"
+ cipher = "cipher" "=" cipher-value
+ authzid = "authzid" "=" authzid-value
+ authzid-value = quoted-string
+
+ The 'host' non-terminal is defined in [RFC 3986] as
+
+ host = IP-literal / IPv4address / reg-name
+
+ 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) and the "prep" directive is not,
+ the server behaves as described in RFC 2831. This mode of
+ operation SHOULD be supported for backward compatibility with RFC
+ 2831, however it is not required to be compliant with this
+ specification.>>
+
+ realm
+ The realm containing the user's account, encoded according to the
+ value of the "charset" directive. This directive MUST appear at
+ most once and SHOULD contain one of the realms provided by the
+ server in the "digest-challenge". If the directive is missing,
+ "realm-value" will set to the empty string when computing A1 (see
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 12]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ below for details).
+
+ <<If the realm value was provided by the client, if the "charset"
+ directive is also specified (which means that the realm is encoded
+ as UTF-8) and the "prep" directive is not, the server behaves as
+ described in RFC 2831. This mode of operation SHOULD be supported
+ for backward compatibility with RFC 2831, however it is not
+ required to be compliant with this specification.>>
+
+ 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.
+
+ cnonce
+ A client-specified string erstwhile intended to add entropy to the
+ challenge. The cnonce field may be used to exchange channel
+ binding data.
+
+ This directive is required and MUST be present exactly once;
+ otherwise, authentication fails.
+
+ Older implementations typically generate some random or pseudo-
+ random data and base64 [RFC 4648] or hexadecimally encode it.
+ When channel binding is not used the cnonce string MUST be
+ different each time a digest-challenge is sent as part of initial
+ authentication. It is RECOMMENDED that the random data contain at
+ least 64 bits of entropy.
+
+ When channel binding is performed, the cnonce must be generated
+ from: the channel type, the bindings to the channel being bound
+ to, copy of the client selected qop, copy of the client selected
+ cipher or cipher="" if none were selected (i.e. for qop=auth or
+ qop=auth-int), and an actual nonce consisting of 64-bits or more
+ of entropy and base64-encoded, and formatted as follows:
+
+ "CB-" <channel type> ":" <channel bindings> ":" <qop-value> ":"
+ [<cipher-value>] ":" <nonce octets>
+
+ See [CHANNEL-BINDINGS] for the syntax of the channel binding data
+ for various security protocols.
+
+ An actual nonce is included in order to allow for channel bindings
+ to possible future channels with channel bindings data which is
+ not necessarily unique for each instance. It is used by both
+ client and server to avoid chosen plaintext attacks, and to
+ provide mutual authentication.
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 13]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ When channel bindings are in use, servers MUST reject responses
+ that contain client nonce values of this form and whose channel
+ bindings do not match those of the actual underlying channel as
+ observed by the server. Also servers MUST reject responses that
+ contain client nonce values of this form and that contain qop-list
+ and/or cipher-list that don't match the values sent in the
+ qop/cipher directives respectively.
+
+ <<Add examples>>
+
+ 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 [SASL], registered in the IANA registry of "service"
+ elements for the GSSAPI host-based service name form [GSS-API].
+
+ host
+ The DNS host name or IP (IPv4 or IPv6) 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.
+
+ 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
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 14]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 2782], 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 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.
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 15]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ response-v2
+ A string of 32 hex digits computed as defined below, which proves
+ that the user knows a password. This directive MUST be present at
+ most once; if it is present multiple times, then authentication
+ fails. If during SS calculation (see section 2.1.2.1) preparation
+ of the username and/or the password fails or results in an empty
+ string (*), then the client MUST NOT send this directive. Also, if
+ none of the values in the server's "prep" directive is recognized,
+ then this directive MUST NOT be sent.
+
+ (*) In this case an interactive client can request a repeated
+ entry of the username and/or the password.
+
+ 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, 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 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 encoded as UTF-8
+ [UTF-8]. If not present, the username, realm 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 that it supports UTF-8 [UTF-8]. 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 server MUST abort the authentication exchange.
+
+ Note, that this directive doesn't affect the authorization
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 16]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ identity ("authzid").
+
+ prep
+ This directive, if present, specifies which username/password
+ preparation algorithms has been used by the client when
+ calculating response-v2. This directive MUST contain one of the
+ values specified in the "prep" directive from the digest-
+ challenge, or authentication exchange fails. This document
+ defines only a single possible value "rfc4013", which means
+ support for [SASLPrep]. Future Standard Track or Experimantal
+ documents may define other values for this directive. <<If this
+ directive is missing, then the "response-v2" directive MUST be
+ absent.>>
+
+ <<This directive MUST be ignored, unless the "charset" directive
+ is also present.>>
+
+ <<Alternative: if this directive is present, but the "charset"
+ directive is not, then charset=utf-8 is implied. However this
+ might be bad when dealing with old (2831) servers which don't
+ recognize the "prep" directive.>>
+
+ This directive may appear at most once; if multiple instances are
+ present, the server MUST abort the authentication exchange.
+
+ LHEX
+ 32 hex digits, where the alphabetic characters MUST be lower case,
+ because MD5 is case sensitive.
+
+ 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 authorization identifier is always in UTF-8, in particular the
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 17]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ "charset" directive doesn't affect how this value is encoded.
+
+ The authzid MUST NOT be an empty string.
+
+ Upon the receipt of this value the server verifies its correctness
+ according to the used 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.
+
+ Note that the algorithm described below applies to both "response"
+ and "response-v2" options. The only difference between the two is in
+ how "SS" value is calculated.
+
+ 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)),
+ { unq(nonce-value), ":" nc-value, ":",
+ unq(cnonce-value), ":", qop-value, ":",
+ HEX(H(A2)) }))
+
+ If authzid is specified, then A1 is
+
+ A1 = { SS, ":", unq(nonce-value), ":",
+ unq(cnonce-value), ":", unq(authzid-value) }
+
+ If authzid is not specified, then A1 is
+
+ A1 = { SS, ":", unq(nonce-value), ":", unq(cnonce-value) }
+
+ where
+
+ password = *OCTET
+
+ For "response" option, SS is calculated as follows:
+
+ SS = H( { unq(username-value), ":",
+ unq(realm-value), ":", password } )
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 18]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ For "response-v2" option, SS is calculated as follows:
+
+ SS = H( { prep(unq(username-value)), ":",
+ unq(realm-value)), ":", prep(password) } )
+
+ where prep(X) is the preparation function described by the "prep"
+ directive.
+ <<This assumes that both input and result are in UTF-8>>
+
+ <<Note that client/server behavior in absence of the "prep" directive
+ is described in RFC 2831. This behavior SHOULD be supported for
+ backward compatibility with RFC 2831, however it is not required for
+ compliance with this specification.>>
+
+ If the "qop" directive's value is "auth", then A2 is:
+
+ A2 = { "AUTHENTICATE:", digest-uri-value }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 19]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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". In
+ particular, the server verifies that all required directives are
+ present and they don't appear more times than expected. See section
+ 2.1.2 for details.
+
+ The server also does the following checks:
+
+ 1) When channel bindings are in use, server MUST reject "digest-
+ response" that contain client nonce whose channel bindings do not
+ match those of the actual underlying channel as observed by the
+ server.
+
+ 2) 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-octets" part of the nonce and the nonce-count.
+
+ 3) The server verifies the received "response" and "response-v2"
+ values. (Note that the "response-v2" might be absent). If either
+ one of them matches the corresponding value calculated by the server,
+ then the server can assume that the client proved that it knows its
+ password.
+
+ 4) If the client sent the "authzid" directive, the server verifies
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 20]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ its correctness according to the used SASL protocol profile. If the
+ "authzid" directive is not present or its correctness is verified,
+ then the server can consider the client to be successfully
+ authenticated.
+
+ Upon successful client authentication the server sends a message
+ formatted as follows:
+
+ auth-info = 1#( response-auth / response-v2-auth / auth-param )
+
+ response-auth = "rspauth" "=" response-value
+ response-v2-auth = "rspauth-v2" "=" response-value
+
+ where response-value is calculated as above (the "rspauth" is
+ calculated as client's "response" and the "rspauth-v2" is calculated
+ as client's "response-v2"), 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" }
+
+ The server sends one of response-auth, response-v2-auth, depending on
+ whether it was able to match client's "response" or "response-v2".
+ Note that only one occurance of the "response-auth"/"response-
+ v2-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
+ "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" (also known as "fast reauthentication"),
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 21]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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 in section 2.1.2, after
+ applying the following changes:
+
+ 1) the nonce-count value is one greater than used in the last
+ "digest-response"
+
+ 2) if nonce/cnonce values contained any channel bindings information,
+ it
+ MUST be replaced with the channel bindings, qop and cipher lists
+ relevant
+ for the new connection.
+ In other words, only the "nonce-octets" part of nonce/cnonce
+ "nonce-data"
+ MUST be preserved on reauthentication.
+
+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, cnone 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
+ values of the username, the realm, the qop and nonce-octets part of
+ the nonce and the cnonce are the same as in the original
+ authentication attempt; 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
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 22]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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 = H({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 = H({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
+ counters for sending and receiving.) The sequence number wraps around
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 23]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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 = H({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 = H({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-ctr" ciphers is all 16 bytes of Kcc or Kcs.
+
+ "aes-ctr" 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.
+
+ The padding and first 10 bytes of the MAC block are encrypted with
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 24]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ the chosen cipher along with the message.
+
+ SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {msg, pad, MAC})
+
+ MAC(Ki, SeqNum, msg) = {HMAC(Ki, {SeqNum, 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. 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, 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.
+
+2.4.1 AES cipher in "stateful-decryption counter" mode ("aes-ctr")
+
+ In stateful-decryption counter mode, both the sender and the receiver
+ maintain an internal 128-bit counter CTRBLK.
+
+ The initial value of the CTRLBLK is calculated as follows:
+
+ The counter for the first SASL packet going from the client
+ to the server consists of 16 bytes calculated as follows:
+
+ CTRBLK = H({H(A1), "aes-128 counter client-to-server", nc-value})
+
+ The counter for the first SASL packet going from the server
+ to the client consists of 16 bytes calculated as follows:
+
+ CTRBLK = H({H(A1), "aes-128 counter server-to-client", nc-value})
+
+ <<An alternative is to add a new option containing 128bit of random
+ data, which is sent with successful authentication and is used to
+ construct the initial counter.>>
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 25]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ For each buffer of cleartext data to be encrypted the sender performs
+ the following procedure:
+
+ 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
+
+ {P[1], P[2], P[3], ..., P[m]}
+
+ where P[i] is a chunk of data of the length 128 bit.
+
+ 2) Data is encrypted as follows:
+
+ FOR i := 1 to m DO
+ E[i] := P[i] XOR CIPHER ( Kc, CTRBLK )
+ CTRBLK := CTRBLK + 1
+ END
+
+ This will generate ciphertext {E[1], ..., E[m]} to be sent as a
+ single
+ SASL packet.
+
+ The initial CTRBLK value is constructed as described at the
+ beginning of
+ this section. The last CTRBLK value produced after encrypting P[m]
+ is
+ used to encrypt the first 128bit chunk of the next sent SASL
+ packet
+ (if any), end so on.
+
+ If CTRBLK = (2**128)-1, then "CTRBLK + 1" has the traditional
+ semantics of "set CTRBLK to 0."
+
+
+ The receiver performs the following steps:
+
+ 1) Data is decrypted as follows:
+
+ FOR i := 1 to m DO
+ P[i] := E[i] XOR CIPHER ( Kc, CTRBLK )
+ CTRBLK := CTRBLK + 1
+ END
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 26]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ This will generate plaintext {P[1], ..., P[m]}, which is
+ {msg, pad, MAC}.
+
+ The initial CTRBLK value is constructed as described at the
+ beginning of
+ this section. The last CTRBLK value produced after decrypting P[m]
+ is used to decrypt the first 128bit chunk of the next received
+ SASL packet
+ (if any), end so on.
+
+ If CTRBLK = (2**128)-1, then "CTRBLK + 1" has the traditional
+ semantics of "set CTRBLK to 0."
+
+ 2) pad and MAC block are verified as described in section 2.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 27]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+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
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 28]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 29]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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 Attacks on padding
+
+ In the past, implementations that treated bad padding differently
+ from bad MACs during decryption were subject to different attacks.
+ Note that such attacks are known for block ciphers in CBC mode, e.g.
+ [VAUDENAY]. Even though this document doesn't define any ciphers in
+ CBC mode, similar attacks might be used in the future against other
+ ciphers.
+
+ In order to mitigate risks of such attacks, it is recommended that
+ implementations don't skip MAC verification when bad padding is found
+ in order to obtain (nearly) uniform timing of sending failure
+ responses.
+
+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, ":", password }), 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
+ 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,
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 30]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 31]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+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:
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 32]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 33]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+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 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+ [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.
+
+ [SASL] Melnikov, A. (editor) and K. Zeilenga "Simple Authentication
+ and Security Layer (SASL)", RFC 4422, June 2006.
+
+ [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).
+
+ [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646",
+ STD 63, RFC 3629, November 2003.
+
+ [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
+ Code for Information Interchange. Standard ANSI X3.4-1986,
+ ANSI, 1986.
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 34]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
+ and passwords", RFC 4013, February 2005.
+
+ [RFC 3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", RFC 3986,
+ January 2005.
+
+ [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",
+ http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf,
+ 3rd September 1999.
+
+ [GSS-API] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743, January 2000.
+
+ [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [CHANNEL-BINDINGS] Williams, N., "On the Use of Channel Bindings to
+ Secure Channels", work in progress, draft-williams-on-
+ channel-binding-00.txt.
+
+5.2 Informative references
+
+ [RFC 2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [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,
+ (ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto1n1.pdf)
+
+ [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 3501, March 2003.
+
+ [RFC 2244] Newman, C., Myers, J., "ACAP -- Application Configuration
+ 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.
+
+ [VAUDENAY] Serge Vaudenay, "Security Flaws Induced by CBC Padding -
+ Applications to SSL, IPSEC, WTLS ...". L.R. Knudsen (Ed.):
+ EUROCRYPT 2002, LNCS 2332, pp. 534-545, 2002.
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 35]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ [RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, October 2006.
+
+ [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
+ MECHANISMS", <http://www.iana.org/assignments/sasl-
+ mechanisms>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 36]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+6 IANA Considerations
+
+ It is requested that the SASL Mechanism registry [IANA-SASL] entry
+ for the DIGEST-MD5 mechanism be updated to reflect that this document
+ now provides its technical specification.
+
+ To: iana@iana.org
+ Subject: Updated Registration of SASL mechanism DIGEST-MD5
+
+ Family of SASL mechanisms: NO
+ SASL mechanism name: DIGEST-MD5
+ Security considerations: See RFC XXXX.
+ Published specification (optional, recommended): RFC XXXX
+ Person & email address to contact for further information:
+ Alexey Melnikov <alexey.melnikov@isode.com>
+ IETF SASL WG <ietf-sasl@imc.org>
+ Intended usage: COMMON
+ Author/Change controller: IESG <iesg@ietf.org>
+ Note: Updates existing entry for DIGEST-MD5
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 37]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+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) which is a
+ superset of the ABNF defined in [ABNF]. The Augmented BNF used by
+ this document defines the following extra syntactic rule:
+
+ #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 (LWSP). This makes the usual
+ form of lists very easy; a rule such as
+ ( LWSP element *( LWSP "," LWSP element ) LWSP )
+ 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.
+
+
+ Other differences from [ABNF]:
+
+ implied LWSP
+ The grammar described by this specification is word-based. Except
+ where noted otherwise, linear white space (LWSP) 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 (LWSP 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.
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 38]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+7.2 Basic Rules
+
+ 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]. Non-terminals not defined in
+ this document can be found in [ABNF].
+
+ TEXTCHAR = <any OCTET except CTLs, but including HTAB>
+
+ 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.
+
+ LWSP = *(WSP / CRLF WSP)
+
+ 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 LWSP>
+
+ A CRLF is allowed in the definition of TEXT only as part of a header
+ field continuation. It is expected that the folding LWSP will be
+ replaced with a single SP before interpretation of the TEXT value.
+
+ Many HTTP/1.1 header field values consist of words separated by LWSP
+ or special characters. These special characters MUST be in a quoted
+ string to be used within a parameter value.
+
+ token = 1*TOKENCHAR
+ BACKSLASH = %x5C
+ ; character
+ separators = "(" / ")" / "<" / ">" / "@"
+ / "," / ";" / ":" / BACKSLASH / DQUOTE
+ / "/" / "[" / "]" / "?" / "="
+ / "{" / "}" / SP / HTAB
+ 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 = DQUOTE qdstr-val DQUOTE
+ qdstr-val = *( qdtext / quoted-pair )
+ qdtext = <any TEXTCHAR except DQUOTE and BACKSLASH>
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 39]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ Note that LWSP is NOT implicit between the double-quote marks
+ (DQUOTE) surrounding a qdstr-val and the qdstr-val; any LWSP will be
+ considered part of the qdstr-val. This is also the case for
+ quotation marks surrounding any other construct.
+
+ The backslash character (BACKSLASH) MAY be used as a single-character
+ quoting mechanism only within qdstr-val and comment constructs.
+
+ quoted-pair = BACKSLASH CHAR
+
+ The value of this construct is CHAR. Note that an effect of this rule
+ is that backslash itself MUST be quoted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 40]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+8 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
+
+
+9 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
+ Nicolas Williams
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 41]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ Jeffrey Hutzelman
+ Tom Yu
+ Dave Cridland
+ Frank Ellermann
+
+ as well as other members of the SASL mailing list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 42]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+10 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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.
+
+11 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.
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 43]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+Appendix A: Changes from 2831
+
+ 1). Fixed various typos in formulas.
+
+ 2). Tighten ABNF. Fixed some bugs.
+
+ 3). Replace RFC 822 ABNF with [ABNF].
+
+ 4). Clarified nc-value verification and which side is aborting
+ exchange.
+
+ 5). Removed downconversion to ISO-8859-1.
+
+ 6). Clarified that unquoted version of the username, etc. used in A1
+ calculation.
+
+ 7). Various cleanup to References section. Split all references into
+ Normative and Informative.
+
+ 8). Added minimal and maximal limits on maxbuf. Clarified how to
+ calculate "maximal sender size".
+
+ 9). Change ABNF for host to allow for IPv6 addresses. ABNF now
+ references RFC 3986.
+
+ 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). Allow for extensibility in step 3. Use "auth-info" as in RFC
+ 2617.
+
+ 17). Prohibit an empty authzid, as this caused interoperability
+ problems.
+
+ 18). Clarified that 'qop="auth",qop="auth-int"' is the same as
+ 'qop="auth,auth-int"'.
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 44]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 19). Clarified client behavior, if it recognizes no ciphers.
+
+ 20). Clarified that the server is not required to advertise all
+ realms it supports.
+
+ 21). Clarified how UIs should present realms.
+
+ 22). Changed some informative text to normative MUST/SHOULDs.
+
+ 23). Changed nonce/cnonce to allow for channel bindings.
+
+ 24). Added new "prep" directive, that allows to specify preparation
+ algorithms for username/password. Defined a single preparation
+ mechanism - SASLPrep [SASLPrep].
+ Added another directive (response-v2) confirming that a user
+ knows
+ its password. A corresponding directive (rspauth-v2) was added
+ for
+ the server.
+
+ 25). Cleaned up Confidentiality protection section.
+
+ 26). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL
+ mechanism" document (expired draft-ietf-sasl-digest-aes-00.txt).
+ Use aes cipher in CTR mode ("aes-ctr").
+
+ 27). Dropped DES as mandatory to implement cipher (aes-ctr is
+ mandatory to
+ implement). Removed "des" and "3des" ciphers because of known
+ interoperability problems and vulnerability to CBC mode attack.
+
+
+ And other minor text clarifications.
+
+Appendix B: Differences between HTTP Digest and DIGEST-MD5
+
+ <<The following list is probably not complete>>
+
+ 1) On reauthentication, DIGEST-MD5 requires that cnonce is to be the
+ same, while HTTP Digest doesn't have this restriction
+
+ 2) Integrity and confidentiality security layers are very specific to
+ SASL and DIGEST-MD5
+
+ 3) HTTP Digest doesn't support channel bindings
+
+ 4) HTTP Digest doesn't have the "charset" and the "prep" options
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 45]
+
+
+
+
+
+INTERNET DRAFT DIGEST-MD5 SASL Mechanism November 2006
+
+
+ 5) DIGEST-MD5 doesn't use the following HTTP Digest options in
+ "digest-challenge": "opaque" and "domain"
+
+ 6) DIGEST-MD5 doesn't use the following HTTP Digest options in
+ "digest-response": "opaque" and "algorithm"
+
+ 7) DIGEST-MD5 doesn't use the following HTTP Digest options in "auth-
+ info": "nextnonce", "qop", "cnonce" and "nonce-count"
+
+ 8) A second directive (response-v2) confirming that a user knows its
+ password
+ is added. A corresponding directive (rspauth-v2) was added for the
+ server.
+
+Appendix C: Open Issues/ToDo List
+
+ 1). Normative vs. Informative references must be carefully rechecked.
+
+ 2). The charset directive is kind of optional, but in practice it is
+ not.
+ Should it just be made mandatory?
+
+ 3). Need to clarify behaviour when the prep directive is present,
+ but the charset directive is not.
+
+ 4). Update example to match the updated draft, in particular need
+ to add channel binding, qop & cipher lists into nonce/cnonce.
+
+ 5). Need to clarify backward compatibility with RFC 2831 in several
+ places.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov (Ed.) Expires: May 2007 [Page 46]
+
+
View Lorry Controller Status