idnits 2.17.1 draft-leach-digest-sasl-02.txt: -(836): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(837): 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 22 longer pages, the longest (page 10) being 69 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 390 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 == Line 631 has weird spacing: '...d, each messa...' -- 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 (February 26, 1999) is 9191 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 48, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Missing Reference: 'FIPS' is mentioned on line 279, but not defined -- Looks like a reference, but probably isn't: '10' on line 664 -- Looks like a reference, but probably isn't: '9' on line 665 -- Looks like a reference, but probably isn't: '8' on line 735 == Missing Reference: 'ISO 8859' is mentioned on line 1011, but not defined == Unused Reference: 'ISO-8859' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'RFC 2047' is defined on line 866, 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: 12 errors (**), 0 flaws (~~), 11 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-02.txt 7 Category: Standards Track 8 Expires August 26, 1999 February 26, 1999 10 Using Digest Authentication as a SASL Mechanism 12 Preliminary Draft 14 Author's draft: 12 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. 21 THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT. IT DOES NOT REPRESENT 22 THE CONSENSUS OF ANY WORKING GROUP. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other groups 26 may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Distribution of this document is unlimited. Please send comments to the 40 authors or the SASL mailing list, ietf-sasl@imc.org. 42 Copyright Notice: Copyright (C) The Internet Society (1998). All Rights 43 Reserved. See section 8 for the full copyright notice. 45 ABSTRACT 47 This specification defines how HTTP Digest Authentication [Digest] can 48 be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL 49 profile. It is intended both as an improvement over CRAM-MD5 [RFC2195] 50 and as a convenient way to support a single authentication mechanism for 51 web, mail, LDAP, and other protocols. 53 Digest Authentication as a SASL Mechanism September 1998 55 Table of Contents 57 1 INTRODUCTION........................................................2 59 1.1 CONVENTIONS AND NOTATION.........................................2 61 1.2 REQUIREMENTS.....................................................2 63 2 AUTHENTICATION......................................................3 65 2.1 INITIAL AUTHENTICATION...........................................3 67 2.1.1Step One......................................................3 69 2.1.2Step Two......................................................5 71 2.1.3Step Three....................................................9 73 2.2 SUBSEQUENT AUTHENTICATION........................................9 75 2.2.1Step one......................................................9 77 2.2.2Step Two......................................................9 79 2.3 INTEGRITY PROTECTION............................................10 81 3 SECURITY CONSIDERATIONS............................................12 83 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION...........12 85 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS...................12 87 3.3 REPLAY ATTACKS..................................................12 89 3.4 ONLINE DICTIONARY ATTACKS.......................................12 91 3.5 OFFLINE DICTIONARY ATTACKS......................................13 93 3.6 MAN IN THE MIDDLE...............................................13 95 3.7 CHOSEN PLAINTEXT ATTACKS........................................13 97 3.8 SPOOFING BY COUNTERFEIT SERVERS.................................13 99 3.9 STORING PASSWORDS...............................................13 101 3.10SUMMARY.........................................................14 103 4 EXAMPLE............................................................14 105 5 REFERENCES.........................................................15 107 6 AUTHORS' ADDRESSES.................................................16 108 Digest Authentication as a SASL Mechanism September 1998 110 7 ABNF...............................................................16 112 7.1 AUGMENTED BNF...................................................16 114 7.2 BASIC RULES.....................................................18 116 8 SAMPLE CODE........................................................19 118 9 FULL COPYRIGHT STATEMENT...........................................20 120 1 Introduction 122 This specification describes the use of HTTP Digest Access 123 Authentication as a SASL mechanism. The authentication type associated 124 with the Digest SASL mechanism is "DIGEST-MD5". 126 This specification is intended to be upward compatible with the "md5- 127 sess" algorithm of HTTP/1.1 Digest Access Authentication specified in 128 [Digest]. The only difference in the "md5-sess" algorithm is that some 129 directives not needed in a SASL mechanism have had their values 130 defaulted. 132 There is one new feature for use as a SASL mechanism: integrity 133 protection on application protocol messages after an authentication 134 exchange. 136 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext 137 attacks, and permits the use of third party authentication servers, 138 mutual authentication, and optimized reauthentication if a client has 139 recently authenticated to a server. 141 1.1 Conventions and Notation 143 This specification uses the same ABNF notation and lexical conventions 144 as HTTP/1.1 specification; see appendix A. 146 Let { a, b, ... } be the concatenation of the strings a, b, � 148 Let H(s) be the 16 octet MD5 hash of the string s. 150 Let KD(k, s) be the 16 octet MD5 hash of the concatenation of the string 151 k, ":" (a 1 character long string consisting of a colon), and the string 152 s. 154 Let HEX(n) be the representation of the 16 octet MD5 hash n as a string 155 of 32 hex digits (with alphabetic characters always in lower case), 156 since MD5 is case sensitive. 158 Digest Authentication as a SASL Mechanism September 1998 160 1.2 Requirements 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC 2119]. 166 An implementation is not compliant if it fails to satisfy one or more of 167 the MUST level requirements for the protocols it implements. An 168 implementation that satisfies all the MUST level and all the SHOULD 169 level requirements for its protocols is said to be "unconditionally 170 compliant"; one that satisfies all the MUST level requirements but not 171 all the SHOULD level requirements for its protocols is said to be 172 "conditionally compliant." 174 2 Authentication 176 The following sections describe how to use Digest as a SASL 177 authentication mechanism. 179 2.1 Initial Authentication 181 If the client has not recently authenticated to the server, then it must 182 perform "initial authentication", as defined in this section. If it has 183 recently authenticated, then a more efficient form is available, defined 184 in the next section. 186 2.1.1S tep One 188 The server starts by sending a challenge. The data encoded in the 189 challenge contains a string formatted according to the rules for a 190 "digest-challenge" defined as follows: 192 digest-challenge = 1#( realm | nonce | qop-options | stale | 193 maxbuf | charset | cipher-opts | auth- 194 param ) 196 realm = "realm" "=" <"> realm-value <"> 197 realm-value = qdstr-val 198 nonce = "nonce" "=" <"> nonce-value <"> 199 nonce-value = qdstr-val 200 qop-options = "qop" "=" <"> qop-list <"> 201 qop-list = 1#qop-value 202 qop-value = "auth" | "auth-int" | "auth-conf" | 203 token 204 stale = "stale" "=" "true" 205 maxbuf = "maxbuf" "=" maxbuf-value 206 maxbuf-value = 1*DIGIT 207 charset = "charset" "=" "utf-8" 208 algorithm = "algorithm" "=" "md5-sess" 209 cipher-opts = "cipher" "=" 1#cipher-value 210 cipher-value = "3des" | "des" | "rc4-40" | "rc4" | "rc4-56" | 211 token 212 Digest Authentication as a SASL Mechanism September 1998 214 auth-param = token "=" ( token | quoted-string ) 216 The meanings of the values of the directives used above are as follows: 218 realm 219 A string to be displayed to users so they know which username and 220 password to use. This string should contain at least the name of the 221 host performing the authentication and might additionally indicate 222 the collection of users who might have access. An example might be 223 "registered_users@gotham.news.com". This directive is optional; if 224 not present, it defaults to the realm used by the user to login to 225 the client system. Multiple realm directives are allowed. 227 nonce 228 A server-specified data string which MUST be different each time a 229 digest-challenge is sent as part of initial authentication. It is 230 recommended that this string be base64 or hexadecimal data. Note that 231 since the string is passed as a quoted string, the double-quote 232 character is not allowed. The contents of the nonce are 233 implementation dependent. The security of the implementation depends 234 on a good choice. It is RECOMMENDED that it contain at least 64 bits 235 of entropy. The nonce is opaque to the client. This directive is 236 required and may appear exactly once; if not present, or if multiple 237 instances are present, the client should abort the authentication 238 exchange. 240 qop-options 241 A quoted string of one or more tokens indicating the "quality of 242 protection" values supported by the server. The value "auth" 243 indicates authentication; the value "auth-int" indicates 244 authentication with integrity protection; the value "auth-conf" 245 indicates authentication with integrity protection and encryption. 246 The client MUST ignore unrecognized options; if the client recognizes 247 no option, it should abort the authentication exchange. 249 stale 250 The "stale" directive is not used in initial authentication. See the 251 next section for its use in subsequent authentications. 253 maxbuf 254 A number indicating the size of the largest buffer the server is able 255 to receive when using "auth-int" or "auth-conf". If this directive is 256 missing, the default value is 65536. This directive may appear at 257 most once; if multiple instances are present, the client should abort 258 the authentication exchange. 260 charset 261 This directive, if present, specifies that the server supports UTF-8 262 encoding for the username and password. If not present, the username 263 and password must be encoded in ISO 8859-1 (of which US-ASCII is a 264 subset). The directive is needed for backwards compatibility with 265 HTTP Digest, which only supports ISO 8859-1. 267 Digest Authentication as a SASL Mechanism September 1998 269 algorithm 270 This directive is required for backwards compatibility with HTTP 271 Digest., which supports other algorithms. 273 cipher-opts 274 A list of ciphers that the server supports. The "3des" and "des" 275 modes are mandatory-to-implement. This directive must be present 276 exactly once if "auth-conf" is offered. 278 des 279 the Data Encryption Standard (DES) cipher [FIPS] in cipher block 280 chaining (CBC) mode with a 56 bit key. 282 3des 283 the "triple DES" cipher in CBC mode with EDE with the same key for 284 each E stage (aka "two keys mode") for a total key length of 112 285 bits. 287 rc4, rc4-40, rc4-56 288 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively. 290 auth-param 291 This directive allows for future extensions. The client MUST ignore 292 any unrecognized directive. 294 For use as a SASL mechanism, note that the following changes are made to 295 "digest-challenge" from HTTP: the following Digest options (called 296 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, 297 and MUST be ignored if received): 299 opaque 300 domain 302 The size of a digest-challenge MUST be less than 2048 bytes. 304 2.1.2S tep Two 306 The client makes note of the "digest-challenge" and then responds with a 307 string formatted and computed according to the rules for a "digest- 308 response" defined as follows: 310 digest-response = 1#( username | realm | nonce | cnonce | 311 nonce-count | qop | digest-uri | response | 312 maxbuf | charset | cipher | auth-param ) 314 username = "username" "=" <"> username-value <"> 315 username-value = qdstr-val 316 cnonce = "cnonce" "=" <"> cnonce-value <"> 317 cnonce-value = qdstr-val 318 nonce-count = "nc" "=" nc-value 319 nc-value = 8LHEX 320 qop = "qop" "=" qop-value 321 Digest Authentication as a SASL Mechanism September 1998 323 digest-uri = "digest-uri" "=" digest-uri-value 324 digest-uri-value = serv-type "/" host [ "/" serv-name ] 325 serv-type = 1*ALPHA 326 host = 1*( ALPHA | DIGIT | "-" | "." ) 327 service = host 328 response = "response" "=" <"> response-value <"> 329 response-value = 32LHEX 330 LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 331 "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" 332 cipher = "cipher" "=" cipher-value 334 username 335 The user's name in the specified realm, encoded as UTF-8. This 336 directive is required; if not present, authentication fails. 338 realm 339 The realm containing the user's account. It MUST be one of the realms 340 from the "digest-challenge", if any were provided. This directive is 341 required unless the server did not provide any realms; otherwise, if 342 not present, or not one of the ones in the "digest-challenge", 343 authentication fails. 345 nonce 346 The server-specified data string received in the preceding digest- 347 challenge. 349 cnonce 350 A client-specified data string which MUST be different each time a 351 digest-response is sent as part of initial authentication. The 352 cnonce-value is an opaque quoted string value provided by the client 353 and used by both client and server to avoid chosen plaintext attacks, 354 and to provide mutual authentication. The security of the 355 implementation depends on a good choice. It is RECOMMENDED that it 356 contain at least 64 bits of entropy. This directive is required; if 357 not present, authentication fails. 359 nonce-count 360 The nc-value is the hexadecimal count of the number of requests 361 (including the current request) that the client has sent with the 362 nonce value in this request. For example, in the first request sent 363 in response to a given nonce value, the client sends "nc=00000001". 364 The purpose of this directive is to allow the server to detect 365 request replays by maintaining its own copy of this count - if the 366 same nc-value is seen twice, then the request is a replay. See the 367 description below of the construction of the response value. 369 qop 370 Indicates what "quality of protection" the client accepted. If 371 present, its value MUST be one of the alternatives the server 372 indicated it supports in digest-challenge. If not present, it 373 Digest Authentication as a SASL Mechanism September 1998 375 defaults to "auth". These values affect the computation of the 376 response. Note that this is a single token, not a quoted list of 377 alternatives. 379 serv-type 380 Indicates the type of service, such as "www" for web service, "ftp" 381 for FTP service, "SMTP" for mail delivery service, etc.. 383 host 384 Indicates the DNS host name for the service requested. 386 serv-name 387 Indicates the name of the service if it is replicated. If the 388 client's service-location process involves resolution using standard 389 (i.e., insecure) DNS lookup operations, and these operations involve 390 DNS records such as CNAME, SRV, or MX, which resolve one DNS name 391 into another, the initial name used by the client is the "serv-name", 392 and the final name is the "host" component. For example, the incoming 393 mail service for "example.com" may be replicated through the use of 394 MX records stored in the DNS, one of which points at an SMTP server 395 called "mail3.example.com"; it's "serv-name" would be "example.com", 396 it's "host" would be "mail3.example.com". 398 digest-uri 399 Indicates the principal name of the service with which the client 400 wishes to connect, formed from the serv-type, host, and serv-name. 401 For example, the FTP service on "ftp.xyz.com" would have a "digest- 402 uri" value of "ftp/ftp.xyz.com"; the SMTP server from the example 403 above would have a "digest-uri" value of "smtp/mail3.xyz.com/xyz.com" 405 response 406 A string of 32 hex digits computed as defined below, which proves 407 that the user knows a password. This directive is required; if not 408 present, authentication fails. 410 maxbuf 411 A number indicating the size of the largest buffer the client is able 412 to receive. If this directive is missing, the default value is 65536. 413 This directive may appear at most once; if multiple instances are 414 present, the server should abort the authentication exchange. 416 charset 417 This directive, if present, specifies that the client has used UTF-8 418 encoding for the username and password. If not present, the username 419 and password must be encoded in ISO 8859-1 (of which US-ASCII is a 420 subset). The client should send this directive only if the server has 421 indicated it supports UTF-8. The directive is needed for backwards 422 compatibility with HTTP Digest, which only supports ISO 8859-1. 424 LHEX 425 32 hex digits, where the alphabetic characters MUST be lower case, 426 because MD5 is not case insensitive. 428 Digest Authentication as a SASL Mechanism September 1998 430 cipher 431 The cipher chosen by the client. This directive MUST appear exactly 432 once if "auth-conf" is negotiated; if required and not present, 433 authentication fails. 435 The size of a digest-response MUST be less than 2048 bytes. 437 2.1.2.1 Response-value 439 The definition of "response-value" above indicates the encoding for its 440 value -- 32 lower case hex characters. The following definitions show 441 how the value is computed. 443 response-value = 444 HEX( KD ( HEX(H(A1)), 445 { nonce-value, ":" nc-value, ":", 446 cnonce-value, ":", qop-value, ":", HEX(H(A2)) 447 })) 449 A1 is 451 A1 = { H( { username-value, ":", realm-value, ":", passwd } ), 452 ":", nonce-value, ":", cnonce-value } 454 where 456 passwd = *OCTET 458 The "username-value", "realm-value" and "passwd" are encoded according 459 to the value of the "charset" directive. If "charset=UTF-8" is present, 460 and all the characters of either "username-value" or "passwd" are in the 461 ISO 8859-1 character set, then it must be converted to ISO 8859-1 before 462 being hashed. A sample implementation of this conversion is in section 463 8. 465 If the "qop" directive's value is "auth", then A2 is: 467 A2 = { "AUTHENTICATE:", digest-uri-value } 469 If the "qop" value is "auth-int" or "auth-conf" then A2 is: 471 A2 = { "AUTHENTICATE:", digest-uri-value, 472 ":00000000000000000000000000000000" } 474 Note that "AUTHENTICATE:" must be in upper case, and the second string 475 constant is a string with a colon followed by 32 zeros. 477 These apparently strange values of A2 are for compatibility with HTTP; 478 they were arrived at by setting "Method" to "AUTHENTICATE" and the hash 479 of the entity body to zero in the HTTP digest calculation of A2. 481 Digest Authentication as a SASL Mechanism September 1998 483 Also, in the HTTP usage of Digest, several directives in the "digest- 484 challenge" sent by the server have to be returned by the client in the 485 "digest-response". These are: 487 opaque 488 algorithm 490 These directives are not needed when Digest is used as a SASL mechanism 491 (i.e., MUST NOT be sent, and MUST be ignored if received). 493 2.1.3S tep Three 495 The server receives and validates the "digest-response". The server 496 checks that the nonce-count is "00000001". If it supports subsequent 497 authentication (see section 2.2), it saves the value of the nonce and 498 the nonce-count. It sends a message formatted as follows: 500 response-auth = "rspauth" "=" response-value 502 where response-value is calculated as above, using the values sent in 503 step two, except that if qop is "auth", then A2 is 505 A2 = { ":", digest-uri-value } 507 And if qop is "auth-int" or "auth-conf" then A2 is 509 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" 510 } 512 Compared to its use in HTTP, the following Digest directives in the 513 "digest-response" are unused: 515 nextnonce 516 qop 517 cnonce 518 nonce-count 520 2.2 Subsequent Authentication 522 If the client has previously authenticated to the server, and remembers 523 the values of username, realm, nonce, nonce-count, cnonce, and qop that 524 it used in that authentication, and the SASL profile for a protocol 525 permits an initial client response, then it MAY perform "subsequent 526 authentication", as defined in this section. 528 2.2.1 Step one 530 The client uses the values from the previous authentication and sends an 531 initial response with a string formatted and computed according to the 532 rules for a "digest-response", as defined above, but with a nonce-count 533 one greater than used in the last "digest-response". 535 Digest Authentication as a SASL Mechanism September 1998 537 2.2.2 Step Two 539 The server receives the "digest-response". If the server does not 540 support subsequent authentication, then it sends a "digest-challenge", 541 and authentication proceeds as in initial authentication. If the server 542 has no saved nonce and nonce-count from a previous authentication, then 543 it sends a "digest-challenge", and authentication proceeds as in initial 544 authentication. Otherwise, the server validates the "digest-response", 545 checks that the nonce-count is one greater than that used in the 546 previous authentication using that nonce, and saves the new value of 547 nonce-count. 549 If the response is invalid, then the server sends a "digest-challenge", 550 and authentication proceeds as in initial authentication (and should be 551 configurable to log an authentication failure in some sort of security 552 audit log, since the failure may be a symptom of an attack). The nonce- 553 count MUST NOT be incremented in this case: to do so would allow a 554 denial of service attack by sending an out-of-order nonce-count. 556 If the response is valid, the server MAY choose to deem that 557 authentication has succeeded. However, if it has been too long since the 558 previous authentication, or for any other reason, the server MAY send a 559 new "digest-challenge" with a new value for nonce. The challenge MAY 560 contain a "stale" directive with value "true", which says that the 561 client may respond to the challenge using the password it used in the 562 previous response; otherwise, the client must solicit a new password 563 from the user. Except for the handling of "stale", after sending the 564 "digest-challenge" authentication proceeds as in the case of initial 565 authentication. 567 2.3 Integrity Protection 569 If the server offered "qop=auth-int" and the client responded "qop=auth- 570 int", then subsequent messages, up to but not including the next 571 subsequent authentication, between the client and the server MUST be 572 integrity protected. Using as a base session key the value of H(A1) as 573 defined above the client and server calculate a pair of message 574 integrity keys as follows. 576 The key for integrity protecting messages from client to server is: 578 Kic = MD5(H(A1), 579 "Digest session key to client-to-server signing key magic 580 constant") 582 The key for integrity protecting messages from client to server is: 584 Kis = MD5(H(A1), 585 "Digest session key to server-to-client signing key magic 586 constant") 588 where MD5 is as specified in [RFC 1321]. If message integrity is 589 negotiated, a MAC for each message is appended to the message. The MAC 590 Digest Authentication as a SASL Mechanism September 1998 592 is 16 bytes: a 4-byte version number with value 1, the first 8 bytes of 593 the HMAC-MD5 [RFC 2104] of the message and the sequence number. 595 MAC(Ki, SeqNum, msg) = (0x00000001, HMAC(Ki, (SeqNum, msg))[0..7], 596 SeqNum) 598 where Ki is Kic for messages sent by the client and Kis for those sent 599 by the server. The sequence number is initialized to zero, and 600 incremented by one for each message sent. 602 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the 603 received value; the message is discarded if they differ. 605 2.4 Confidentiality Protection 607 If the server sent a "cipher-opts" directive and the client responded 608 with a "cipher" directive, then subsequent messages between the client 609 and the server MUST be confidentiality protected. Using as a base 610 session key the value of H(A1) as defined above the client and server 611 calculate a pair of message integrity keys as follows. 613 The key for confidentiality protecting messages from client to server 614 is: 616 Kcc = MD5(H(A1)[0..n], 617 "Digest H(A1) to client-to-server sealing key magic constant") 619 The key for confidentiality protecting messages from server to client 620 is: 622 Kcs = MD5(H(A1)[0..n], 623 "Digest H(A1) to server-to-client sealing key magic constant") 625 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for 626 "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers is 627 all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the 628 key for "3des" is the first 14 bytes. The IV for "des" and "3des" is the 629 last 8 bytes of Kcc or Kcs. 631 If message confidentiality is negotiated, each message is encrypted 632 with the chosen cipher and a MAC is appended to the message. 634 The MAC is a variable length padding prefix followed by 16 bytes 635 formatted as follows: a 4-byte version number with value 1, the first 8 636 bytes of the HMAC-MD5 [RFC 2104] of the message and the sequence number. 637 If the blocksize of the chosen cipher is not 1 byte, the padding prefix 638 is one or more octets each containing the number of padding bytes such 639 that length of the message plus the length of the padding prefix is a 640 multiple of the blocksize. 642 SEAL(Ki, Ke, SeqNum, msg) = CIPHER(Ke, { msg, pad}), CMAC(Ki, Ke, 643 SeqNum, msg) 644 CMAC(Ki, Ke, SeqNum, msg) = 645 { 0x00000001, CIPHER(Ke, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum } 646 Digest Authentication as a SASL Mechanism September 1998 648 where CIPHER is the chosen cipher, Ki and Ke are Kic and Kcc for 649 messages sent by the client and Kis and Kcs for those sent by the 650 server. The sequence number is initialized to zero, and incremented by 651 one for each message sent. 653 Upon receipt, the message is decrypted, CMAC(Ki, Ke, SeqNum, msg) is 654 computed and compared with the received value; the message is discarded 655 if they differ. 657 3 Security Considerations 659 3.1 Authentication of Clients using Digest Authentication 661 Digest Authentication does not provide a strong authentication 662 mechanism, when compared to public key based mechanisms, for example. 663 However, since it prevents chosen plaintext attacks, it is stronger than 664 (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and 665 IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and 666 even more dangerous use of plaintext passwords; however, since it is 667 still a password based mechanism it avoids some of the potential 668 deployabilty issues with public-key, OTP or similar mechanisms. 670 Digest Authentication offers no confidentiality protection beyond 671 protecting the actual password. All of the rest of the challenge 672 and response are available to an eavesdropper, including the 673 user's name and authentication realm. 675 3.2 Comparison of Digest with Plaintext Passwords 677 The greatest threat to the type of transactions for which these 678 protocols are used is network snooping. This kind of transaction 679 might involve, for example, online access to a mail service whose 680 use is restricted to paying subscribers. With plaintext password 681 authentication an eavesdropper can obtain the password of the 682 user. This not only permits him to access anything in the 683 database, but, often worse, will permit access to anything else 684 the user protects with the same password. 686 3.3 Replay Attacks 688 Replay attacks are defeated if the client or the server chooses a 689 fresh nonce for each authentication, as this specification 690 requires. 692 3.4 Online dictionary attacks 694 I f the attacker can eavesdrop, then it can test any overheard 695 nonce/response pairs against a (potentially very large) list of common 696 words. Such a list is usually much smaller than the total number of 697 possible passwords. The cost of computing the response for each password 698 on the list is paid once for each challenge. 700 Digest Authentication as a SASL Mechanism September 1998 702 The server can mitigate this attack by not allowing users to select 703 passwords that are in a dictionary. 705 3.5 Offline dictionary attacks 707 If the attacker can choose the challenge, then it can precompute the 708 possible responses to that challenge for a list of common words. Such a 709 list is usually much smaller than the total number of possible 710 passwords. The cost of computing the response for each password on the 711 list is paid just once. 713 Offline dictionary attacks are defeated if the client chooses a fresh 714 nonce for each authentication, as this specification requires. 716 3.6 Man in the Middle 718 Digest authentication is vulnerable to "man in the middle" (MITM) 719 attacks. Clearly, a MITM would present all the problems of 720 eavesdropping. But it also offers some additional opportunities to the 721 attacker. 723 A possible man-in-the-middle attack would be to substitute a weaker qop 724 scheme for the one(s) sent by the server; the server will not be able to 725 detect this attack. For this reason, the client should always use the 726 strongest scheme that it understands from the choices offered, and 727 should never choose a scheme that does not meet its minimum 728 requirements. 730 3.7 Chosen plaintext attacks 732 A chosen plaintext attack is where a MITM or a malicious server can 733 arbitrarily choose the challenge that the client will use to compute the 734 response. The ability to choose the challenge is known to make 735 cryptanalysis much easier [8]. 737 However, Digest does not permit the attack to choose the challenge as 738 long as the client chooses a fresh nonce for each authentication, as 739 this specification requires. 741 3.8 Spoofing by Counterfeit Servers 743 If a user can be led to believe that she is connecting to a host 744 containing information protected by a password she knows, when in fact 745 she is connecting to a hostile server, then the hostile server can 746 obtain challenge/response pairs where it was able to partly choose the 747 challenge. There is no known way that this can be exploited. 749 3.9 Storing passwords 751 Digest authentication requires that the authenticating agent (usually 752 the server) store some data derived from the user's name and password in 753 a "password file" associated with a given realm. Normally this might 754 contain pairs consisting of username and H(A1), where H(A1) is the 755 digested value of the username, realm, and password as described above. 757 Digest Authentication as a SASL Mechanism September 1998 759 The security implications of this are that if this password file is 760 compromised, then an attacker gains immediate access to documents on the 761 server using this realm. Unlike, say a standard UNIX password file, this 762 information need not be decrypted in order to access documents in the 763 server realm associated with this file. On the other hand, decryption, 764 or more likely a brute force attack, would be necessary to obtain the 765 user's password. This is the reason that the realm is part of the 766 digested data stored in the password file. It means that if one Digest 767 authentication password file is compromised, it does not automatically 768 compromise others with the same username and password (though it does 769 expose them to brute force attack). 771 There are two important security consequences of this. First the 772 password file must be protected as if it contained plaintext passwords, 773 because for the purpose of accessing documents in its realm, it 774 effectively does. 776 A second consequence of this is that the realm string should be unique 777 among all realms that any single user is likely to use. In particular a 778 realm string should include the name of the host doing the 779 authentication. 781 3.10 Multiple realms 783 Use of multiple realms may mean both that compromise of a the security 784 database for a single realm does not compromise all security, and that 785 there are more things to protect in order to keep the whole system 786 secure. 788 3.11 Summary 790 By modern cryptographic standards Digest Authentication is weak, 791 compared to (say) public key based mechanisms. But for a large range of 792 purposes it is valuable as a replacement for plaintext passwords. Its 793 strength may vary depending on the implementation. 795 4 Example 797 This example shows the use of the Digest SASL mechanism with the IMAP4 798 AUTHENTICATE command [RFC 2060]. The base64 encoding of the challenges 799 and responses is part of the IMAP4 AUTHENTICATE command, not part of the 800 Digest specification itself. (Note: linebreaks added for editorial 801 clarity are not part of the mechanism): 803 Digest Authentication as a SASL Mechanism September 1998 805 * OK elwood.innosoft.com IMAP4 Server PMDF5.3-1 at Mon, 28 Sep 1998 806 09:16:30 -0700 (PDT) 807 c CAPABILITY 808 * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE STARTTLS AUTH=CRAM-MD5 809 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN 810 c OK CAPABILITY completed 811 a AUTHENTICATE DIGEST-MD5 812 + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJENlBpNXVvT2xp 813 RzI4WFZidVRYQ0l3Iixxb3A9ImF1dGgi 814 dXNlcm5hbWU9ImNocmlzIixyZWFsbT0iZWx3b29kLmlubm9zb2Z0LmNvbSIsbm 815 9uY2U9IkQ2UGk1dW9PbGlHMjhYVmJ1VFhDSXciLG5jPTAwMDAwMDAxLGNub25j 816 ZT0iZS9nWG5wRW94ODNzVzNERXU3b1FoZyIscmVzcG9uc2U9IjRmNjA2NTBhYW 817 FmNDQxNzkyOWViNjg3Zjc2NmNlOTMyIixxb3A9ImF1dGgi 818 a OK AUTHENTICATE completed 819 --- 821 Decoding the base64, gets: 823 realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw",qop="auth 824 " 826 and 828 username="chris",realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVb 829 uTXCIw", 830 nc=00000001,cnonce="e/gXnpEox83sW3DEu7oQhg", 831 response="4f60650aaaf4417929eb687f766ce932",qop="auth" 833 The password was "secret". 835 The server uses the values of all the directives, plus knowledge of the 836 users password (or the hash of the user�s name, server�s realm and the 837 user�s password) to verify the computations above. If they check, then 838 the user has authenticated. 840 5 References 842 [Digest] Franks, J., et. al., "HTTP Authentication: Basic and Digest 843 Access Authentication", , Work in 844 Progress of the HTTP Working Group, August, 1998 846 [ISO-8859] ISO-8859. International Standard -- Information Processing -- 847 8-bit Single-Byte Coded Graphic Character Sets -- 848 Part 1: Latin alphabet No. 1, ISO-8859-1:1987. 849 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. 850 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. 851 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. 852 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. 853 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. 854 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. 855 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. 856 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. 858 Digest Authentication as a SASL Mechanism September 1998 860 [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet Text 861 Messages," STD 11, RFC 822, UDEL, August 1982. 863 [RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 864 April 1992 866 [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 867 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 868 University of Tennessee, November 1996. 870 [RFC 2060] Crispin, "Internet Message Access Protocol - Version 4rev1", 871 RFC 2060, University of Washington, December 1996. 873 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 874 for Message Authentication", RFC 2104, 02/05/1997 876 [RFC2195] Klensin, J., et. al., "IMAP/POP AUTHorize Extension for Simple 877 Challenge/Response", RFC 2195, September, 1997. 879 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 880 Requirement Levels," RFC 2119, Harvard University, March 1997. 882 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code 883 for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. 885 6 Authors' Addresses 887 Paul Leach 888 Microsoft 889 1 Microsoft Way 890 Redmond, WA 98052 891 paulle@microsoft.com 893 Chris Newman 894 Innosoft International, Inc. 895 1050 Lakes Drive 896 West Covina, CA 91790 USA 897 chris.newman@innosoft.com 899 7 ABNF 901 7.1 Augmented BNF 903 All of the mechanisms specified in this document are described in both 904 prose and an augmented Backus-Naur Form (BNF) similar to that used by 905 RFC 822 [RFC 822]. Implementors will need to be familiar with the 906 notation in order to understand this specification. The augmented BNF 907 includes the following constructs: 909 Digest Authentication as a SASL Mechanism September 1998 911 name = definition 912 The name of a rule is simply the name itself (without any enclosing 913 "<" and ">") and is separated from its definition by the equal "=" 914 character. White space is only significant in that indentation of 915 continuation lines is used to indicate a rule definition that spans 916 more than one line. Certain basic rules are in uppercase, such as SP, 917 LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within 918 definitions whenever their presence will facilitate discerning the 919 use of rule names. 921 "literal" 922 Quotation marks surround literal text. Unless stated otherwise, the 923 text is case-insensitive. 925 rule1 | rule2 926 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" 927 will accept yes or no. 929 (rule1 rule2) 930 Elements enclosed in parentheses are treated as a single element. 931 Thus, "(elem (foo | bar) elem)" allows the token sequences 932 "elem foo elem" and "elem bar elem". 934 *rule 935 The character "*" preceding an element indicates repetition. The full 936 form is "*element" indicating at least and at most 937 occurrences of element. Default values are 0 and infinity so that 938 "*(element)" allows any number, including zero; "1*element" requires 939 at least one; and "1*2element" allows one or two. 941 [rule] 942 Square brackets enclose optional elements; "[foo bar]" is equivalent 943 to "*1(foo bar)". 945 N rule 946 Specific repetition: "(element)" is equivalent to 947 "*(element)"; that is, exactly occurrences of (element). 948 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 949 alphabetic characters. 951 #rule 952 A construct "#" is defined, similar to "*", for defining lists of 953 elements. The full form is "#element" indicating at least 954 and at most elements, each separated by one or more commas (",") 955 and OPTIONAL linear white space (LWS). This makes the usual form of 956 lists very easy; a rule such as 957 ( *LWS element *( *LWS "," *LWS element )) 958 can be shown as 959 1#element 960 Wherever this construct is used, null elements are allowed, but do 961 not contribute to the count of elements present. That is, "(element), 962 , (element) " is permitted, but counts as only two elements. 964 Digest Authentication as a SASL Mechanism September 1998 966 Therefore, where at least one element is required, at least one non- 967 null element MUST be present. Default values are 0 and infinity so 968 that "#element" allows any number, including zero; "1#element" 969 requires at least one; and "1#2element" allows one or two. 971 ; comment 972 A semi-colon, set off some distance to the right of rule text, starts 973 a comment that continues to the end of line. This is a simple way of 974 including useful notes in parallel with the specifications. 976 implied *LWS 977 Except where noted otherwise, linear white space ("LWS") can be 978 included between any adjacent "token", "quoted-string", or 979 "separators" constructs, as these are defined in the basic rules 980 below; such LWS is ignored. 982 7.2 Basic Rules 984 The following rules are used throughout this specification to describe 985 basic parsing constructs. The US-ASCII coded character set is defined by 986 ANSI X3.4-1986 [USASCII]. 988 OCTET = 989 CHAR = 990 UPALPHA = 991 LOALPHA = 992 ALPHA = UPALPHA | LOALPHA 993 DIGIT = 994 CTL = 996 CR = 997 LF = 998 SP = 999 HT = 1000 <"> = 1002 All linear white space, including folding, has the same semantics as SP. 1003 A recipient MAY replace any linear white space with a single SP before 1004 interpreting the field value or forwarding the message downstream. 1006 LWS = [CRLF] 1*( SP | HT ) 1008 The TEXT rule is only used for descriptive field contents and values 1009 that are not intended to be interpreted by the message parser. Words of 1010 *TEXT MAY contain characters from character sets other than ISO-8859-1 1011 [ISO 8859] only when encoded according to the rules of RFC 2047 [RFC 1012 2047]. 1014 TEXT = 1016 Digest Authentication as a SASL Mechanism September 1998 1018 A CRLF is allowed in the definition of TEXT only as part of a header 1019 field continuation. It is expected that the folding LWS will be replaced 1020 with a single SP before interpretation of the TEXT value. 1022 Hexadecimal numeric characters are used in several protocol elements. 1024 HEX = "A" | "B" | "C" | "D" | "E" | "F" 1025 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 1027 Many HTTP/1.1 header field values consist of words separated by LWS or 1028 special characters. These special characters MUST be in a quoted string 1029 to be used within a parameter value. 1031 token = 1* 1032 separators = "(" | ")" | "<" | ">" | "@" 1033 | "," | ";" | ":" | "\" | <"> 1034 | "/" | "[" | "]" | "?" | "=" 1035 | "{" | "}" | SP | HT 1037 A string of text is parsed as a single word if it is quoted using 1038 double-quote marks. 1040 quoted-string = ( <"> qdstr-val <"> ) 1041 qdstr-val = *(qdtext | quoted-pair ) 1042 qdtext = > 1044 The backslash character ("\") MAY be used as a single-character quoting 1045 mechanism only within qdstr-val and comment constructs. 1047 quoted-pair = "\" CHAR 1049 The value of this construct is CHAR. Note that an effect of this rule is 1050 that backslash must be quoted. 1052 8 Sample Code 1054 The sample implementation in [Digest] also applies to DIGEST-MD5. 1056 The following code implements the conversion from UTF-8 to 8859-1 if 1057 necessary. 1059 Digest Authentication as a SASL Mechanism September 1998 1061 /* if the string is entirely in the 8859-1 subset of UTF-8, then 1062 translate 1063 * to 8859-1 prior to MD5 1064 */ 1065 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, int 1066 len) 1067 { 1068 const unsigned char *scan, *end; 1069 unsigned char cbuf; 1071 end = base + len; 1072 for (scan = base; scan < end; ++scan) { 1073 if (*scan > 0xC3) break; /* abort if outside 8859-1 */ 1074 if (*scan >= 0xC0 && *scan <= 0xC3) { 1075 if (++scan == end || *scan < 0x80 || *scan > 0xBF) 1076 break; 1077 } 1078 } 1079 /* if we found a character outside 8859-1, don't alter string 1080 */ 1081 if (scan < end) { 1082 MD5Update(ctx, base, len); 1083 return; 1084 } 1086 /* convert to 8859-1 prior to applying hash 1087 */ 1088 do { 1089 for (scan = base; scan < end && *scan < 0xC0; ++scan) 1090 ; 1091 if (scan != base) MD5Update(ctx, base, scan - base); 1092 if (scan + 1 >= end) break; 1093 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f); 1094 MD5Update(ctx, &cbuf, 1); 1095 base = scan + 2; 1096 } while (base < end); 1097 } 1099 9 Full Copyright Statement 1101 Copyright (C) The Internet Society (1998). All Rights Reserved. 1103 This document and translations of it may be copied and furnished to 1104 others, and derivative works that comment on or otherwise explain it or 1105 assist in its implmentation may be prepared, copied, published and 1106 distributed, in whole or in part, without restriction of any kind, 1107 provided that the above copyright notice and this paragraph are included 1108 on all such copies and derivative works. However, this document itself 1109 may not be modified in any way, such as by removing the copyright notice 1110 or references to the Internet Society or other Internet organizations, 1111 except as needed for the purpose of developing Internet standards in 1112 which case the procedures for copyrights defined in the Internet 1113 Digest Authentication as a SASL Mechanism September 1998 1115 Standards process must be followed, or as required to translate it into 1116 languages other than English. 1118 The limited permissions granted above are perpetual and will not be 1119 revoked by the Internet Society or its successors or assigns. 1121 This document and the information contained herein is provided on an "AS 1122 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1123 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1124 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1125 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1126 FITNESS FOR A PARTICULAR PURPOSE.