idnits 2.17.1 draft-leach-digest-sasl-00.txt: -(725): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(726): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 3 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 7) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 340 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2195], [RFC2222], [Digest]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 21, 1998) is 9348 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) == Missing Reference: 'RFC 2222' is mentioned on line 46, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Looks like a reference, but probably isn't: '10' on line 558 -- Looks like a reference, but probably isn't: '9' on line 559 -- Looks like a reference, but probably isn't: '8' on line 631 == Missing Reference: 'ISO 8859' is mentioned on line 900, but not defined == Unused Reference: 'ISO-8859' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC 2047' is defined on line 755, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Digest' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Digest Authentication as a SASL Mechanism September 1998 4 Network Working Group Paul J. Leach, Microsoft 5 INTERNET-DRAFT Chris Newman, Innosoft 6 draft-leach-digest-sasl-00.txt 7 Category: Standards Track 8 Expires March 21, 1999 September 21, 1998 10 Using Digest Authentication as a SASL Mechanism 12 Preliminary Draft 14 Author's draft: 7 16 STATUS OF THIS MEMO 18 THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT. IT DOES NOT REPRESENT 19 THE CONSENSUS OF ANY WORKING GROUP. 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, and 23 its working groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress". 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Distribution of this document is unlimited. Please send comments to the 38 authors or the SASL mailing list, ietf-sasl@imc.org. 40 Copyright Notice: Copyright (C) The Internet Society (1998). All Rights 41 Reserved. See section 8 for the full copyright notice. 43 ABSTRACT 45 This specification defines how HTTP Digest Authentication [Digest] can 46 be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL 47 profile. It is intended both as an improvement over CRAM-MD5 [RFC2195] 48 and as a convenient way to support a single authentication mechanism for 49 web, mail, LDAP, and other protocols. 51 Digest Authentication as a SASL Mechanism September 1998 53 Table of Contents 55 1 INTRODUCTION........................................................3 57 1.1 CONVENTIONS AND NOTATION.........................................3 59 1.2 REQUIREMENTS.....................................................4 61 2 AUTHENTICATION......................................................4 63 2.1 INITIAL AUTHENTICATION...........................................4 65 2.2 SUBSEQUENT AUTHENTICATION.......................................10 67 2.2.1 Step one.....................................................10 69 2.2.2 Step Two.....................................................10 71 2.3 INTEGRITY PROTECTION............................................10 73 3 SECURITY CONSIDERATIONS............................................11 75 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION...........11 77 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS...................11 79 3.3 REPLAY ATTACKS..................................................12 81 3.4 ONLINE DICTIONARY ATTACKS.......................................12 83 3.5 OFFLINE DICTIONARY ATTACKS......................................12 85 3.6 MAN IN THE MIDDLE...............................................12 87 3.7 CHOSEN PLAINTEXT ATTACKS........................................12 89 3.8 SPOOFING BY COUNTERFEIT SERVERS.................................13 91 3.9 STORING PASSWORDS...............................................13 93 3.10 SUMMARY........................................................13 95 4 EXAMPLE............................................................13 97 5 REFERENCES.........................................................14 99 6 AUTHORS' ADDRESSES.................................................15 100 Digest Authentication as a SASL Mechanism September 1998 102 7 ABNF...............................................................15 104 7.1 AUGMENTED BNF...................................................15 106 7.2 BASIC RULES.....................................................17 108 8 SAMPLE CODE........................................................18 110 9 FULL COPYRIGHT STATEMENT...........................................19 112 1 Introduction 114 This specification describes the use of HTTP Digest Access 115 Authentication as a SASL mechanism. The authentication type associated 116 with the Digest SASL mechanism is "DIGEST-MD5". 118 This specification is intended to be upward compatible with the "md5- 119 sess" algorithm of HTTP/1.1 Digest Access Authentication specified in 120 [Digest]. The only difference in the "md5-sess" algorithm is that some 121 directives not needed in a SASL mechanism have had their values 122 defaulted. 124 There are two new features for use as a SASL mechanism: integrity 125 protection and confidentiality protection on application protocol 126 messages after an authentication exchange. 128 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext 129 attacks, and permits the use of third party authentication servers, 130 mutual authentication, and optimized reauthentication if a client has 131 recently authenticated to a server. 133 1.1 Conventions and Notation 135 This specification uses the same ABNF notation and lexical conventions 136 as HTTP/1.1 specification; see appendix A. 138 Let { a, b, � } be the concatenation of the strings a, b, � 140 Let H(s) be the 16 octet MD5 hash of the string s. 142 Let KD(k, s) be the 16 octet MD5 hash of the concatenation of the string 143 k, ":" (a 1 character long string consisting of a colon), and the string 144 s. 146 Let HEX(n) be the representation of the 16 octet MD5 hash n as a string 147 of 32 hex digits (with alphabetic characters always in lower case), 148 since MD5 is case sensitive. 150 Digest Authentication as a SASL Mechanism September 1998 152 1.2 Requirements 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC 2119]. 158 An implementation is not compliant if it fails to satisfy one or more of 159 the MUST level requirements for the protocols it implements. An 160 implementation that satisfies all the MUST level and all the SHOULD 161 level requirements for its protocols is said to be "unconditionally 162 compliant"; one that satisfies all the MUST level requirements but not 163 all the SHOULD level requirements for its protocols is said to be 164 "conditionally compliant." 166 2 Authentication 168 The following sections describe how to use Digest as a SASL 169 authentication mechanism. 171 2.1 Initial Authentication 173 If the client has not recently authenticated to the server, then it must 174 perform "initial authentication", as defined in this section. If it has 175 recently authenticated, then a more efficient form is available, defined 176 in the next section. 178 2.1.1S tep One 180 The server starts by sending a challenge. The data encoded in the 181 challenge contains a string formatted according to the rules for a 182 "digest-challenge" defined as follows: 184 digest-challenge = 1#( realm | nonce | qop-options | stale | 185 maxbuf | charset | auth-param ) 187 realm = "realm" "=" <"> realm-value <"> 188 realm-value = 1*(qdtext | quoted-pair ) 189 nonce = "nonce" "=" <"> nonce-value <"> 190 nonce-value = 1*(qdtext | quoted-pair ) 191 qop-options = "qop" "=" <"> qop-list <"> 192 qop-list = 1#qop-value 193 qop-value = "auth" | "auth-int" | "auth-conf" | 194 token 195 stale = "stale" "=" "true" 196 maxbuf = "maxbuf" "=" maxbuf-value 197 maxbuf-value = 1*DIGIT 198 charset = "charset" "=" "utf-8" 199 algorithm = "algorithm" "=" "md5-sess" 200 auth-param = token "=" ( token | quoted-string ) 202 The meanings of the values of the directives used above are as follows: 204 Digest Authentication as a SASL Mechanism September 1998 206 realm 207 A string to be displayed to users so they know which username and 208 password to use. This string should contain at least the name of the 209 host performing the authentication and might additionally indicate 210 the collection of users who might have access. An example might be 211 "registered_users@gotham.news.com". This directive is optional; if 212 not present, it defaults to the realm used by the user to login to 213 the client system. Multiple realm directives are allowed. 215 nonce 216 A server-specified data string which should be different each time a 217 digest-challenge is sent. It is recommended that this string be 218 base64 or hexadecimal data. Note that since the string is passed as a 219 quoted string, the double-quote character is not allowed. The 220 contents of the nonce are implementation dependent. The quality of 221 the implementation depends on a good choice. The nonce is opaque to 222 the client. This directive is required and may appear exactly once; 223 if not present, or if multiple instances are present, the client 224 should abort the authentication exchange. 226 qop-options 227 A quoted string of one or more tokens indicating the "quality of 228 protection" values supported by the server. The value "auth" 229 indicates authentication; the value "auth-int" indicates 230 authentication with integrity protection; the value "auth-conf" is 231 reserved to indicate authentication with integrity protection and 232 encryption. The client MUST ignore unrecognized options; if the 233 client recognizes no option, it should abort the authentication 234 exchange. 236 stale 237 The "stale" directive is not used in initial authentication. See the 238 next section for its use in subsequent authentications. 240 maxbuf 241 A number indicating the size of the largest buffer the server is able 242 to receive when using "auth-int". If this directive is missing, the 243 default value is 65536. This directive may appear at most once; if 244 multiple instances are present, the client should abort the 245 authentication exchange. 247 charset 248 This directive, if present, specifies that the server supports UTF-8 249 encoding for the username and password. If not present, the username 250 and password must be encoded in ISO 8859-1 (of which US-ASCII is a 251 subset). The directive is needed for backwards compatibility with 252 HTTP Digest, which only supports ISO 8859-1. 254 algorithm 255 This directive is required for backwards compatibility with HTTP 256 Digest., which supports other algorithms. 258 Digest Authentication as a SASL Mechanism September 1998 260 auth-param 261 This directive allows for future extensions. The client MUST ignore 262 any unrecognized directive. 264 For use as a SASL mechanism, note that the following changes are made to 265 "digest-challenge" from HTTP: the following Digest options (called 266 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, 267 and MUST be ignored if received): 269 opaque 270 domain 272 2.1.2 Step Two 274 The client makes note of the "digest-challenge" and then responds with a 275 string formatted and computed according to the rules for a "digest- 276 response" defined as follows: 278 digest-response = 1#( username | realm | nonce | cnonce | 279 nonce-count | qop | digest-uri | response | 280 maxbuf | charset | auth-param ) 282 username = "username" "=" <"> username-value <"> 283 username-value = 1*(qdtext | quoted-pair ) 284 cnonce = "cnonce" "=" <"> cnonce-value <"> 285 cnonce-value = 1*(qdtext | quoted-pair ) 286 nonce-count = "nc" "=" nc-value 287 nc-value = 8LHEX 288 qop = "qop" "=" qop-value 289 digest-uri = "digest-uri" "=" digest-uri-value 290 digest-uri-value = serv-type "/" host [ "/" serv-name ] 291 serv-type = 1*ALPHA 292 host = 1*( ALPHA | DIGIT | "-" | "." ) 293 service = host 294 response = "response" "=" <"> response-value <"> 295 response-value = 32LHEX 296 LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 297 "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" 299 username 300 The user's name in the specified realm, encoded as UTF-8. This 301 directive is required; if not present, authentication fails. 303 realm 304 The realm containing the user's account. It MUST be one of the realms 305 from the "digest-challenge". This directive is required; if not 306 present, or not one of the ones in the "digest-challenge", 307 authentication fails.. 309 nonce 310 A server-specified data string which should be different each time a 311 digest-challenge is sent. It is recommended that this string be 312 Digest Authentication as a SASL Mechanism September 1998 314 base64 or hexadecimal data. The contents of the nonce are 315 implementation dependent. The quality of the implementation depends 316 on a good choice. The nonce is opaque to the client. This directive 317 is required and may appear exactly once; if not present, or if 318 multiple instances are present, the client should abort the 319 authentication exchange. 321 cnonce 322 The cnonce-value is an opaque quoted string value provided by the 323 client and used by both client and server to avoid chosen plaintext 324 attacks, and to provide mutual authentication. This directive is 325 required; if not present, authentication fails. 327 nonce-count 328 The nc-value is the hexadecimal count of the number of requests 329 (including the current request) that the client has sent with the 330 nonce value in this request. For example, in the first request sent 331 in response to a given nonce value, the client sends "nc=00000001". 332 The purpose of this directive is to allow the server to detect 333 request replays by maintaining its own copy of this count - if the 334 same nc-value is seen twice, then the request is a replay. See the 335 description below of the construction of the response value. 337 qop 338 Indicates what "quality of protection" the client accepted. If 339 present, its value MUST be one of the alternatives the server 340 indicated it supports in digest-challenge. If not present, it 341 defaults to "auth". These values affect the computation of the 342 response. Note that this is a single token, not a quoted list of 343 alternatives. 345 serv-type 346 Indicates the type of service, such as "www" for web service, "ftp" 347 for FTP service, "SMTP" for mail delivery service, etc.. 349 host 350 Indicates the host name for the service requested. 352 serv-name 353 Indicates the name of the service if it is replicated. For example, 354 the incoming mail service for "xyz.com" may be replicated through the 355 use of MX records stored in the DNS, one of which points at an SMTP 356 server called "mail3.xyz.com"; it's "serv-name" would be "xyz.com", 357 it's "host" would be "mail3.xyz.com". 359 digest-uri 360 Indicates the principal name of the service with which the client 361 wishes to connect, formed from the serv-type, host, and serv-name. 362 For example, the FTP service on "ftp.xyz.com" would have a "digest- 363 uri" value of "ftp/ftp.xyz.com"; the SMTP server from the example 364 above would have a "digest-uri" value of "smtp/mail3.xyz.com/xyz.com" 365 Digest Authentication as a SASL Mechanism September 1998 367 response 368 A string of 32 hex digits computed as defined below, which proves 369 that the user knows a password. This directive is required; if not 370 present, authentication fails. 372 maxbuf 373 A number indicating the size of the largest buffer the client is able 374 to receive. If this directive is missing, the default value is 65536. 375 This directive may appear at most once; if multiple instances are 376 present, the server should abort the authentication exchange. 378 charset 379 This directive, if present, specifies that the client has used UTF-8 380 encoding for the username and password. If not present, the username 381 and password must be encoded in ISO 8859-1 (of which US-ASCII is a 382 subset). The client should send this directive only if the server has 383 indicated it supports UTF-8. The directive is needed for backwards 384 compatibility with HTTP Digest, which only supports ISO 8859-1. 386 LHEX 387 32 hex digits, where the alphabetic characters MUST be lower case, 388 because MD5 is not case insensitive. 390 2.1.2.1 Response-value 392 The definition of "response-value" above indicates the encoding for its 393 value -- 32 lower case hex characters. The following definitions show 394 how the value is computed. 396 response-value = 397 HEX( KD ( HEX(H(A1)), 398 { nonce-value, ":" nc-value, ":", 399 cnonce-value, ":", qop-value, ":", HEX(H(A2)) 400 })) 402 A1 is 404 A1 = { 405 H( { username-value, ":", realm-value, ":", passwd } ), 406 ":", nonce-value, ":", cnonce-value } 408 where 410 passwd = *OCTET 412 The "username-value", "realm-value" and "passwd" are encoded according 413 to the value of the "charset" directive. If "charset=UTF-8" is present, 414 and all the characters of either "username-value" or "passwd" are in the 415 ISO 8859-1 character set, then it must be converted to ISO 8859-1 before 416 being hashed. A sample implementation of this conversion is in section 417 8. 419 Digest Authentication as a SASL Mechanism September 1998 421 If the "qop" directive's value is "auth", then A2 is: 423 A2 = { "AUTHENTICATE:", digest-uri-value } 425 If the "qop" value is "auth-int" then A2 is: 427 A2 = { "AUTHENTICATE:", digest-uri-value, 428 ":00000000000000000000000000000000" } 430 i.e., a string of two colons followed by 32 zeros. 432 These apparently strange values of A2 are for compatibility with HTTP; 433 they were arrived at by setting "Method" to "AUTHENTICATE" and the hash 434 of the entity body to zero in the HTTP digest calculation of A2. 436 Also, in the HTTP usage of Digest, several directives in the "digest- 437 challenge" sent by the server have to be returned by the client in the 438 "digest-response". These are: 440 opaque 441 algorithm 443 These directives are not needed when Digest is used as a SASL mechanism 444 (i.e., MUST NOT be sent, and MUST be ignored if received). 446 2.1.3 Step Three 448 The server receives and validates the "digest-response". The server 449 checks that the nonce-count is 1 (one). If it supports subsequent 450 authentication, it saves the value of the nonce and the nonce-count. It 451 sends a message formatted as follows: 453 response-auth = "rspauth" "=" response-value 455 where response-value is calculated as above, using the values sent in 456 step three, except that if qop is "auth", then A2 is 458 A2 = { ":", digest-uri-value } 460 And if qop is "auth-int" then A2 is 462 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" 463 } 465 Compared to its use in HTTP, the following Digest directives in the 466 "digest-response" are unused: 468 Digest Authentication as a SASL Mechanism September 1998 470 nextnonce 471 qop 472 cnonce 473 nonce-count 475 2.2 Subsequent Authentication 477 If the client has previously authenticated to the server, and remembers 478 the values of username, realm, nonce, nonce-count, cnonce, and qop that 479 it used in that authentication, and the SASL profile for a protocol 480 permits an initial client response, then it MAY perform "subsequent 481 authentication", as defined in this section. 483 2.2.1 Step one 485 The client uses the values from the previous authentication and sends an 486 initial response with a string formatted and computed according to the 487 rules for a "digest-response", as defined above, but with a nonce-count 488 one greater than used in the last "digest-response". 490 2.2.2 Step Two 492 The server receives and validates the "digest-response". In addition, 493 if it has saved the nonce and nonce-count from a previous 494 authentication, the server checks that the nonce-count is one greater 495 than that used in the previous authentication using that nonce, and 496 saves the new value of nonce-count. 498 If the response is invalid, then the server sends a "digest-challenge", 499 and authentication proceeds as in initial authentication (and should be 500 configurable to log an authentication failure in some sort of security 501 audit log, since the failure may be a symptom of an attack). 503 If the response is valid, the server MAY choose to deem that 504 authentication has succeeded. However, if it has been too long since the 505 previous authentication, or for any other reason, the server MAY send a 506 new "digest-challenge" with a new value for nonce. The challenge MAY 507 contain a "stale" directive with value "true", which says that the 508 client may respond to the challenge using the password it used in the 509 previous response; otherwise, the client must solicit a new password 510 from the user. Except for the handling of "stale", after sending the 511 "digest-challenge" authentication proceeds as in the case of initial 512 authentication. 514 2.3 Integrity Protection 516 If the server offered "qop=auth-int" and the client responded "qop=auth- 517 int", then subsequent messages between the client and the server MUST be 518 integrity protected. Using as a base session key the value of H(A1) as 519 defined above the client and server calculate a pair of message 520 integrity keys as follows. 522 The key for integrity protecting messages from client to server is: 524 Digest Authentication as a SASL Mechanism September 1998 526 Kic = MD5(H(A1), 527 "Digest session key to client-to-server signing key magic 528 constant") 530 The key for integrity protecting messages from client to server is: 532 Kis = MD5(H(A1), 533 "Digest session key to server-to-client signing key magic 534 constant") 536 where MD5 is as specified in [RFC 1321]. If message integrity is 537 negotiated, a MAC for each message is appended to the message. The MAC 538 is 16 bytes: a 4-byte version number with value 1, the first 8 bytes of 539 the HMAC-MD5 [RFC 2104] of the message and the sequence number. 541 MAC(Ki, SeqNum, msg) = (0x00000001, HMAC(Ki, (SeqNum, msg))[0..7], 542 SeqNum) 544 where Ki is Kic for messages sent by the client and Kis for those sent 545 by the server. The sequence number is initialized to zero, and 546 incremented by one for each message sent. 548 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the 549 received value; the message is discarded if they differ. 551 3 Security Considerations 553 3.1 Authentication of Clients using Digest Authentication 555 Digest Authentication does not provide a strong authentication 556 mechanism, when compared to public key based mechanisms, for example. 557 However, since it prevents chosen plaintext attacks, it is stronger than 558 (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and 559 IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and 560 even more dangerous use of plaintext passwords; however, since it is 561 still a password based mechanism it avoids some of the potential 562 deployabilty issues with public-key, OTP or similar mechanisms. 564 Digest Authentication offers no confidentiality protection beyond 565 protecting the actual password. All of the rest of the challenge 566 and response are available to an eavesdropper, including the 567 user's name and authentication realm. 569 3.2 Comparison of Digest with Plaintext Passwords 571 The greatest threat to the type of transactions for which these 572 protocols are used is network snooping. This kind of transaction 573 might involve, for example, online access to a mail service whose 574 use is restricted to paying subscribers. With plaintext password 575 authentication an eavesdropper can obtain the password of the 576 user. This not only permits him to access anything in the 577 database, but, often worse, will permit access to anything else 578 the user protects with the same password. 580 Digest Authentication as a SASL Mechanism September 1998 582 3.3 Replay Attacks 584 Replay attacks are defeated if the client or the server chooses a 585 fresh nonce for each authentication as this specification 586 requires. 588 3.4 Online dictionary attacks 590 If the attacker can eavesdrop, then it can test any overheard 591 nonce/response pairs against a (potentially very large) list of common 592 words. Such a list is usually much smaller than the total number of 593 possible passwords. The cost of computing the response for each password 594 on the list is paid once for each challenge. 596 The server can mitigate this attack by not allowing users to select 597 passwords that are in a dictionary. 599 3.5 Offline dictionary attacks 601 If the attacker can choose the challenge, then it can precompute the 602 possible responses to that challenge for a list of common words. Such a 603 list is usually much smaller than the total number of possible 604 passwords. The cost of computing the response for each password on the 605 list is paid just once. 607 Offline dictionary attacks are defeated if the client chooses a fresh 608 nonce for each authentication, as this specification requires. 610 3.6 Man in the Middle 612 Digest authentication is vulnerable to "man in the middle" (MITM) 613 attacks. Clearly, a MITM would present all the problems of 614 eavesdropping. But it also offers some additional opportunities to the 615 attacker. 617 A possible man-in-the-middle attack would be to substitute a weaker qop 618 scheme for the ones sent by the server. If the algorithm is "md5-sess", 619 the server will not be able to detect this attack. For this reason, the 620 client should always use the strongest scheme that it understands from 621 the choices offered, and should never choose a scheme that does not meet 622 its minimum requirements. If the algorithm is "md5-neg", then the entire 623 challenge/response exchange is protected, and the server will detect 624 that the challenge was modified. 626 3.7 Chosen plaintext attacks 628 A chosen plaintext attack is where a MITM or a malicious server can 629 arbitrarily choose the challenge that the client will use to compute the 630 response. The ability to choose the challenge is known to make 631 cryptanalysis much easier [8]. 633 However, Digest does not permit the attack to choose the challenge as 634 long as the client chooses a fresh nonce for each authentication, as 635 this specification requires. 637 Digest Authentication as a SASL Mechanism September 1998 639 3.8 Spoofing by Counterfeit Servers 641 If a user can be led to believe that she is connecting to a host 642 containing information protected by a password she knows, when in fact 643 she is connecting to a hostile server, then the hostile server can 644 obtain challenge/response pairs where it was able to partly choose the 645 challenge. There is no known was that this can be exploited. 647 3.9 Storing passwords 649 Digest authentication requires that the authenticating agent (usually 650 the server) store some data derived from the user's name and password in 651 a "password file" associated with a given realm. Normally this might 652 contain pairs consisting of username and H(A1), where H(A1) is the 653 digested value of the username, realm, and password as described above. 655 The security implications of this are that if this password file is 656 compromised, then an attacker gains immediate access to documents on the 657 server using this realm. Unlike, say a standard UNIX password file, this 658 information need not be decrypted in order to access documents in the 659 server realm associated with this file. On the other hand, decryption, 660 or more likely a brute force attack, would be necessary to obtain the 661 user's password. This is the reason that the realm is part of the 662 digested data stored in the password file. It means that if one Digest 663 authentication password file is compromised, it does not automatically 664 compromise others with the same username and password (though it does 665 expose them to brute force attack). 667 There are two important security consequences of this. First the 668 password file must be protected as if it contained plaintext passwords, 669 because for the purpose of accessing documents in its realm, it 670 effectively does. 672 A second consequence of this is that the realm string should be unique 673 among all realms that any single user is likely to use. In particular a 674 realm string should include the name of the host doing the 675 authentication. 677 3.10 Summary 679 By modern cryptographic standards Digest Authentication is weak, 680 compared to (say) public key based mechanisms. But for a large range of 681 purposes it is valuable as a replacement for plaintext passwords. Its 682 strength may vary depending on the implementation. 684 4 Example 686 This example shows the use of the Digest SASL mechanism with the IMAP4 687 AUTHENTICATE command [RFC 2060]. The base64 encoding of the challenges 688 and responses is part of the IMAP4 AUTHENTICATE command, not part of the 689 Digest specification itself. (Note: linebreaks added for editorial 690 clarity are not part of the mechanism): 692 Digest Authentication as a SASL Mechanism September 1998 694 * OK elwood.innosoft.com IMAP4 Server PMDF5.3-1 at Mon, 28 Sep 1998 695 09:16:30 -0700 (PDT) 696 c CAPABILITY 697 * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE STARTTLS AUTH=CRAM-MD5 698 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN 699 c OK CAPABILITY completed 700 a AUTHENTICATE DIGEST-MD5 701 + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJENlBpNXVvT2xp 702 RzI4WFZidVRYQ0l3Iixxb3A9ImF1dGgi 703 dXNlcm5hbWU9ImNocmlzIixyZWFsbT0iZWx3b29kLmlubm9zb2Z0LmNvbSIsbm 704 9uY2U9IkQ2UGk1dW9PbGlHMjhYVmJ1VFhDSXciLG5jPTAwMDAwMDAxLGNub25j 705 ZT0iZS9nWG5wRW94ODNzVzNERXU3b1FoZyIscmVzcG9uc2U9IjRmNjA2NTBhYW 706 FmNDQxNzkyOWViNjg3Zjc2NmNlOTMyIixxb3A9ImF1dGgi 707 a OK AUTHENTICATE completed 708 --- 710 Decoding the base64, gets: 712 realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw",qop="auth 713 " 715 and 717 username="chris",realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVb 718 uTXCIw", 719 nc=00000001,cnonce="e/gXnpEox83sW3DEu7oQhg", 720 response="4f60650aaaf4417929eb687f766ce932",qop="auth" 722 The password was "secret". 724 The server uses the values of all the directives, plus knowledge of the 725 users password (or the hash of the user�s name, server�s realm and the 726 user�s password) to verify the computations above. If they check, then 727 the user has authenticated. 729 5 References 731 [Digest] Franks, J., et. al., "HTTP Authentication: Basic and Digest 732 Access Authentication", , Work in 733 Progress of the HTTP Working Group, August, 1998 735 [ISO-8859] ISO-8859. International Standard -- Information Processing -- 736 8-bit Single-Byte Coded Graphic Character Sets -- 737 Part 1: Latin alphabet No. 1, ISO-8859-1:1987. 738 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. 739 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. 740 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. 741 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. 742 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. 743 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. 744 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. 745 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. 747 Digest Authentication as a SASL Mechanism September 1998 749 [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet Text 750 Messages," STD 11, RFC 822, UDEL, August 1982. 752 [RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 753 April 1992 755 [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 756 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 757 University of Tennessee, November 1996. 759 [RFC 2060] Crispin, "Internet Message Access Protocol - Version 4rev1", 760 RFC 2060, University of Washington, December 1996. 762 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 763 for Message Authentication", RFC 2104, 02/05/1997 765 [RFC2195] Klensin, J., et. al., "IMAP/POP AUTHorize Extension for Simple 766 Challenge/Response", RFC 2195, September, 1997. 768 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels," RFC 2119, Harvard University, March 1997. 771 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code 772 for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. 774 6 Authors' Addresses 776 Paul Leach 777 Microsoft 778 1 Microsoft Way 779 Redmond, WA 98052 780 paulle@microsoft.com 782 Chris Newman 783 Innosoft International, Inc. 784 1050 Lakes Drive 785 West Covina, CA 91790 USA 786 chris.newman@innosoft.com 788 7 ABNF 790 7.1 Augmented BNF 792 All of the mechanisms specified in this document are described in both 793 prose and an augmented Backus-Naur Form (BNF) similar to that used by 794 RFC 822 [RFC 822]. Implementors will need to be familiar with the 795 notation in order to understand this specification. The augmented BNF 796 includes the following constructs: 798 Digest Authentication as a SASL Mechanism September 1998 800 name = definition 801 The name of a rule is simply the name itself (without any enclosing 802 "<" and ">") and is separated from its definition by the equal "=" 803 character. White space is only significant in that indentation of 804 continuation lines is used to indicate a rule definition that spans 805 more than one line. Certain basic rules are in uppercase, such as SP, 806 LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within 807 definitions whenever their presence will facilitate discerning the 808 use of rule names. 810 "literal" 811 Quotation marks surround literal text. Unless stated otherwise, the 812 text is case-insensitive. 814 rule1 | rule2 815 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" 816 will accept yes or no. 818 (rule1 rule2) 819 Elements enclosed in parentheses are treated as a single element. 820 Thus, "(elem (foo | bar) elem)" allows the token sequences 821 "elem foo elem" and "elem bar elem". 823 *rule 824 The character "*" preceding an element indicates repetition. The full 825 form is "*element" indicating at least and at most 826 occurrences of element. Default values are 0 and infinity so that 827 "*(element)" allows any number, including zero; "1*element" requires 828 at least one; and "1*2element" allows one or two. 830 [rule] 831 Square brackets enclose optional elements; "[foo bar]" is equivalent 832 to "*1(foo bar)". 834 N rule 835 Specific repetition: "(element)" is equivalent to 836 "*(element)"; that is, exactly occurrences of (element). 837 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 838 alphabetic characters. 840 #rule 841 A construct "#" is defined, similar to "*", for defining lists of 842 elements. The full form is "#element" indicating at least 843 and at most elements, each separated by one or more commas (",") 844 and OPTIONAL linear white space (LWS). This makes the usual form of 845 lists very easy; a rule such as 846 ( *LWS element *( *LWS "," *LWS element )) 847 can be shown as 848 1#element 849 Wherever this construct is used, null elements are allowed, but do 850 not contribute to the count of elements present. That is, "(element), 851 , (element) " is permitted, but counts as only two elements. 853 Digest Authentication as a SASL Mechanism September 1998 855 Therefore, where at least one element is required, at least one non- 856 null element MUST be present. Default values are 0 and infinity so 857 that "#element" allows any number, including zero; "1#element" 858 requires at least one; and "1#2element" allows one or two. 860 ; comment 861 A semi-colon, set off some distance to the right of rule text, starts 862 a comment that continues to the end of line. This is a simple way of 863 including useful notes in parallel with the specifications. 865 implied *LWS 866 Except where noted otherwise, linear white space ("LWS") can be 867 included between any adjacent "token", "quoted-string", or 868 "separators" constructs, as these are defined in the basic rules 869 below; such LWS is ignored. 871 7.2 Basic Rules 873 The following rules are used throughout this specification to describe 874 basic parsing constructs. The US-ASCII coded character set is defined by 875 ANSI X3.4-1986 [USASCII]. 877 OCTET = 878 CHAR = 879 UPALPHA = 880 LOALPHA = 881 ALPHA = UPALPHA | LOALPHA 882 DIGIT = 883 CTL = 885 CR = 886 LF = 887 SP = 888 HT = 889 <"> = 891 All linear white space, including folding, has the same semantics as SP. 892 A recipient MAY replace any linear white space with a single SP before 893 interpreting the field value or forwarding the message downstream. 895 LWS = [CRLF] 1*( SP | HT ) 897 The TEXT rule is only used for descriptive field contents and values 898 that are not intended to be interpreted by the message parser. Words of 899 *TEXT MAY contain characters from character sets other than ISO-8859-1 900 [ISO 8859] only when encoded according to the rules of RFC 2047 [RFC 901 2047]. 903 TEXT = 905 Digest Authentication as a SASL Mechanism September 1998 907 A CRLF is allowed in the definition of TEXT only as part of a header 908 field continuation. It is expected that the folding LWS will be replaced 909 with a single SP before interpretation of the TEXT value. 911 Hexadecimal numeric characters are used in several protocol elements. 913 HEX = "A" | "B" | "C" | "D" | "E" | "F" 914 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 916 Many HTTP/1.1 header field values consist of words separated by LWS or 917 special characters. These special characters MUST be in a quoted string 918 to be used within a parameter value. 920 token = 1* 921 separators = "(" | ")" | "<" | ">" | "@" 922 | "," | ";" | ":" | "\" | <"> 923 | "/" | "[" | "]" | "?" | "=" 924 | "{" | "}" | SP | HT 926 A string of text is parsed as a single word if it is quoted using 927 double-quote marks. 929 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) 930 qdtext = > 932 The backslash character ("\") MAY be used as a single-character quoting 933 mechanism only within quoted-string and comment constructs. 935 quoted-pair = "\" CHAR 937 8 Sample Code 939 The sample implementation in [Digest] also applies to DIGEST-MD5. 941 The following code implements the conversion from UTF-8 to 8859-1 if 942 necessary. 944 Digest Authentication as a SASL Mechanism September 1998 946 /* if the string is entirely in the 8859-1 subset of UTF-8, then 947 translate 948 * to 8859-1 prior to MD5 949 */ 950 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, int 951 len) 952 { 953 const unsigned char *scan, *end; 954 unsigned char cbuf; 956 end = base + len; 957 for (scan = base; scan < end; ++scan) { 958 if (*scan > 0xC3) break; /* abort if outside 8859-1 */ 959 if (*scan >= 0xC0 && *scan <= 0xC3) { 960 if (++scan == end || *scan < 0x80 || *scan > 0xBF) 961 break; 962 } 963 } 964 /* if we found a character outside 8859-1, don't alter string 965 */ 966 if (scan < end) { 967 MD5Update(ctx, base, len); 968 return; 969 } 971 /* convert to 8859-1 prior to applying hash 972 */ 973 do { 974 for (scan = base; scan < end && *scan < 0xC0; ++scan) 975 ; 976 if (scan != base) MD5Update(ctx, base, scan - base); 977 if (scan + 1 >= end) break; 978 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f); 979 MD5Update(ctx, &cbuf, 1); 980 base = scan + 2; 981 } while (base < end); 982 } 984 9 Full Copyright Statement 986 Copyright (C) The Internet Society (1998). All Rights Reserved. 988 This document and translations of it may be copied and furnished to 989 others, and derivative works that comment on or otherwise explain it or 990 assist in its implmentation may be prepared, copied, published and 991 distributed, in whole or in part, without restriction of any kind, 992 provided that the above copyright notice and this paragraph are included 993 on all such copies and derivative works. However, this document itself 994 may not be modified in any way, such as by removing the copyright notice 995 or references to the Internet Society or other Internet organizations, 996 except as needed for the purpose of developing Internet standards in 997 which case the procedures for copyrights defined in the Internet 998 Digest Authentication as a SASL Mechanism September 1998 1000 Standards process must be followed, or as required to translate it into 1001 languages other than English. 1003 The limited permissions granted above are perpetual and will not be 1004 revoked by the Internet Society or its successors or assigns. 1006 This document and the information contained herein is provided on an "AS 1007 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1008 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1009 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1010 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1011 FITNESS FOR A PARTICULAR PURPOSE.