idnits 2.17.1 draft-ietf-sasl-rfc2831bis-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1893. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 47 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2831, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6251 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1185 -- Looks like a reference, but probably isn't: '2' on line 1151 -- Looks like a reference, but probably isn't: '3' on line 1151 == Unused Reference: 'Unicode' is defined on line 1476, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (ref. 'Digest') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' ** Obsolete normative reference: RFC 4013 (ref. 'SASLPrep') (Obsoleted by RFC 7613) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) == Outdated reference: A later version (-04) exists of draft-williams-on-channel-binding-00 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Melnikov (Ed.) 3 Obsoletes: RFC 2831 (if approved) Isode Ltd. 4 Intended status: Standards track March 2007 5 Expires: September 2007 7 Using Digest Authentication as a SASL Mechanism 8 draft-ietf-sasl-rfc2831bis-12.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its 19 working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This specification defines how HTTP Digest Authentication (RFC 2617) 41 can be used as a Simple Authentication and Security Layer (SASL, RFC 42 4422) mechanism for any protocol that has a SASL profile. It is 43 intended both as an improvement over CRAM-MD5 (RFC 2195) and as a 44 convenient way to support a single authentication mechanism for web, 45 mail, LDAP, and other protocols. 47 Table of Contents 49 1 INTRODUCTION.....................................................3 50 1.1 CONVENTIONS AND NOTATION......................................3 51 1.2 CHANNEL BINDINGS..............................................4 52 2 AUTHENTICATION...................................................5 53 2.1 INITIAL AUTHENTICATION........................................5 54 2.1.1 Step One...................................................5 55 2.1.2 Step Two...................................................9 56 2.1.3 Step Three................................................16 57 2.2 SUBSEQUENT AUTHENTICATION....................................17 58 2.2.1 Step one..................................................17 59 2.2.2 Step Two..................................................17 60 2.3 INTEGRITY PROTECTION.........................................18 61 2.4 CONFIDENTIALITY PROTECTION...................................18 62 3 SECURITY CONSIDERATIONS.........................................21 63 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........21 64 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................21 65 3.3 REPLAY ATTACKS...............................................21 66 3.4 ONLINE DICTIONARY ATTACKS....................................22 67 3.5 OFFLINE DICTIONARY ATTACKS...................................22 68 3.6 MAN IN THE MIDDLE............................................22 69 3.7 CHOSEN PLAINTEXT ATTACKS.....................................22 70 3.8 CBC MODE ATTACKS............................................. 71 3.9 SPOOFING BY COUNTERFEIT SERVERS..............................23 72 3.10 STORING PASSWORDS...........................................23 73 3.11 MULTIPLE REALMS.............................................24 74 3.12 SUMMARY.....................................................24 75 4 EXAMPLE.........................................................24 76 5 REFERENCES......................................................26 77 5.1 NORMATIVE REFERENCES.........................................26 78 5.2 INFORMATIVE REFERENCES.......................................27 79 6 IANA CONSIDERATIONS.............................................28 80 7 HBNF............................................................29 81 7.1 Enhanced BNF.................................................29 82 7.2 BASIC RULES..................................................31 83 8 SAMPLE CODE.....................................................33 84 9 AUTHORS' ADDRESSES..............................................XX 85 10 ACKNOWLEDGEMENTS..............................................34 86 11 FULL COPYRIGHT STATEMENT.......................................35 87 Appendix A: Changes from 2831.....................................36 88 Appendix B: Open Issues...........................................37 90 <> 93 1 Introduction 95 This specification describes the use of HTTP Digest Access 96 Authentication as a SASL mechanism. The authentication type 97 associated with the Digest SASL mechanism is "DIGEST-MD5". 99 This specification is intended to be upward compatible with the 100 "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication 101 specified in [Digest]. The only difference in the "md5-sess" 102 algorithm is that some directives not needed in a SASL mechanism have 103 had their values defaulted. 105 There is <>: integrity 106 and confidentiality protection on application protocol messages after 107 an authentication exchange. 109 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext 110 attacks, and permits the use of third party authentication servers, 111 mutual authentication, and optimized reauthentication if a client has 112 recently authenticated to a server. 114 1.1 Conventions and Notation 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC 2119]. 120 This specification uses the same EnHanced BNF notation (referred to 121 as HBNF in this document) and lexical conventions as HTTP/1.1 122 specification; see section 7. 124 Let { a, b, ... } be the concatenation of the octet strings a, b, ... 126 Let ** denote the power operation. 128 Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s. 130 Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string 131 k, a colon and the string s. 133 Let HEX(n) be the representation of the 16 octet MD5 hash n as a 134 string of 32 hex digits (with alphabetic characters always in lower 135 case, since MD5 is case sensitive). 137 Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet 138 string s using the octet string k as a key. 140 Let unq(X) be the value of the quoted-string X without the 141 surrounding quotes and with all escape characters "\\" removed. For 142 example for the quoted-string "Babylon" the value of unq("Babylon") 143 is Babylon; for the quoted string "ABC\"123\\" the value of 144 unq("ABC\"123\\") is ABC"123\. 146 The value of a quoted string constant as an octet string does not 147 include any terminating nul (0x00) character. 149 Let prep(X) be the value returned by the preparation function (see 150 description of "prep" directive in section 2.1.1). 152 Other terms like "protocol profile" are defined in RFC4422. 154 1.2 Channel Bindings 156 "Channel binding" is a concept described in [GSS-API] and which 157 refers to the act of cryptographically binding authentication at one 158 network layer to a secure channel at another layer and where the end- 159 points at both layers are the same entities. In the context of the 160 DIGEST-MD5 SASL mechanism this means ensuring that the challenge and 161 response messages include the "channel bindings" of any cryptographic 162 channel (e.g. TLS) over which the DIGEST-MD5 exchange is transported, 163 and that the inputs to the digest function include the same as well. 164 The "channel bindings" of a channel here refer to information which 165 securely identifies one instance of such a channel to both endpoints 166 such that MITM attacks are detectable. For more discussions of 167 channel bindings, and the syntax of the channel binding data for 168 various security protocols, see [CHANNEL-BINDINGS]. 170 Channel bindings are herein added to DIGEST-MD5 by overloading the 171 nonce and cnonce fields of the digest-challenge and digest-response 172 messages, respectively. Because these nonces are treated as opaque 173 octet strings in previous versions of this mechanism such overloading 174 is backwards compatible. Because these nonces are used in the 175 construction of the response-value (i.e., as input to the digest 176 function) using these fields for carrying channel bindings data makes 177 the channel binding operation possible without requiring incompatible 178 changes to the message formats. The fact that the odds that older 179 implementations may select random nonces that resemble actual channel 180 bindings data are so low allows new implementations to detect old 181 peers and to decide whether to allow such peers or reject them 182 according to local policy. 184 2 Authentication 186 DIGEST-MD5 can operate in two modes. Initial authentication (section 187 2.1) is usually used when a client authenticates to a server for the 188 first time. If protocol profile supports initial client response 189 (see "Protocol profile requirements" in [SASL]) and the client 190 supports reauthentication and it has successfully authenticated to 191 the server before, the client may be able to use the more efficient 192 fast reauthentication mode as described in section 2.2. 194 The following sections describe these two modes in details. 196 2.1 Initial Authentication 198 If the client has not recently authenticated to the server, then it 199 must perform "initial authentication", as defined in this section. If 200 it has recently authenticated, then a more efficient form is 201 available, defined in the next section. 203 2.1.1 Step One 205 The server starts by sending a challenge. The data encoded in the 206 challenge is formatted according to the rules for the "digest- 207 challenge" defined as follows: 209 digest-challenge = 210 1#( realm / nonce / qop-options / stale / server-maxbuf / 211 charset / prep-opts / algorithm / cipher-opts / 212 auth-param ) 214 realm = "realm" "=" realm-value 215 realm-value = quoted-string 216 nonce = "nonce" "=" nonce-value 217 nonce-value = quoted-string 218 ;; contains data described by "nonce-data" 219 qop-options = "qop" "=" DQUOTE qop-list DQUOTE 220 qop-list = 1#qop-value 221 qop-value = "auth" / "auth-int" / "auth-conf" / 222 qop-token 223 ;; qop-token is reserved for identifying 224 ;; future extensions to DIGEST-MD5 225 qop-token = token 226 stale = "stale" "=" "true" 227 server-maxbuf = "maxbuf" "=" maxbuf-value 228 maxbuf-value = 1*DIGIT 229 charset = "charset" "=" "utf-8" 230 prep-opts = "prep" "=" DQUOTE prep-mechs DQUOTE 231 prep-mechs = 1#prep-mech 232 prep-mech = "rfc4013" 233 algorithm = "algorithm" "=" "md5-sess" 234 cipher-opts = "cipher" "=" DQUOTE cipher-list DQUOTE 235 cipher-list = 1#cipher-value 236 cipher-value = "rc4-40" / "rc4" / "rc4-56" / 237 "aes-ctr" / cipher-token 238 ;; cipher-token is reserved for 239 ;; new ciphersuites 240 cipher-token = token 241 auth-param = token "=" ( token / quoted-string ) 242 nonce-data = new-nonce-data / obs-nonce-data 243 new-nonce-data = "CB-" channel-type ":" channel-bindings 244 ":" qop-list ":" cipher-list 245 ":" nonce-octets 246 obs-nonce-data = nonce-octets 247 ;; nonce value as defined in RFC 2831. 248 ;; SHOULD be accepted. MUST NOT be 249 ;; generated. 250 <> 255 channel-bindings = 1*TEXTCHAR 256 ;; channel binding data as defined by 257 ;; the channel type 258 nonce-octets = 1*TEXTCHAR 260 The meanings of the values of the directives used above are as 261 follows: 263 realm 264 Mechanistically, a string which enables users to decide which 265 username and password to use, in case they have different ones for 266 different servers. Conceptually, it is the name of a collection 267 of accounts that might include the user's account. This string 268 should contain the name of the host performing the authentication 269 and might additionally indicate the collection of users who might 270 have access. An example might be 271 "registered_users@gotham.news.example.com". Note that the server 272 MAY not advertise (hide) some or all realms it supports. 274 Other examples: 276 1) "dc=gotham, dc=news, dc=example, dc=com". 278 2) If there are two servers (e.g. server1.example.com and 279 server2.example.com) that share authentication database, they 280 both may advertise "example.com" as the realm. 282 A server implementation that uses a fixed string as the advertised 283 realm is compliant with this specification, however this is not 284 recommended. See also sections 3.10 "Storing passwords" and 3.11 285 "Multiple realms" for discussion. 287 The value of this directive is case-sensitive. This directive is 288 optional; if not present, the client SHOULD solicit it from the 289 user or be able to compute a default; a plausible default might be 290 the realm supplied by the user when they logged in to the client 291 system. Multiple realm directives are allowed, in which case the 292 user or client must choose one as the realm for which to supply 293 username and password. 295 Requirements on UIs: UIs MUST allow users to enter arbitrary user 296 names and realm names. In order to achieve this, UIs MAY present 297 two separate edit boxes. Alternatively, UIs MAY present a single 298 edit box and allow user to enter a special character that 299 separates user name from the realm name. In the latter case, UIs 300 MUST be able to escape the special character and they need to 301 present their escape rules to the user. UIs MUST also present the 302 list of realms advertised by the server. 304 nonce 305 A server-specified string erstwhile intended to add entropy to the 306 challenge. The nonce field may be used to exchange channel 307 binding data. 309 This directive is required and MUST appear exactly once; if not 310 present, or if multiple instances are present, the client should 311 abort the authentication exchange. 313 Older implementations typically generate some random or pseudo- 314 random data and base64 [RFC 4648] or hexadecimally encode it. 315 When channel binding is not used the nonce string MUST be 316 different each time a digest-challenge is sent as part of initial 317 authentication. It is RECOMMENDED that the random data contain at 318 least 64 bits of entropy. 320 When channel binding is performed, the nonce must be generated 321 from: the channel type, the bindings to the channel being bound 322 to, copy of the server specified qop-list (*), copy of the server 323 specified list of ciphers or empty string if none were specified 324 and an actual nonce consisting of 64-bits or more of entropy and 325 base64-encoded, and formatted as follows: 327 "CB-" ":" ":" ":" 328 ":" 330 See [CHANNEL-BINDINGS] for the syntax of the channel binding data 331 for various security protocols. 333 An actual nonce is included in order to allow for channel bindings 334 to possible future channels with channel bindings data which is 335 not necessarily unique for each instance. 337 When channel bindings are in use, clients MUST reject challenges 338 that contain server nonce values of this form and whose channel 339 bindings do not match those of the actual underlying channel as 340 observed by the client. Also clients MUST reject challenges that 341 contain server nonce values of this form and that contain qop-list 342 and/or cipher-list that don't match the values sent in the 343 qop/cipher directives respectively. 345 (*) - Note that if the server specified multiple "qop" directives, 346 this field MUST be constructed by extracting all qop-list values 347 (in the order they were specified) and inserting "," between them. 348 For example, if the server sent: 349 qop="auth",qop="auth-int" this field must have the value 350 "auth,auth-int" (with no quotes). 352 qop-options 353 A quoted string of one or more comma-separated tokens indicating 354 the "quality of protection" values supported by the server. The 355 value "auth" indicates authentication; the value "auth-int" 356 indicates authentication with integrity protection; the value 357 "auth-conf" indicates authentication with integrity protection and 358 encryption. This directive is optional; if not present it 359 defaults to "auth". The client MUST ignore unrecognized options; 360 if the client recognizes no option, it MUST abort the 361 authentication exchange. 363 If this directive is present multiple times the client MUST treat 364 it as if it received a single qop directive containing a comma 365 separated value from all instances. I.e., 'qop="auth",qop="auth- 366 int"' is the same as 'qop="auth,auth-int"'. 368 stale 369 The "stale" directive is not used in initial authentication. See 370 the next section for its use in subsequent authentications. This 371 directive may appear at most once; if multiple instances are 372 present, the client MUST abort the authentication exchange. 374 server-maxbuf ("maximal ciphertext buffer size") 375 A number indicating the size of the largest buffer (in bytes) the 376 server is able to receive when using "auth-int" or "auth-conf". 377 The value MUST be bigger than 16 and smaller or equal to 16777215 378 (i.e. 2**24-1). If this directive is missing, the default value is 379 65536. This directive may appear at most once; if multiple 380 instances are present, or the value is out of range the client 381 MUST abort the authentication exchange. 383 Let "maximal cleartext buffer size" (or "maximal sender size") be 384 the maximal size of a cleartext buffer that, after being 385 transformed by integrity (section 2.3) or confidentiality (section 386 2.4) protection function, will produce a SASL block of the maxbuf 387 size. As it should be clear from the name, the sender MUST never 388 pass a block of data bigger than the "maximal sender size" through 389 the selected protection function. This will guarantee that the 390 receiver will never get a block bigger than the maxbuf. 392 charset 393 This directive, if present, specifies that the server supports 394 UTF-8 [UTF-8] encoding for the username, realm and password. If 395 present, the username, realm and password are encoded as UTF-8 396 [UTF-8]. If not present, the username, realm and password used by 397 the client in Step 2 MUST be encoded in ISO 8859-1 [ISO-8859] (of 398 which US-ASCII [USASCII] is a subset). The directive is needed for 399 backwards compatibility with HTTP Digest<<, which only supports 400 ISO 8859-1>>. This directive may appear at most once; if multiple 401 instances are present, the client MUST abort the authentication 402 exchange. 404 Note, that this directive doesn't affect authorization id 405 ("authzid"). 407 prep-opts 408 Servers compliant with this specification MUST include this 409 directive. 411 If present, it contains a comma separated list of 412 username/password preparation algorithms supported by the server. 413 That is, if user credentials are stored as one or more "SS" (see 414 section 2.1.2.1) values, then the server signals to the client 415 which username/password preparation algorithms were used when the 416 "SS" value(s) were created. If cleartext user password is stored, 417 the server returns "rfc4013" (see below) as the value of this 418 directive. 420 This document defines only a single value "rfc4013", which means 421 that the server supports "SASLPrep" profile [SASLPrep] of the 422 "stringprep" algorithm [RFC 3454]. 424 <> 430 <> >> 435 If this directive is missing, the server doesn't support any 436 preparation algorithm, i.e. the server is an RFC 2831 only server. 438 If this directive is present multiple times the client MUST treat 439 it as if it received a single prep-opts directive containing a 440 comma separated value from all instances. 442 algorithm 443 This directive is required for backwards compatibility with HTTP 444 Digest, which supports other algorithms. This directive is 445 required and MUST appear exactly once; if not present, or if 446 multiple instances are present, the client SHOULD abort the 447 authentication exchange. 449 cipher-opts 450 A list of ciphers that the server supports. This directive must be 451 present exactly once if "auth-conf" is offered in the 452 "qop-options" directive, in which case the "aes-ctr" cipher is 453 mandatory-to-implement. The client MUST ignore unrecognized 454 ciphers; if the client recognizes no cipher, it MUST behave as if 455 "auth-conf" qop option wasn't provided by the server. If the 456 client recognizes no cipher and the server only advertised "auth- 457 conf" in the qop option, the client MUST abort the authentication 458 exchange. See section 2.4 for more detailed description of the 459 ciphers. 461 rc4, rc4-40, rc4-56 462 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, 463 respectively. 465 aes-ctr 466 the Advanced Encryption Standard (AES) cipher [AES] in counter 467 (CTR) mode with a 128 bit key. This mode requires an IV that 468 has the same size as the block size. 470 auth-param 471 This construct allows for future extensions; it may appear more 472 than once. The client MUST ignore any unrecognized directives. 474 For use as a SASL mechanism, note that the following changes are made 475 to "digest-challenge" from HTTP: the following Digest options (called 476 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, 477 and MUST be ignored if received): 479 opaque 480 domain 482 The size of a "digest-challenge" MUST be less than 2048 bytes. 484 2.1.2 Step Two 486 The client validates "digest-challenge" as described in the previous 487 section. In particular, when channel bindings are in use, client MUST 488 reject "digest-challenge" that contain server nonce whose channel 489 bindings do not match those of the actual underlying channel as 490 observed by the client. 492 The client makes note of the "digest-challenge" and then responds 493 with a string formatted and computed according to the rules for a 494 "digest-response" defined as follows: 496 digest-response = 1#( username / realm / nonce / cnonce / 497 nonce-count / qop / digest-uri / response / 498 response-v2 / client-maxbuf / charset / prep / 499 cipher / authzid / auth-param ) 501 username = "username" "=" username-value 502 username-value = quoted-string 503 cnonce = "cnonce" "=" cnonce-value 504 cnonce-value = nonce-value 505 nonce-count = "nc" "=" nc-value 506 nc-value = 8LHEX 507 client-maxbuf = "maxbuf" "=" maxbuf-value 508 qop = "qop" "=" qop-value 509 digest-uri = "digest-uri" "=" 510 DQUOTE digest-uri-value DQUOTE 511 digest-uri-value = serv-type "/" host [ "/" serv-name ] 512 serv-type = 1*ALPHA 513 serv-name = host 514 prep = "prep" "=" prep-mech 515 response = "response" "=" response-value 516 response-v2 = "response-v2" "=" response-value 517 response-value = 32LHEX 518 LHEX = DIGIT / "a" / "b" / 519 "c" / "d" / "e" / "f" 520 cipher = "cipher" "=" cipher-value 521 authzid = "authzid" "=" authzid-value 522 authzid-value = quoted-string 524 The 'host' non-terminal is defined in [RFC 3986] as 526 host = IP-literal / IPv4address / reg-name 528 username 529 The user's name in the specified realm, encoded according to the 530 value of the "charset" directive. This directive is REQUIRED and 531 MUST be present exactly once; otherwise, authentication fails. 533 <> 540 realm 541 The realm containing the user's account, encoded according to the 542 value of the "charset" directive. This directive MUST appear at 543 most once and SHOULD contain one of the realms provided by the 544 server in the "digest-challenge". If the directive is missing, 545 "realm-value" will set to the empty string when computing A1 (see 546 below for details). 548 <> 555 nonce 556 The server-specified data string received in the preceding digest- 557 challenge. This directive is required and MUST be present exactly 558 once; otherwise, authentication fails. 560 cnonce 561 A client-specified string erstwhile intended to add entropy to the 562 challenge. The cnonce field may be used to exchange channel 563 binding data. 565 This directive is required and MUST be present exactly once; 566 otherwise, authentication fails. 568 Older implementations typically generate some random or pseudo- 569 random data and base64 [RFC 4648] or hexadecimally encode it. 570 When channel binding is not used the cnonce string MUST be 571 different each time a digest-challenge is sent as part of initial 572 authentication. It is RECOMMENDED that the random data contain at 573 least 64 bits of entropy. 575 When channel binding is performed, the cnonce must be generated 576 from: the channel type, the bindings to the channel being bound 577 to, copy of the client selected qop, copy of the client selected 578 cipher or cipher="" if none were selected (i.e. for qop=auth or 579 qop=auth-int), and an actual nonce consisting of 64-bits or more 580 of entropy and base64-encoded, and formatted as follows: 582 "CB-" ":" ":" ":" 583 [] ":" 585 See [CHANNEL-BINDINGS] for the syntax of the channel binding data 586 for various security protocols. 588 An actual nonce is included in order to allow for channel bindings 589 to possible future channels with channel bindings data which is 590 not necessarily unique for each instance. It is used by both 591 client and server to avoid chosen plaintext attacks, and to 592 provide mutual authentication. 594 When channel bindings are in use, servers MUST reject responses 595 that contain client nonce values of this form and whose channel 596 bindings do not match those of the actual underlying channel as 597 observed by the server. Also servers MUST reject responses that 598 contain client nonce values of this form and that contain qop-list 599 and/or cipher-list that don't match the values sent in the 600 qop/cipher directives respectively. 602 <> 604 nonce-count 605 The nc-value is the hexadecimal count of the number of requests 606 (including the current request) that the client has sent with the 607 nonce value in this request. For example, in the first request 608 sent in response to a given nonce value, the client sends 609 "nc=00000001". The purpose of this directive is to allow the 610 server to detect request replays by maintaining its own copy of 611 this count - if the same nc-value is seen twice, then the request 612 is a replay. See the description below of the construction of the 613 response value. This directive is required and MUST be present 614 exactly once; otherwise, or if the value is 0, authentication 615 fails. 617 qop 618 Indicates what "quality of protection" the client accepted. If 619 present, it may appear exactly once and its value MUST be one of 620 the alternatives in qop-options. If not present, it defaults to 621 "auth". These values affect the computation of the response. Note 622 that this is a single token, not a quoted list of alternatives. 624 serv-type 625 Indicates the type of service, such as "http" for web service, 626 "ftp" for FTP service, "smtp" for mail delivery service, etc. The 627 service name as defined in the SASL profile for the protocol see 628 section 4 of [SASL], registered in the IANA registry of "service" 629 elements for the GSSAPI host-based service name form [GSS-API]. 631 host 632 The DNS host name or IP (IPv4 or IPv6) address for the service 633 requested. The DNS host name must be the fully-qualified 634 canonical name of the host. The DNS host name is the preferred 635 form; see notes on server processing of the digest-uri. 637 serv-name 638 Indicates the name of the service if it is replicated. The service 639 is considered to be replicated if the client's service-location 640 process involves resolution using standard DNS lookup operations, 641 and if these operations involve DNS records (such as SRV 643 [RFC-2782], or MX) which resolve one DNS name into a set of other 644 DNS names. In this case, the initial name used by the client is 645 the "serv-name", and the final name is the "host" component. For 646 example, the incoming mail service for "example.com" may be 647 replicated through the use of MX records stored in the DNS, one of 648 which points at an SMTP server called "mail3.example.com"; it's 649 "serv-name" would be "example.com", it's "host" would be 650 "mail3.example.com". If the service is not replicated, or the 651 serv-name is identical to the host, then the serv-name component 652 MUST be omitted. 654 digest-uri 655 Indicates the principal name of the service with which the client 656 wishes to connect, formed from the serv-type, host, and serv-name. 657 For example, the FTP service on "ftp.example.com" would have a 658 "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from 659 the example above would have a "digest-uri" value of 660 "SMTP/mail3.example.com/example.com". 662 Servers SHOULD check that the supplied value is correct. This will 663 detect accidental connection to the incorrect server, as well as 664 some redirection attacks. It is also so that clients will be 665 trained to provide values that will work with implementations that 666 use a shared back-end authentication service that can provide 667 server authentication. 669 The serv-type component should match the service being offered. 670 The host component should match one of the host names of the host 671 on which the service is running, or it's IP address. Servers 672 SHOULD NOT normally support the IP address form, because server 673 authentication by IP address is not very useful; they should only 674 do so if the DNS is unavailable or unreliable. The serv-name 675 component should match one of the service's configured service 676 names. 678 This directive is required and MUST be present exactly once; if 679 multiple instances are present, the server MUST abort the 680 authentication exchange. 682 Note: In the HTTP use of Digest authentication, the digest-uri is 683 the URI (usually a URL) of the resource requested -- hence the 684 name of the directive. 686 response 687 A string of 32 hex digits computed as defined below, which proves 688 that the user knows a password. This directive is REQUIRED and 689 MUST be present exactly once; otherwise, authentication fails. 691 response-v2 692 A string of 32 hex digits computed as defined below, which proves 693 that the user knows a password. This directive MUST be present at 694 most once; if it is present multiple times, then authentication 695 fails. If during SS calculation (see section 2.1.2.1) preparation 696 of the username and/or the password fails or results in an empty 697 string (*), then the client MUST NOT send this directive. Also, if 698 none of the values in the server's "prep-opts" directive is 699 recognized, then this directive MUST NOT be sent. 701 (*) In this case an interactive client can request a repeated 702 entry of the username and/or the password. 704 client-maxbuf 705 A number indicating the size of the largest ciphertext buffer the 706 client is able to receive when using "auth-int" or "auth-conf". If 707 this directive is missing, the default value is 65536. This 708 directive may appear at most once; if multiple instances are 709 present, the server MUST abort the authentication exchange. If the 710 value is less or equal to 16, or bigger than 16777215 (i.e. 711 2**24-1), the server MUST abort the authentication exchange. 713 Upon processing/sending of the client-maxbuf value both the server 714 and the client calculate their "maximal ciphertext buffer size" as 715 the minimum of the server-maxbuf (Step One) and the client-maxbuf 716 (Step Two). The "maximal sender size" can be calculated by 717 subtracting 16 from the calculated "maximal ciphertext buffer 718 size". 720 When sending a block of data the client/server MUST NOT pass more 721 than the "maximal sender size" bytes of data to the selected 722 protection function (2.3 or 2.4). 724 charset 725 This directive, if present, specifies that the client has used 726 UTF-8 [UTF-8] encoding for the username, realm and password. If 727 present, the username, realm and password are encoded as UTF-8 728 [UTF-8]. If not present, the username, realm and password MUST be 729 encoded in ISO 8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a 730 subset). The client should send this directive only if the server 731 has indicated that it supports UTF-8 [UTF-8]. The directive is 732 needed for backwards compatibility with HTTP Digest<<, which only 733 supports ISO 8859-1>>. 735 This directive may appear at most once; if multiple instances are 736 present, the server MUST abort the authentication exchange. 738 Note, that this directive doesn't affect the authorization 739 identity ("authzid"). 741 prep 742 This directive, if present, specifies which username/password 743 preparation algorithms has been used by the client when 744 calculating response-v2. This directive MUST contain one of the 745 values specified in the "prep-opts" directive from the digest- 746 challenge, or authentication exchange fails. This document 747 defines only a single possible value "rfc4013", which means 748 support for [SASLPrep]. Future Standard Track or Experimantal 749 documents may define other values for this directive. <> 753 <> 756 <> 761 This directive may appear at most once; if multiple instances are 762 present, the server MUST abort the authentication exchange. 764 LHEX 765 32 hex digits, where the alphabetic characters MUST be lower case, 766 because MD5 is case sensitive. 768 cipher 769 The cipher chosen by the client. This directive MUST appear 770 exactly once if "auth-conf" is negotiated; if required and not 771 present, authentication fails. If the cipher chosen by the client 772 is not one of the ciphers advertised by the server, authentication 773 fails. 775 authzid 776 The "authorization ID" (authzid) directive may appear at most 777 once; if multiple instances are present, the server MUST abort the 778 authentication exchange. If present, and the authenticating user 779 has sufficient privilege, and the server supports it, then after 780 authentication the server will use this identity for making all 781 accesses and access checks. If the client specifies it, and the 782 server does not support it, then the response-value calculated on 783 the server will not match the one calculated on the client and 784 authentication will fail. 786 The authorization identifier is always in UTF-8, in particular the 787 "charset" directive doesn't affect how this value is encoded. 789 The authzid MUST NOT be an empty string. 791 Upon the receipt of this value the server verifies its correctness 792 according to the used SASL protocol profile. 794 The size of a digest-response MUST be less than 4096 bytes. 796 2.1.2.1 Response-value 798 The definition of "response-value" above indicates the encoding for 799 its value -- 32 lower case hex characters. The following definitions 800 show how the value is computed. 802 Note that the algorithm described below applies to both "response" 803 and "response-v2" options. The only difference between the two is in 804 how "SS" value is calculated. 806 Although qop-value and components of digest-uri-value may be 807 case-insensitive, the case which the client supplies in step two is 808 preserved for the purpose of computing and verifying the 809 response-value. 811 response-value = 812 HEX( KD ( HEX(H(A1)), 813 { unq(nonce-value), ":" nc-value, ":", 814 unq(cnonce-value), ":", qop-value, ":", 815 HEX(H(A2)) })) 817 If authzid is specified, then A1 is 819 A1 = { SS, ":", unq(nonce-value), ":", 820 unq(cnonce-value), ":", unq(authzid-value) } 822 If authzid is not specified, then A1 is 824 A1 = { SS, ":", unq(nonce-value), ":", unq(cnonce-value) } 826 where 828 password = *OCTET 830 For "response" option, SS is calculated as follows: 832 SS = H( { unq(username-value), ":", 833 unq(realm-value), ":", password } ) 835 For "response-v2" option, SS is calculated as follows: 837 SS = H( { prep(unq(username-value)), ":", 838 unq(realm-value)), ":", prep(password) } ) 840 where prep(X) is the preparation function described by the "prep" 841 directive. 842 <> 844 <> 849 If the "qop" directive's value is "auth", then A2 is: 851 A2 = { "AUTHENTICATE:", digest-uri-value } 853 If the "qop" value is "auth-int" or "auth-conf" then A2 is: 855 A2 = { "AUTHENTICATE:", digest-uri-value, 856 ":00000000000000000000000000000000" } 858 Note that "AUTHENTICATE:" must be in upper case, and the second 859 string constant is a string with a colon followed by 32 zeros. 861 These apparently strange values of A2 are for compatibility with 862 HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and 863 the hash of the entity body to zero in the HTTP digest calculation of 864 A2. 866 Also, in the HTTP usage of Digest, several directives in the 867 "digest-challenge" sent by the server have to be returned by the 868 client in the "digest-response". These are: 870 opaque 871 algorithm 873 These directives are not needed when Digest is used as a SASL 874 mechanism (i.e., MUST NOT be sent, and MUST be ignored if received). 876 2.1.3 Step Three 878 The server receives and validates the "digest-response". In 879 particular, the server verifies that all required directives are 880 present and they don't appear more times than expected. See section 881 2.1.2 for details. 883 The server also does the following checks: 885 1) When channel bindings are in use, server MUST reject "digest- 886 response" that contain client nonce whose channel bindings do not 887 match those of the actual underlying channel as observed by the 888 server. 890 2) The server checks that the nonce-count is "00000001". If it 891 supports subsequent authentication (see section 2.2), it saves the 892 value of the "nonce-octets" part of the nonce and the nonce-count. 894 3) The server verifies the received "response" and "response-v2" 895 values. (Note that the "response-v2" might be absent). If either 896 one of them matches the corresponding value calculated by the server, 897 then the server can assume that the client proved that it knows its 898 password. 900 4) If the client sent the "authzid" directive, the server verifies 901 its correctness according to the used SASL protocol profile. If the 902 "authzid" directive is not present or its correctness is verified, 903 then the server can consider the client to be successfully 904 authenticated. 906 Upon successful client authentication the server sends a message 907 formatted as follows: 909 auth-info = 1#( response-auth / response-v2-auth / auth-param ) 911 response-auth = "rspauth" "=" response-value 912 response-v2-auth = "rspauth-v2" "=" response-value 914 where response-value is calculated as above (the "rspauth" is 915 calculated as client's "response" and the "rspauth-v2" is calculated 916 as client's "response-v2"), using the values sent in step two, except 917 that if qop is "auth", then A2 is 919 A2 = { ":", digest-uri-value } 921 And if qop is "auth-int" or "auth-conf" then A2 is 923 A2 = { ":", digest-uri-value, 924 ":00000000000000000000000000000000" } 926 The server sends one of response-auth, response-v2-auth, depending on 927 whether it was able to match client's "response" or "response-v2". 928 Note that only one occurance of the "response-auth"/"response- 929 v2-auth" is allowed. If more than one is found, the client MUST 930 treat this as an authentication error. 932 Compared to its use in HTTP, the following Digest directives in the 933 "auth-info" are unused: 935 nextnonce 936 qop 937 cnonce 938 nonce-count 940 The size of an auth-info MUST be less than 2048 bytes. 942 2.2 Subsequent Authentication 944 If the client has previously authenticated to the server, and 945 remembers the values of username, realm, nonce, nonce-count, cnonce, 946 and qop that it used in that authentication, and the SASL profile for 947 a protocol permits an initial client response, then it MAY perform 948 "subsequent authentication" (also known as "fast reauthentication"), 949 as defined in this section. Note, that a subsequent authentication 950 can be done on a different connection, or on the same connection, if 951 the protocol profile also permits multiple authentications. 953 2.2.1 Step one 955 The client uses the values from the previous authentication and sends 956 an initial response with a string formatted and computed according to 957 the rules for a "digest-response", as defined in section 2.1.2, after 958 applying the following changes: 960 1) the nonce-count value is one greater than used in the last 961 "digest-response" 963 2) if nonce/cnonce values contained any channel bindings information, 964 it 965 MUST be replaced with the channel bindings, qop and cipher lists 966 relevant 967 for the new connection. 968 In other words, only the "nonce-octets" part of nonce/cnonce 969 "nonce-data" 970 MUST be preserved on reauthentication. 972 2.2.2 Step Two 974 The server receives the "digest-response". If the server does not 975 support subsequent authentication, then it sends a 976 "digest-challenge", and authentication proceeds as in initial 977 authentication. If the server has no saved nonce, cnone and nonce- 978 count from a previous authentication, then it sends a "digest- 979 challenge", and authentication proceeds as in initial authentication. 980 Otherwise, the server validates the "digest-response"; checks that 981 values of the username, the realm, the qop and nonce-octets part of 982 the nonce and the cnonce are the same as in the original 983 authentication attempt; checks that the nonce-count is one greater 984 than that used in the previous authentication using that nonce, and 985 saves the new value of nonce-count. 987 If the response is invalid, then the server sends a 988 "digest-challenge", and authentication proceeds as in initial 989 authentication (and should be configurable to log an authentication 990 failure in some sort of security audit log, since the failure may be 991 a symptom of an attack). The nonce-count MUST NOT be incremented in 992 this case: to do so would allow a denial of service attack by sending 993 an out-of-order nonce-count. 995 If the response is valid, the server MAY choose to deem that 996 authentication has succeeded. However, if it has been too long since 997 the previous authentication, or for any other reason, the server MAY 998 send a new "digest-challenge" with a new value for nonce. The 999 challenge MAY contain a "stale" directive with value "true", which 1000 says that the client may respond to the challenge using the password 1001 it used in the previous response; otherwise, the client must solicit 1002 the password anew from the user. This permits the server to make sure 1003 that the user has presented their password recently. (The directive 1004 name refers to the previous nonce being stale, not to the last use of 1005 the password.) Except for the handling of "stale", after sending the 1006 "digest-challenge" authentication proceeds as in the case of initial 1007 authentication. 1009 2.3 Integrity Protection 1011 If the server offered "qop=auth-int" and the client responded 1012 "qop=auth-int", then subsequent messages, up to but not including the 1013 next subsequent authentication, between the client and the server 1014 MUST be integrity protected. Using as a base session key the value of 1015 H(A1), as defined above the client and server calculate a pair of 1016 message integrity keys as follows. 1018 The key for integrity protecting messages from client to server is: 1020 Kic = H({H(A1), 1021 "Digest session key to client-to-server signing key magic constant"}) 1023 The key for integrity protecting messages from server to client is: 1025 Kis = H({H(A1), 1026 "Digest session key to server-to-client signing key magic constant"}) 1028 where MD5 is as specified in [RFC 1321]. If message integrity is 1029 negotiated, a MAC block for each message is appended to the message. 1030 The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC 1031 2104] of the message, a 2-byte message type number in network byte 1032 order with value 1, and the 4-byte sequence number in network byte 1033 order. The message type is to allow for future extensions such as 1034 rekeying. 1036 MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001, 1037 SeqNum) 1039 where Ki is Kic for messages sent by the client and Kis for those 1040 sent by the server. The sequence number (SeqNum) is an unsigned 1041 number initialized to zero after initial or subsequent 1042 authentication, and incremented by one for each message 1043 sent/successfully verified. (Note, that there are two independent 1044 counters for sending and receiving.) The sequence number wraps around 1045 to 0 after 2**32-1. 1047 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the 1048 received value; the message is discarded if they differ and as the 1049 result the connection being used MUST be dropped. The receiver's 1050 sequence counter is incremented if they match. 1052 2.4 Confidentiality Protection 1054 If the server sent a "cipher-opts" directive and the client responded 1055 with a "cipher" directive, then subsequent messages between the 1056 client and the server MUST be confidentiality protected. Using as a 1057 base session key the value of H(A1) as defined above the client and 1058 server calculate a pair of message integrity keys as follows. 1060 The key for confidentiality protecting messages from client to server 1061 is: 1063 Kcc = H({H(A1)[0..n-1], 1064 "Digest H(A1) to client-to-server sealing key magic constant"}) 1066 The key for confidentiality protecting messages from server to client 1067 is: 1069 Kcs = H({H(A1)[0..n-1], 1070 "Digest H(A1) to server-to-client sealing key magic constant"}) 1072 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; 1073 for "rc4-56" n is 7; for the rest n is 16. The key for the "rc4-*" 1074 and "aes-ctr" ciphers is all 16 bytes of Kcc or Kcs. 1076 "aes-ctr" cipher works as described in section 2.4.1. 1078 rc4 cipher state MUST NOT be reset before sending/receiving a next 1079 buffer of protected data. 1081 If the blocksize of the chosen cipher is not 1 byte, the padding 1082 prefix is one or more octets each containing the number of padding 1083 bytes, such that the total length of the encrypted part of the 1084 message is a multiple of the blocksize. 1086 The MAC block is 16 bytes formatted as follows: the first 10 bytes of 1087 the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number 1088 in network byte order with value 1, and the 4-byte sequence number in 1089 network byte order. 1091 The padding and first 10 bytes of the MAC block are encrypted with 1092 the chosen cipher along with the message. 1094 SEAL(Ki, Kc, SeqNum, msg) = CIPHER(Kc, {msg, pad, MAC}) 1096 MAC(Ki, SeqNum, msg) = {HMAC(Ki, {SeqNum, msg})[0..9], 1097 packet_type_data, SeqNum} 1099 packet_type_data = 0x0001 1101 where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for 1102 messages sent by the client and Kis and Kcs for those sent by the 1103 server. The sequence number (SeqNum) is an unsigned number 1104 initialized to zero after initial or subsequent authentication, and 1105 incremented by one for each message sent/successfully verified. 1106 (Note, that there are two independent counters for sending and 1107 receiving.) The sequence number wraps around to 0 after 2**32-1. 1109 Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is 1110 computed and compared with the received value; the padding and the 1111 packet type are verified. The message is discarded if the received 1112 and the calculated HMACs differ and/or the padding is invalid. See 1113 also section 3.8 for important information about MAC and padding 1114 verification. The receiver's sequence counter is then compared with 1115 the received SeqNum value; the message is discarded if they differ 1116 and, as the result, the connection being used MUST be dropped. The 1117 receiver's sequence counter is incremented if they match. 1119 2.4.1 AES cipher in "stateful-decryption counter" mode ("aes-ctr") 1121 In stateful-decryption counter mode, both the sender and the receiver 1122 maintain an internal 128-bit counter CTRBLK. 1124 The initial value of the CTRLBLK is calculated as follows: 1126 The counter for the first SASL packet going from the client 1127 to the server consists of 16 bytes calculated as follows: 1129 CTRBLK = H({H(A1), "aes-128 counter client-to-server", nc-value}) 1131 The counter for the first SASL packet going from the server 1132 to the client consists of 16 bytes calculated as follows: 1134 CTRBLK = H({H(A1), "aes-128 counter server-to-client", nc-value}) 1136 <> 1139 For each buffer of cleartext data to be encrypted the sender performs 1140 the following procedure: 1142 1) padding and MAC block are constructed (see section 2.4) and 1143 appended to the end of the plaintext. After this step the data 1144 to be encrypted will look like: 1146 {msg, pad, MAC} 1148 As the total length of the data will be multiple of AES block size 1149 (i.e. 128 bit), this can also be represented as 1151 {P[1], P[2], P[3], ..., P[m]} 1153 where P[i] is a chunk of data of the length 128 bit. 1155 2) Data is encrypted as follows: 1157 FOR i := 1 to m DO 1158 E[i] := P[i] XOR CIPHER ( Kc, CTRBLK ) 1159 CTRBLK := CTRBLK + 1 1160 END 1162 This will generate ciphertext {E[1], ..., E[m]} to be sent as a 1163 single 1164 SASL packet. 1166 The initial CTRBLK value is constructed as described at the 1167 beginning of 1168 this section. The last CTRBLK value produced after encrypting P[m] 1169 is 1170 used to encrypt the first 128bit chunk of the next sent SASL 1171 packet 1172 (if any), end so on. 1174 If CTRBLK = (2**128)-1, then "CTRBLK + 1" has the traditional 1175 semantics of "set CTRBLK to 0." 1177 The receiver performs the following steps: 1179 1) Data is decrypted as follows: 1181 FOR i := 1 to m DO 1182 P[i] := E[i] XOR CIPHER ( Kc, CTRBLK ) 1183 CTRBLK := CTRBLK + 1 1184 END 1185 This will generate plaintext {P[1], ..., P[m]}, which is 1186 {msg, pad, MAC}. 1188 The initial CTRBLK value is constructed as described at the 1189 beginning of 1190 this section. The last CTRBLK value produced after decrypting P[m] 1191 is used to decrypt the first 128bit chunk of the next received 1192 SASL packet 1193 (if any), end so on. 1195 If CTRBLK = (2**128)-1, then "CTRBLK + 1" has the traditional 1196 semantics of "set CTRBLK to 0." 1198 2) pad and MAC block are verified as described in section 2.4. 1200 3 Security Considerations 1202 General SASL security considerations apply to this mechanism. 1203 "stringprep" and Unicode security considerations also apply. 1205 Detailed discussion of other DIGEST-MD5 specific security issues is 1206 below. 1208 3.1 Authentication of Clients using Digest Authentication 1210 Digest Authentication does not provide a strong authentication 1211 mechanism, when compared to public key based mechanisms, for example. 1212 However, since it prevents chosen plaintext attacks, it is stronger 1213 than (e.g.) CRAM-MD5, which has been proposed for use with ACAP 1214 [RFC-2244], POP and IMAP [RFC 2195]. It is intended to replace the 1215 much weaker and even more dangerous use of plaintext passwords; 1216 however, since it is still a password based mechanism it avoids some 1217 of the potential deployability issues with public-key, OTP or similar 1218 mechanisms. 1220 Digest Authentication offers no confidentiality protection beyond 1221 protecting the actual password. All of the rest of the challenge and 1222 response are available to an eavesdropper, including the user's name 1223 and authentication realm. 1225 3.2 Comparison of Digest with Plaintext Passwords 1227 The greatest threat to the type of transactions for which these 1228 protocols are used is network snooping. This kind of transaction 1229 might involve, for example, online access to a mail service whose use 1230 is restricted to paying subscribers. With plaintext password 1231 authentication an eavesdropper can obtain the password of the user. 1232 This not only permits him to access anything in the database, but, 1233 often worse, will permit access to anything else the user protects 1234 with the same password. 1236 3.3 Replay Attacks 1238 Replay attacks are defeated if the client or the server chooses a 1239 fresh nonce for each authentication, as this specification requires. 1241 As a security precaution, the server, when verifying a response from 1242 the client, must use the original server nonce ("nonce") it sent, not 1243 the one returned by the client in the response, as it might have been 1244 modified by an attacker. 1246 To prevent some redirection attacks it is recommended that the server 1247 verifies that the "serv-type" part of the "digest-uri" matches the 1248 service name and that the hostname/IP address belongs to the server. 1250 3.4 Online dictionary attacks 1252 If the attacker can eavesdrop, then it can test any overheard 1253 nonce/response pairs against a (potentially very large) list of 1254 common words. Such a list is usually much smaller than the total 1255 number of possible passwords. The cost of computing the response for 1256 each password on the list is paid once for each challenge. 1258 The server can mitigate this attack by not allowing users to select 1259 passwords that are in a dictionary. 1261 3.5 Offline dictionary attacks 1263 If the attacker can choose the challenge, then it can precompute the 1264 possible responses to that challenge for a list of common words. Such 1265 a list is usually much smaller than the total number of possible 1266 passwords. The cost of computing the response for each password on 1267 the list is paid just once. 1269 Offline dictionary attacks are defeated if the client chooses a fresh 1270 nonce for each authentication, as this specification requires. 1272 3.6 Man in the Middle 1274 Digest authentication is vulnerable to "man in the middle" (MITM) 1275 attacks. Clearly, a MITM would present all the problems of 1276 eavesdropping. But it also offers some additional opportunities to 1277 the attacker. 1279 A possible man-in-the-middle attack would be to substitute a weaker 1280 qop scheme for the one(s) sent by the server; the server will not be 1281 able to detect this attack. For this reason, the client should always 1282 use the strongest scheme that it understands from the choices 1283 offered, and should never choose a scheme that does not meet its 1284 minimum requirements. 1286 A man-in-the-middle attack may also make the client and the server 1287 that agreed to use confidentiality protection to use different (and 1288 possibly weaker) cipher's. This is because the chosen cipher is not 1289 used in the shared secret calculation. 1291 3.7 Chosen plaintext attacks 1293 A chosen plaintext attack is where a MITM or a malicious server can 1294 arbitrarily choose the challenge that the client will use to compute 1295 the response. The ability to choose the challenge is known to make 1296 cryptanalysis much easier [MD5]. 1298 However, Digest does not permit the attack to choose the challenge as 1299 long as the client chooses a fresh nonce for each authentication, as 1300 this specification requires. 1302 3.8 Attacks on padding 1304 In the past, implementations that treated bad padding differently 1305 from bad MACs during decryption were subject to different attacks. 1306 Note that such attacks are known for block ciphers in CBC mode, e.g. 1307 [VAUDENAY]. Even though this document doesn't define any ciphers in 1308 CBC mode, similar attacks might be used in the future against other 1309 ciphers. 1311 In order to mitigate risks of such attacks, it is recommended that 1312 implementations don't skip MAC verification when bad padding is found 1313 in order to obtain (nearly) uniform timing of sending failure 1314 responses. 1316 3.9 Spoofing by Counterfeit Servers 1318 If a user can be led to believe that she is connecting to a host 1319 containing information protected by a password she knows, when in 1320 fact she is connecting to a hostile server, then the hostile server 1321 can obtain challenge/response pairs where it was able to partly 1322 choose the challenge. There is no known way that this can be 1323 exploited. 1325 3.10 Storing passwords 1327 Digest authentication requires that the authenticating agent (usually 1328 the server) store some data derived from the user's name and password 1329 in a "password file" associated with a given realm. Normally this 1330 might contain pairs consisting of username and H({ username-value, 1331 ":", realm-value, ":", password }), which is adequate to compute 1332 H(A1) as described above without directly exposing the user's 1333 password. 1335 The security implications of this are that if this password file is 1336 compromised, then an attacker gains immediate access to documents on 1337 the server using this realm. Unlike, say a standard UNIX password 1338 file, this information need not be decrypted in order to access 1339 documents in the server realm associated with this file. On the other 1340 hand, decryption, or more likely a brute force attack, would be 1341 necessary to obtain the user's password. This is the reason that the 1342 realm is part of the digested data stored in the password file. It 1343 means that if one Digest authentication password file is compromised, 1344 it does not automatically compromise others with the same username 1345 and password (though it does expose them to brute force attack). 1347 There are two important security consequences of this. First the 1348 password file must be protected as if it contained plaintext 1349 passwords, because for the purpose of accessing documents in its 1350 realm, it effectively does. 1352 A second consequence of this is that the realm string should be 1353 unique among all realms that any single user is likely to use. In 1354 particular a realm string should include the name of the host doing 1355 the authentication. 1357 3.11 Multiple realms 1359 Use of multiple realms may mean both that compromise of a the 1360 security database for a single realm does not compromise all 1361 security, and that there are more things to protect in order to keep 1362 the whole system secure. 1364 3.11 Summary 1366 By modern cryptographic standards Digest Authentication is weak, 1367 compared to (say) public key based mechanisms. But for a large range 1368 of purposes it is valuable as a replacement for plaintext passwords. 1369 Its strength may vary depending on the implementation. 1371 4 Example 1373 This example shows the use of the Digest SASL mechanism with the 1374 IMAP4 AUTHENTICATE command [RFC 3501]. 1376 In this example, "C:" and "S:" represent a line sent by the client or 1377 server respectively including a CRLF at the end. Linebreaks and 1378 indentation within a "C:" or "S:" are editorial and not part of the 1379 protocol. The password in this example was "secret". Note that the 1380 base64 encoding of the challenges and responses is part of the IMAP4 1381 AUTHENTICATE command, not part of the Digest specification itself. 1383 S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9 1384 C: c CAPABILITY 1385 S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA 1386 UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN 1387 S: c OK Completed 1388 C: a AUTHENTICATE DIGEST-MD5 1389 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 1390 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 1391 cnNldD11dGYtOA== 1392 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 1393 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 1394 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 1395 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 1396 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= 1397 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1398 C: 1399 S: a OK User logged in 1400 --- 1402 The base64-decoded version of the SASL exchange is: 1404 S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth", 1405 algorithm=md5-sess,charset=utf-8 1406 C: charset=utf-8,username="chris",realm="elwood.innosoft.com", 1407 nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", 1408 digest-uri="imap/elwood.innosoft.com", 1409 response=d388dad90d4bbd760a152321f2143af7,qop=auth 1410 S: rspauth=ea40f60335c427b5527b84dbabcdfffd 1412 The password in this example was "secret". 1414 This example shows the use of the Digest SASL mechanism with the 1415 ACAP, using the same notational conventions and password as in the 1416 previous example. Note that ACAP does not base64 encode and uses 1417 fewer round trips that IMAP4. 1419 S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5" 1420 "DIGEST-MD5" "PLAIN") 1421 C: a AUTHENTICATE "DIGEST-MD5" 1422 S: + {94} 1423 S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth", 1424 algorithm=md5-sess,charset=utf-8 1425 C: {206} 1426 C: charset=utf-8,username="chris",realm="elwood.innosoft.com", 1427 nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m", 1428 digest-uri="acap/elwood.innosoft.com", 1429 response=6084c6db3fede7352c551284490fd0fc,qop=auth 1430 S: a OK (SASL {40} 1431 S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE 1432 Completed" 1433 --- 1435 The server uses the values of all the directives, plus knowledge of 1436 the users password (or the hash of the user's name, server's realm 1437 and the user's password) to verify the computations above. If they 1438 check, then the user has authenticated. 1440 5 References 1442 5.1 Normative references 1444 [Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest 1445 Access Authentication", RFC 2617, June 1999. 1447 [ISO-8859] ISO-8859. International Standard--Information Processing-- 1448 8-bit Single-Byte Coded Graphic Character Sets -- 1449 Part 1: Latin alphabet No. 1, ISO-8859-1:1987. 1450 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. 1451 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. 1452 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. 1453 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. 1454 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. 1455 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. 1456 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. 1457 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. 1459 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1460 April 1992. 1462 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1463 Hashing for Message Authentication", RFC 2104, February 1464 1997. 1466 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1467 Requirement Levels", BCP 14, RFC 2119, March 1997. 1469 [SASL] Melnikov, A. (editor) and K. Zeilenga "Simple Authentication 1470 and Security Layer (SASL)", RFC 4422, June 2006. 1472 [RFC 3454] Hoffman, P., Blanchet, M., "Preparation of 1473 Internationalized Strings ("stringprep")", RFC 3454, 1474 December 2002. 1476 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1477 3.2.0", defined by: The Unicode Standard, Version 3.0 1478 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 1479 as amended by the Unicode Standard Annex #28: Unicode 3.2 1480 (http://www.unicode.org/reports/tr28/tr28-3.html). 1482 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", 1483 STD 63, RFC 3629, November 2003. 1485 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard 1486 Code for Information Interchange. Standard ANSI X3.4-1986, 1487 ANSI, 1986. 1489 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 1490 and passwords", RFC 4013, February 2005. 1492 [RFC 3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1493 Resource Identifier (URI): Generic Syntax", RFC 3986, 1494 January 2005. 1496 [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher", 1497 http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf, 1498 3rd September 1999. 1500 [GSS-API] Linn, J., "Generic Security Service Application Program 1501 Interface Version 2, Update 1", RFC 2743, January 2000. 1503 [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax 1504 Specifications: ABNF", RFC 4234, October 2005. 1506 [CHANNEL-BINDINGS] Williams, N., "On the Use of Channel Bindings to 1507 Secure Channels", work in progress, draft-williams-on- 1508 channel-binding-00.txt. 1510 5.2 Informative references 1512 [RFC-2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1513 specifying the location of services (DNS SRV)", RFC 2782, 1514 February 2000. 1516 [RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP 1517 AUTHorize Extension for Simple Challenge/Response", RFC 1518 2195, September 1997. 1520 [MD5] Kaliski, B.,Robshaw, M., "Message Authentication with 1521 MD5", CryptoBytes, Sping 1995, RSA Inc, 1522 (ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto1n1.pdf) 1524 [RFC 3501] Crispin, M., "Internet Message Access Protocol - Version 1525 4rev1", RFC 3501, March 2003. 1527 [RFC-2244] Newman, C., Myers, J., "ACAP -- Application Configuration 1528 Access Protocol", RFC 2244, November 1997. 1530 [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1531 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext 1532 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1534 [VAUDENAY] Serge Vaudenay, "Security Flaws Induced by CBC Padding - 1535 Applications to SSL, IPSEC, WTLS ...". L.R. Knudsen (Ed.): 1536 EUROCRYPT 2002, LNCS 2332, pp. 534-545, 2002. 1538 [RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1539 Encodings", RFC 4648, October 2006. 1541 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 1542 MECHANISMS", . 1545 6 IANA Considerations 1547 It is requested that the SASL Mechanism registry [IANA-SASL] entry 1548 for the DIGEST-MD5 mechanism be updated to reflect that this document 1549 now provides its technical specification. 1551 To: iana@iana.org 1552 Subject: Updated Registration of SASL mechanism DIGEST-MD5 1554 Family of SASL mechanisms: NO 1555 SASL mechanism name: DIGEST-MD5 1556 Security considerations: See RFC XXXX. 1557 Published specification (optional, recommended): RFC XXXX 1558 Person & email address to contact for further information: 1559 Alexey Melnikov 1560 IETF SASL WG 1561 Intended usage: COMMON 1562 Author/Change controller: IESG 1563 Note: Updates existing entry for DIGEST-MD5 1565 7 HBNF 1567 <> 1576 7.1 EnHanced BNF 1578 All of the mechanisms specified in this document are described in 1579 both prose and an EnHanced Backus-Naur Form (HBNF) which is a 1580 superset of the ABNF defined in [ABNF]. The Enhanced BNF used by this 1581 document defines the following extra syntactic rule: 1583 #rule 1584 A construct "#" is defined, similar to "*", for defining lists of 1585 elements. The full form is "#element" indicating at least 1586 and at most elements, each separated by one or more commas 1587 (",") and OPTIONAL linear white space (LWSP). This makes the usual 1588 form of lists very easy; a rule such as 1589 ( LWSP element *( LWSP "," LWSP [element] ) LWSP ) 1590 can be shown as 1591 1#element 1592 Wherever this construct is used, null elements are allowed, but do 1593 not contribute to the count of elements present. That is, 1594 "(element), , (element) " is permitted, but counts as only two 1595 elements. Therefore, where at least one element is required, at 1596 least one non-null element MUST be present. Default values are 0 1597 and infinity so that "#element" allows any number, including zero; 1598 "1#element" requires at least one; and "1#2element" allows one or 1599 two. 1601 Other differences from [ABNF]: 1603 implied LWSP 1604 The grammar described by this specification is word-based. Except 1605 where noted otherwise, linear white space (LWSP) can be included 1606 between any two adjacent words (token or quoted-string), and 1607 between adjacent words and separators, without changing the 1608 interpretation of a field. At least one delimiter (LWSP and/or 1609 separators) MUST exist between any two tokens (for the definition 1610 of "token" below), since they would otherwise be interpreted as a 1611 single token. 1613 Implementations SHOULD NOT insert LWSP when generating challenges/ 1614 responses, but MUST accept them in any received data. 1615 7.2 Basic Rules 1617 The following rules are used throughout this specification to 1618 describe basic parsing constructs. The US-ASCII coded character set 1619 is defined by ANSI X3.4-1986 [USASCII]. Non-terminals not defined in 1620 this document can be found in [ABNF]. 1622 TEXTCHAR = 1624 All linear white space, including folding, has the same semantics as 1625 SP. A recipient MAY replace any linear white space with a single SP 1626 before interpreting the field value or forwarding the message 1627 downstream. 1629 LWSP = *(WSP / CRLF WSP) 1631 Many HTTP/1.1 header field values consist of words separated by LWSP 1632 or special characters. These special characters MUST be in a quoted 1633 string to be used within a parameter value. 1635 token = 1*TOKENCHAR 1636 BACKSLASH = %x5C 1637 ; character 1638 separators = "(" / ")" / "<" / ">" / "@" 1639 / "," / ";" / ":" / BACKSLASH / DQUOTE 1640 / "/" / "[" / "]" / "?" / "=" 1641 / "{" / "}" / SP / HTAB 1642 TOKENCHAR = 1644 A string of text is parsed as a single word if it is quoted using 1645 double-quote marks. 1647 quoted-string = DQUOTE qdstr-val DQUOTE 1648 qdstr-val = *( qdtext / quoted-pair ) 1649 qdtext = 1651 Note that LWSP is NOT implicit between the double-quote marks 1652 (DQUOTE) surrounding a qdstr-val and the qdstr-val; any LWSP will be 1653 considered part of the qdstr-val. This is also the case for 1654 quotation marks surrounding any other construct. 1656 The backslash character (BACKSLASH) MAY be used as a single-character 1657 quoting mechanism only within qdstr-val and comment constructs. 1659 quoted-pair = BACKSLASH CHAR 1661 The value of this construct is CHAR. Note that an effect of this rule 1662 is that backslash itself MUST be quoted. 1664 7.3 Collected grammar in ABNF 1666 <> 1669 ;;; 2.1.1 Step One 1671 digest-challenge = LWSP d-c-e *(LWSP "," LWSP [d-c-e]) LWSP 1672 d-c-e = realm / nonce / qop-options / stale 1673 / server-maxbuf / charset / prep-opts / algorithm 1674 / cipher-opts / auth-param 1676 realm = "realm" EQU realm-value 1677 realm-value = quoted-string 1678 nonce = "nonce" EQU nonce-value 1679 nonce-value = quoted-string 1680 ;; contains data described by "nonce-data" 1681 qop-options = "qop" EQU DQUOTE qop-list DQUOTE 1682 qop-list = LWSP qop-value *(LWSP "," LWSP [qop-value]) LWSP 1683 qop-value = "auth" / "auth-int" / "auth-conf" / 1684 qop-token 1685 ;; qop-token is reserved for identifying 1686 ;; future extensions to DIGEST-MD5 1687 qop-token = token 1688 stale = "stale" EQU "true" 1689 server-maxbuf = "maxbuf" EQU maxbuf-value 1690 maxbuf-value = 1*DIGIT 1691 charset = "charset" EQU "utf-8" 1692 prep-opts = "prep" EQU DQUOTE prep-mechs DQUOTE 1693 prep-mechs = LWSP prep-mech *(LWSP "," LWSP [prep-mech]) LWSP 1694 prep-mech = "rfc4013" 1695 algorithm = "algorithm" EQU "md5-sess" 1696 cipher-opts = "cipher" EQU DQUOTE cipher-list DQUOTE 1697 cipher-list = LWSP cipher-value 1698 *(LWSP "," LWSP [cipher-value]) LWSP 1699 cipher-value = "rc4-40" / "rc4" / "rc4-56" / 1700 "aes-ctr" / cipher-token 1701 ;; cipher-token is reserved for 1702 ;; new ciphersuites 1703 cipher-token = token 1704 auth-param = token EQU ( token / quoted-string ) 1705 nonce-data = new-nonce-data / obs-nonce-data 1706 new-nonce-data = "CB-" channel-type ":" channel-bindings 1707 ":" qop-list ":" cipher-list 1708 ":" nonce-octets 1710 obs-nonce-data = nonce-octets 1711 ;; nonce value as defined in RFC 2831. 1712 ;; SHOULD be accepted. MUST NOT be 1713 ;; generated. 1714 channel-type = "TLS" / channel-type-ext 1715 ;; Should be taken from 1716 ;; [CHANNEL-BINDINGS]. 1717 channel-type-ext = 1*(ALPHA / DIGIT) 1718 ;; for future channel bindings>> 1719 channel-bindings = 1*TEXTCHAR 1720 ;; channel binding data as defined by 1721 ;; the channel type 1723 nonce-octets = 1*TEXTCHAR 1725 ;;; 2.1.2 Step Two 1727 digest-response = LWSP d-r-e *(LWSP "," LWSP [d-r-e]) LWSP 1728 d-r-e = username / realm / nonce / cnonce 1729 / nonce-count / qop / digest-uri / response 1730 / response-v2 / client-maxbuf / charset 1731 / prep / cipher / authzid / auth-param 1733 username = "username" EQU username-value 1734 username-value = quoted-string 1735 cnonce = "cnonce" EQU cnonce-value 1736 cnonce-value = nonce-value 1737 nonce-count = "nc" EQU nc-value 1738 nc-value = 8LHEX 1739 client-maxbuf = "maxbuf" EQU maxbuf-value 1740 qop = "qop" EQU qop-value 1741 digest-uri = "digest-uri" EQU 1742 DQUOTE digest-uri-value DQUOTE 1743 digest-uri-value = serv-type "/" host [ "/" serv-name ] 1744 serv-type = 1*ALPHA 1745 serv-name = host 1746 prep = "prep" EQU prep-mech 1747 response = "response" EQU response-value 1748 response-v2 = "response-v2" EQU response-value 1749 response-value = 32LHEX 1750 LHEX = DIGIT / "a" / "b" / 1751 "c" / "d" / "e" / "f" 1752 cipher = "cipher" EQU cipher-value 1753 authzid = "authzid" EQU authzid-value 1754 authzid-value = quoted-string 1756 host = IP-literal / IPv4address / reg-name 1757 IP-literal = 1758 IPv4address = 1759 reg-name = 1761 ;;; 2.1.2.1 Response-value 1763 password = *OCTET 1765 ;;; 2.1.3 Step Three 1767 auth-info = LWSP a-i-e *(LWSP "," LWSP [a-i-e]) LWSP 1768 a-i-e = response-auth / response-v2-auth / auth-param 1770 response-auth = "rspauth" EQU response-value 1771 response-v2-auth = "rspauth-v2" EQU response-value 1773 ;;; 7.2 Basic rules 1775 TEXTCHAR = HTAB / %x20-7E / %x80-FF 1776 LWSP = *(WSP / CRLF WSP) 1778 token = 1*TOKENCHAR 1779 BACKSLASH = %x5C 1780 ; character 1781 separators = "(" / ")" / "<" / ">" / "@" 1782 / "," / ";" / ":" / BACKSLASH / DQUOTE 1783 / "/" / "[" / "]" / "?" / "=" 1784 / "{" / "}" / SP / HTAB 1785 TOKENCHAR = 1787 quoted-string = DQUOTE qdstr-val DQUOTE 1788 qdstr-val = *( qdtext / quoted-pair ) 1789 qdtext = HTAB / %x20-21 / %x23-5B / %x5D-7E / %x80-FF 1791 quoted-pair = BACKSLASH CHAR 1793 EQU = LWSP "=" LWSP 1795 ;;; The following non-terminals were imported from RFC 4234: 1796 ;;DIGIT, DQUOTE, ALPHA, OCTET, WSP, CRLF, HTAB, SP, CHAR and CTL 1798 8 Authors' Addresses 1800 Paul Leach 1801 Microsoft 1802 1 Microsoft Way 1803 Redmond, WA 98052, USA 1805 EMail: paulle@microsoft.com 1807 Chris Newman 1808 Sun Microsystems 1809 1050 Lakes Drive 1810 West Covina, CA 91790, USA 1812 EMail: Chris.Newman@Sun.COM 1814 Alexey Melnikov 1815 Isode Ltd. 1816 5 Castle Business Village, 1817 36 Station Road, 1818 Hampton, 1819 Middlesex, 1820 TW12 2BX, 1821 United Kingdom 1823 Email: Alexey.Melnikov@isode.com 1825 9 Acknowledgements 1827 The following people had substantial contributions to the development 1828 and/or refinement of this document: 1830 Lawrence Greenfield 1831 John Gardiner Myers 1832 Simon Josefsson 1833 RL Bob Morgan 1834 Jeff Hodges 1835 Claus Assmann 1836 Tony Hansen 1837 Ken Murchison 1838 Sam Hartman 1839 Kurt D. Zeilenga 1840 Hallvard B. Furuseth 1841 Abhijit Menon-Sen 1842 Nicolas Williams 1843 Jeffrey Hutzelman 1844 Tom Yu 1845 Dave Cridland 1846 Frank Ellermann 1848 as well as other members of the SASL mailing list. 1850 10 Full Copyright Statement 1852 Copyright (C) The IETF Trust (2007). 1854 This document is subject to the rights, licenses and restrictions 1855 contained in BCP 78, and except as set forth therein, the authors 1856 retain all their rights. 1858 This document and the information contained herein are provided on an 1859 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1860 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1861 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1862 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1863 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1864 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1866 Acknowledgement 1868 Funding for the RFC Editor function is currently provided by the 1869 Internet Society. 1871 11 Intellectual Property 1873 The IETF takes no position regarding the validity or scope of any 1874 Intellectual Property Rights or other rights that might be claimed to 1875 pertain to the implementation or use of the technology described in 1876 this document or the extent to which any license under such rights 1877 might or might not be available; nor does it represent that it has 1878 made any independent effort to identify any such rights. Information 1879 on the procedures with respect to rights in RFC documents can be 1880 found in BCP 78 and BCP 79. 1882 Copies of IPR disclosures made to the IETF Secretariat and any 1883 assurances of licenses to be made available, or the result of an 1884 attempt made to obtain a general license or permission for the use of 1885 such proprietary rights by implementers or users of this 1886 specification can be obtained from the IETF on-line IPR repository at 1887 http://www.ietf.org/ipr. 1889 The IETF invites any interested party to bring to its attention any 1890 copyrights, patents or patent applications, or other proprietary 1891 rights that may cover technology that may be required to implement 1892 this standard. Please address the information to the IETF at ietf- 1893 ipr@ietf.org. 1895 Appendix A: Changes from 2831 1897 1). Fixed various typos in formulas. 1899 2). Tighten ABNF. Fixed some bugs. 1901 3). Replace RFC 822 ABNF with [ABNF]. 1903 4). Clarified nc-value verification and which side is aborting 1904 exchange. 1906 5). Removed downconversion to ISO-8859-1. 1908 6). Clarified that unquoted version of the username, etc. used in A1 1909 calculation. 1911 7). Various cleanup to References section. Split all references into 1912 Normative and Informative. 1914 8). Added minimal and maximal limits on maxbuf. Clarified how to 1915 calculate "maximal sender size". 1917 9). Change ABNF for host to allow for IPv6 addresses. ABNF now 1918 references RFC 3986. 1920 10). Added man-in-the-middle considerations for ciphers. 1922 11). Clarified how sequence counters are updated. 1924 12). Addition warnings about preventing reply/redirection attacks. 1926 13). Specified that "charset" directive affects "realm" and doesn't 1927 affect "authzid". 1929 14). Removed text that described that "authzid" is in Unicode in 1930 Normalization Form KC, encoded as UTF-8. 1932 15). Clarified that rc4 state is not reset between two consecutive 1933 sent/received buffers of protected data. 1935 16). Allow for extensibility in step 3. Use "auth-info" as in RFC 1936 2617. 1938 17). Prohibit an empty authzid, as this caused interoperability 1939 problems. 1941 18). Clarified that 'qop="auth",qop="auth-int"' is the same as 1942 'qop="auth,auth-int"'. 1944 19). Clarified client behavior, if it recognizes no ciphers. 1946 20). Clarified that the server is not required to advertise all 1947 realms it supports. 1949 21). Clarified how UIs should present realms. 1951 22). Changed some informative text to normative MUST/SHOULDs. 1953 23). Changed nonce/cnonce to allow for channel bindings. 1955 24). Added new "prep" directive, that allows to specify preparation 1956 algorithms for username/password. Defined a single preparation 1957 mechanism - SASLPrep [SASLPrep]. 1958 Added another directive (response-v2) confirming that a user 1959 knows 1960 its password. A corresponding directive (rspauth-v2) was added 1961 for 1962 the server. 1964 25). Cleaned up Confidentiality protection section. 1966 26). Added AES cipher defined in "AES Ciphersuite for DIGEST-MD5 SASL 1967 mechanism" document (expired draft-ietf-sasl-digest-aes-00.txt). 1968 Use aes cipher in CTR mode ("aes-ctr"). 1970 27). Dropped DES as mandatory to implement cipher (aes-ctr is 1971 mandatory to 1972 implement). Removed "des" and "3des" ciphers because of known 1973 interoperability problems and vulnerability to CBC mode attack. 1975 And other minor text clarifications. 1977 Appendix B: Differences between HTTP Digest and DIGEST-MD5 1979 <> 1981 1) On reauthentication, DIGEST-MD5 requires that cnonce is to be the 1982 same, while HTTP Digest doesn't have this restriction 1984 2) Integrity and confidentiality security layers are very specific to 1985 SASL and DIGEST-MD5 1987 3) HTTP Digest doesn't support channel bindings 1989 4) HTTP Digest doesn't have the "charset" and the "prep" options 1990 5) DIGEST-MD5 doesn't use the following HTTP Digest options in 1991 "digest-challenge": "opaque" and "domain" 1993 6) DIGEST-MD5 doesn't use the following HTTP Digest options in 1994 "digest-response": "opaque" and "algorithm" 1996 7) DIGEST-MD5 doesn't use the following HTTP Digest options in "auth- 1997 info": "nextnonce", "qop", "cnonce" and "nonce-count" 1999 8) A second directive (response-v2) confirming that a user knows its 2000 password was added. A corresponding directive (rspauth-v2) was added 2001 for the server. 2003 Appendix C: Open Issues/ToDo List 2005 1). Normative vs. Informative references must be carefully rechecked. 2007 2). The charset directive is kind of optional, but in practice it is 2008 not. 2009 Should it just be made mandatory? 2011 3). Need to clarify behaviour when the prep directive is present, 2012 but the charset directive is not. 2014 4). Update example to match the updated draft, in particular need 2015 to add channel binding, qop & cipher lists into nonce/cnonce. 2016 Also need to use example.{com|net} in examples. 2018 5). Frank Ellermann asked if the procedure for unescaping is actually 2019 correct and consistent with HTTP Digest. 2020 He suggested that simple removal of surrounding quotes is what 2021 people actually implement. Need to perform some interop testing. 2023 6). Need to clarify backward compatibility with RFC 2831 in several 2024 places.