idnits 2.17.1 draft-leach-digest-sasl-01.txt: -(805): 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 22 longer pages, the longest (page 8) 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 6 instances of too long lines in the document, the longest one being 8 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 608 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 (November 18, 1998) is 9284 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) == Missing Reference: 'FIPS' is mentioned on line 274, but not defined -- Looks like a reference, but probably isn't: '10' on line 642 -- Looks like a reference, but probably isn't: '9' on line 643 -- Looks like a reference, but probably isn't: '8' on line 713 == Missing Reference: 'ISO 8859' is mentioned on line 980, but not defined == Unused Reference: 'ISO-8859' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC 2047' is defined on line 835, 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 (~~), 10 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-01.txt 7 Category: Standards Track 8 Expires May 18, 1999 November 18, 1998 10 Using Digest Authentication as a SASL Mechanism 12 Preliminary Draft 14 Author's draft: 9 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.1.1 Step One......................................................4 67 2.1.2 Step Two......................................................6 69 2.1.3 Step Three...................................................10 71 2.2 SUBSEQUENT AUTHENTICATION.......................................10 73 2.2.1 Step one.....................................................10 75 2.2.2 Step Two.....................................................10 77 2.3 INTEGRITY PROTECTION............................................11 79 3 SECURITY CONSIDERATIONS............................................13 81 3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION...........13 83 3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS...................13 85 3.3 REPLAY ATTACKS..................................................13 87 3.4 ONLINE DICTIONARY ATTACKS.......................................13 89 3.5 OFFLINE DICTIONARY ATTACKS......................................13 91 3.6 MAN IN THE MIDDLE...............................................14 93 3.7 CHOSEN PLAINTEXT ATTACKS........................................14 95 3.8 SPOOFING BY COUNTERFEIT SERVERS.................................14 97 3.9 STORING PASSWORDS...............................................14 99 3.10SUMMARY.........................................................15 101 4 EXAMPLE............................................................15 103 5 REFERENCES.........................................................16 105 6 AUTHORS' ADDRESSES.................................................17 106 Digest Authentication as a SASL Mechanism September 1998 108 7 ABNF...............................................................17 110 7.1 AUGMENTED BNF...................................................17 112 7.2 BASIC RULES.....................................................19 114 8 SAMPLE CODE........................................................20 116 9 FULL COPYRIGHT STATEMENT...........................................21 118 1 Introduction 120 This specification describes the use of HTTP Digest Access 121 Authentication as a SASL mechanism. The authentication type associated 122 with the Digest SASL mechanism is "DIGEST-MD5". 124 This specification is intended to be upward compatible with the "md5- 125 sess" algorithm of HTTP/1.1 Digest Access Authentication specified in 126 [Digest]. The only difference in the "md5-sess" algorithm is that some 127 directives not needed in a SASL mechanism have had their values 128 defaulted. 130 There is one new feature for use as a SASL mechanism: integrity 131 protection on application protocol messages after an authentication 132 exchange. 134 Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext 135 attacks, and permits the use of third party authentication servers, 136 mutual authentication, and optimized reauthentication if a client has 137 recently authenticated to a server. 139 1.1 Conventions and Notation 141 This specification uses the same ABNF notation and lexical conventions 142 as HTTP/1.1 specification; see appendix A. 144 Let { a, b, ... } be the concatenation of the strings a, b, � 146 Let H(s) be the 16 octet MD5 hash of the string s. 148 Let KD(k, s) be the 16 octet MD5 hash of the concatenation of the string 149 k, ":" (a 1 character long string consisting of a colon), and the string 150 s. 152 Let HEX(n) be the representation of the 16 octet MD5 hash n as a string 153 of 32 hex digits (with alphabetic characters always in lower case), 154 since MD5 is case sensitive. 156 Digest Authentication as a SASL Mechanism September 1998 158 1.2 Requirements 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC 2119]. 164 An implementation is not compliant if it fails to satisfy one or more of 165 the MUST level requirements for the protocols it implements. An 166 implementation that satisfies all the MUST level and all the SHOULD 167 level requirements for its protocols is said to be "unconditionally 168 compliant"; one that satisfies all the MUST level requirements but not 169 all the SHOULD level requirements for its protocols is said to be 170 "conditionally compliant." 172 2 Authentication 174 The following sections describe how to use Digest as a SASL 175 authentication mechanism. 177 2.1 Initial Authentication 179 If the client has not recently authenticated to the server, then it must 180 perform "initial authentication", as defined in this section. If it has 181 recently authenticated, then a more efficient form is available, defined 182 in the next section. 184 2.1.1 Step One 186 The server starts by sending a challenge. The data encoded in the 187 challenge contains a string formatted according to the rules for a 188 "digest-challenge" defined as follows: 190 digest-challenge = 1#( realm | nonce | qop-options | stale | 191 maxbuf | charset | cipher-opts | auth-param ) 193 realm = "realm" "=" <"> realm-value <"> 194 realm-value = qdstr-val 195 nonce = "nonce" "=" <"> nonce-value <"> 196 nonce-value = qdstr-val 197 qop-options = "qop" "=" <"> qop-list <"> 198 qop-list = 1#qop-value 199 qop-value = "auth" | "auth-int" | "auth-conf" | 200 token 201 stale = "stale" "=" "true" 202 maxbuf = "maxbuf" "=" maxbuf-value 203 maxbuf-value = 1*DIGIT 204 charset = "charset" "=" "utf-8" 205 algorithm = "algorithm" "=" "md5-sess" 206 cipher-opts = "cipher" "=" 1#cipher-value 207 cipher-value = "3des" | "des" | "rc4-40" | "rc4" | "rc4-56" | token 208 Digest Authentication as a SASL Mechanism September 1998 210 auth-param = token "=" ( token | quoted-string ) 212 The meanings of the values of the directives used above are as follows: 214 realm 215 A string to be displayed to users so they know which username and 216 password to use. This string should contain at least the name of the 217 host performing the authentication and might additionally indicate 218 the collection of users who might have access. An example might be 219 "registered_users@gotham.news.com". This directive is optional; if 220 not present, it defaults to the realm used by the user to login to 221 the client system. Multiple realm directives are allowed. 223 nonce 224 A server-specified data string which MUST be different each time a 225 digest-challenge is sent as part of initial authentication. It is 226 recommended that this string be base64 or hexadecimal data. Note that 227 since the string is passed as a quoted string, the double-quote 228 character is not allowed. The contents of the nonce are 229 implementation dependent. The quality of the implementation depends 230 on a good choice. The nonce is opaque to the client. This directive 231 is required and may appear exactly once; if not present, or if 232 multiple instances are present, the client should abort the 233 authentication exchange. 235 qop-options 236 A quoted string of one or more tokens indicating the "quality of 237 protection" values supported by the server. The value "auth" 238 indicates authentication; the value "auth-int" indicates 239 authentication with integrity protection; the value "auth-conf" 240 indicates authentication with integrity protection and encryption. 241 The client MUST ignore unrecognized options; if the client recognizes 242 no option, it should abort the authentication exchange. 244 stale 245 The "stale" directive is not used in initial authentication. See the 246 next section for its use in subsequent authentications. 248 maxbuf 249 A number indicating the size of the largest buffer the server is able 250 to receive when using "auth-int". If this directive is missing, the 251 default value is 65536. This directive may appear at most once; if 252 multiple instances are present, the client should abort the 253 authentication exchange. 255 charset 256 This directive, if present, specifies that the server supports UTF-8 257 encoding for the username and password. If not present, the username 258 and password must be encoded in ISO 8859-1 (of which US-ASCII is a 259 subset). The directive is needed for backwards compatibility with 260 HTTP Digest, which only supports ISO 8859-1. 262 Digest Authentication as a SASL Mechanism September 1998 264 algorithm 265 This directive is required for backwards compatibility with HTTP 266 Digest., which supports other algorithms. 268 cipher-opts 269 A list of ciphers that the server supports. The "3des" and "des" 270 modes are mandatory-to-implement. This directive must be present 271 exactly once if "auth-conf" is offered. 273 des 274 the Data Encryption Standard (DES) cipher [FIPS] in cipher block 275 chaining (CBC) mode with a 56 bit key. 277 3des 278 the "triple DES" cipher in CBC mode with EDE with the same key for 279 each E stage (aka "two keys mode") for a total key length of 112 280 bits. 282 rc4, rc4-40, rc4-56 283 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively. 285 auth-param 286 This directive allows for future extensions. The client MUST ignore 287 any unrecognized directive. 289 For use as a SASL mechanism, note that the following changes are made to 290 "digest-challenge" from HTTP: the following Digest options (called 291 "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, 292 and MUST be ignored if received): 294 opaque 295 domain 297 The size of a digest-challenge MUST be less than 2048 bytes. 299 2.1.2 Step Two 301 The client makes note of the "digest-challenge" and then responds with a 302 string formatted and computed according to the rules for a "digest- 303 response" defined as follows: 305 digest-response = 1#( username | realm | nonce | cnonce | 306 nonce-count | qop | digest-uri | response | 307 maxbuf | charset | cipher | auth-param ) 309 username = "username" "=" <"> username-value <"> 310 username-value = qdstr-val 311 cnonce = "cnonce" "=" <"> cnonce-value <"> 312 cnonce-value = qdstr-val 313 nonce-count = "nc" "=" nc-value 314 nc-value = 8LHEX 315 qop = "qop" "=" qop-value 316 Digest Authentication as a SASL Mechanism September 1998 318 digest-uri = "digest-uri" "=" digest-uri-value 319 digest-uri-value = serv-type "/" host [ "/" serv-name ] 320 serv-type = 1*ALPHA 321 host = 1*( ALPHA | DIGIT | "-" | "." ) 322 service = host 323 response = "response" "=" <"> response-value <"> 324 response-value = 32LHEX 325 LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 326 "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" 327 cipher = "cipher" "=" cipher-value 329 username 330 The user's name in the specified realm, encoded as UTF-8. This 331 directive is required; if not present, authentication fails. 333 realm 334 The realm containing the user's account. It MUST be one of the realms 335 from the "digest-challenge", if any were provided. This directive is 336 required unless the server did not provide any realms; otherwise, if 337 not present, or not one of the ones in the "digest-challenge", 338 authentication fails. 340 nonce 341 The server-specified data string received in the preceding digest- 342 challenge. 344 cnonce 345 A client-specified data string which MUST be different each time a 346 digest-response is sent as part of initial authentication. The 347 cnonce-value is an opaque quoted string value provided by the client 348 and used by both client and server to avoid chosen plaintext attacks, 349 and to provide mutual authentication. This directive is required; if 350 not present, authentication fails. 352 nonce-count 353 The nc-value is the hexadecimal count of the number of requests 354 (including the current request) that the client has sent with the 355 nonce value in this request. For example, in the first request sent 356 in response to a given nonce value, the client sends "nc=00000001". 357 The purpose of this directive is to allow the server to detect 358 request replays by maintaining its own copy of this count - if the 359 same nc-value is seen twice, then the request is a replay. See the 360 description below of the construction of the response value. 362 qop 363 Indicates what "quality of protection" the client accepted. If 364 present, its value MUST be one of the alternatives the server 365 indicated it supports in digest-challenge. If not present, it 366 defaults to "auth". These values affect the computation of the 367 Digest Authentication as a SASL Mechanism September 1998 369 response. Note that this is a single token, not a quoted list of 370 alternatives. 372 serv-type 373 Indicates the type of service, such as "www" for web service, "ftp" 374 for FTP service, "SMTP" for mail delivery service, etc.. 376 host 377 Indicates the host name for the service requested. 379 serv-name 380 Indicates the name of the service if it is replicated. For example, 381 the incoming mail service for "xyz.com" may be replicated through the 382 use of MX records stored in the DNS, one of which points at an SMTP 383 server called "mail3.xyz.com"; it's "serv-name" would be "xyz.com", 384 it's "host" would be "mail3.xyz.com". 386 digest-uri 387 Indicates the principal name of the service with which the client 388 wishes to connect, formed from the serv-type, host, and serv-name. 389 For example, the FTP service on "ftp.xyz.com" would have a "digest- 390 uri" value of "ftp/ftp.xyz.com"; the SMTP server from the example 391 above would have a "digest-uri" value of "smtp/mail3.xyz.com/xyz.com" 393 response 394 A string of 32 hex digits computed as defined below, which proves 395 that the user knows a password. This directive is required; if not 396 present, authentication fails. 398 maxbuf 399 A number indicating the size of the largest buffer the client is able 400 to receive. If this directive is missing, the default value is 65536. 401 This directive may appear at most once; if multiple instances are 402 present, the server should abort the authentication exchange. 404 charset 405 This directive, if present, specifies that the client has used UTF-8 406 encoding for the username and password. If not present, the username 407 and password must be encoded in ISO 8859-1 (of which US-ASCII is a 408 subset). The client should send this directive only if the server has 409 indicated it supports UTF-8. The directive is needed for backwards 410 compatibility with HTTP Digest, which only supports ISO 8859-1. 412 LHEX 413 32 hex digits, where the alphabetic characters MUST be lower case, 414 because MD5 is not case insensitive. 416 cipher 417 The cipher chosen by the client. This directive MUST appear exactly 418 once if "auth-conf" is negotiated; if required and not present, 419 authentication fails. 421 Digest Authentication as a SASL Mechanism September 1998 423 The size of a digest-response MUST be less than 2048 bytes. 425 2.1.2.1 Response-value 427 The definition of "response-value" above indicates the encoding for its 428 value -- 32 lower case hex characters. The following definitions show 429 how the value is computed. 431 response-value = 432 HEX( KD ( HEX(H(A1)), 433 { nonce-value, ":" nc-value, ":", 434 cnonce-value, ":", qop-value, ":", HEX(H(A2))})) 436 A1 is 438 A1 = { H( { username-value, ":", realm-value, ":", passwd } ), 439 ":", nonce-value, ":", cnonce-value } 441 where 443 passwd = *OCTET 445 The "username-value", "realm-value" and "passwd" are encoded according 446 to the value of the "charset" directive. If "charset=UTF-8" is present, 447 and all the characters of either "username-value" or "passwd" are in the 448 ISO 8859-1 character set, then it must be converted to ISO 8859-1 before 449 being hashed. A sample implementation of this conversion is in section 450 8. 452 If the "qop" directive's value is "auth", then A2 is: 454 A2 = { "AUTHENTICATE:", digest-uri-value } 456 If the "qop" value is "auth-int" then A2 is: 458 A2 = { "AUTHENTICATE:", digest-uri-value, 459 ":00000000000000000000000000000000" } 461 Note that "AUTHENTICATE:" must be in upper case, and the second string 462 constant is a string with a colon followed by 32 zeros. 464 These apparently strange values of A2 are for compatibility with HTTP; 465 they were arrived at by setting "Method" to "AUTHENTICATE" and the hash 466 of the entity body to zero in the HTTP digest calculation of A2. 468 Also, in the HTTP usage of Digest, several directives in the "digest- 469 challenge" sent by the server have to be returned by the client in the 470 "digest-response". These are: 472 Digest Authentication as a SASL Mechanism September 1998 474 opaque 475 algorithm 477 These directives are not needed when Digest is used as a SASL mechanism 478 (i.e., MUST NOT be sent, and MUST be ignored if received). 480 2.1.3 Step Three 482 The server receives and validates the "digest-response". The server 483 checks that the nonce-count is "00000001". If it supports subsequent 484 authentication, it saves the value of the nonce and the nonce-count. It 485 sends a message formatted as follows: 487 response-auth = "rspauth" "=" response-value 489 where response-value is calculated as above, using the values sent in 490 step three, except that if qop is "auth", then A2 is 492 A2 = { ":", digest-uri-value } 494 And if qop is "auth-int" then A2 is 496 A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" } 498 Compared to its use in HTTP, the following Digest directives in the 499 "digest-response" are unused: 501 nextnonce 502 qop 503 cnonce 504 nonce-count 506 2.2 Subsequent Authentication 508 If the client has previously authenticated to the server, and remembers 509 the values of username, realm, nonce, nonce-count, cnonce, and qop that 510 it used in that authentication, and the SASL profile for a protocol 511 permits an initial client response, then it MAY perform "subsequent 512 authentication", as defined in this section. 514 2.2.1 Step one 516 The client uses the values from the previous authentication and sends an 517 initial response with a string formatted and computed according to the 518 rules for a "digest-response", as defined above, but with a nonce-count 519 one greater than used in the last "digest-response". 521 2.2.2 Step Two 523 The server receives and validates the "digest-response". In addition, 524 if it has saved the nonce and nonce-count from a previous 525 authentication, the server checks that the nonce-count is one greater 526 Digest Authentication as a SASL Mechanism September 1998 528 than that used in the previous authentication using that nonce, and 529 saves the new value of nonce-count. 531 If the response is invalid, then the server sends a "digest-challenge", 532 and authentication proceeds as in initial authentication (and should be 533 configurable to log an authentication failure in some sort of security 534 audit log, since the failure may be a symptom of an attack). 536 If the response is valid, the server MAY choose to deem that 537 authentication has succeeded. However, if it has been too long since the 538 previous authentication, or for any other reason, the server MAY send a 539 new "digest-challenge" with a new value for nonce. The challenge MAY 540 contain a "stale" directive with value "true", which says that the 541 client may respond to the challenge using the password it used in the 542 previous response; otherwise, the client must solicit a new password 543 from the user. Except for the handling of "stale", after sending the 544 "digest-challenge" authentication proceeds as in the case of initial 545 authentication. 547 2.3 Integrity Protection 549 If the server offered "qop=auth-int" and the client responded "qop=auth- 550 int", then subsequent messages between the client and the server MUST be 551 integrity protected. Using as a base session key the value of H(A1) as 552 defined above the client and server calculate a pair of message 553 integrity keys as follows. 555 The key for integrity protecting messages from client to server is: 557 Kic = MD5(H(A1), 558 "Digest session key to client-to-server signing key magic constant") 560 The key for integrity protecting messages from client to server is: 562 Kis = MD5(H(A1), 563 "Digest session key to server-to-client signing key magic constant") 565 where MD5 is as specified in [RFC 1321]. If message integrity is 566 negotiated, a MAC for each message is appended to the message. The MAC 567 is 16 bytes: a 4-byte version number with value 1, the first 8 bytes of 568 the HMAC-MD5 [RFC 2104] of the message and the sequence number. 570 MAC(Ki, SeqNum, msg) = (0x00000001, HMAC(Ki, (SeqNum, msg))[0..7], 571 SeqNum) 573 where Ki is Kic for messages sent by the client and Kis for those sent 574 by the server. The sequence number is initialized to zero, and 575 incremented by one for each message sent. 577 Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the 578 received value; the message is discarded if they differ. 580 Digest Authentication as a SASL Mechanism September 1998 582 2.4 Confidentiality Protection 584 If the server sent a "cipher-opts" directive and the client responded 585 with a "cipher" directive, then subsequent messages between the client 586 and the server MUST be confidentiality protected. Using as a base 587 session key the value of H(A1) as defined above the client and server 588 calculate a pair of message integrity keys as follows. 590 The key for confidentiality protecting messages from client to server 591 is: 593 Kcc = MD5(H(A1)[0..n], 594 "Digest H(A1) to client-to-server sealing key magic constant") 596 The key for confidentiality protecting messages from client to server 597 is: 599 Kcs = MD5(H(A1)[0..n], 600 "Digest H(A1) to server-to-client sealing key magic constant") 602 where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for 603 "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers is 604 all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the 605 key for "3des" is the first 14 bytes. The IV for "des" and "3des" is the 606 last 8 bytes of Kcc or Kcs. 608 If message confidentiality is negotiated, each message is encrypted 609 with the chosen cipher and a MAC is appended to the message. 611 The MAC is a variable length padding prefix followed by 16 bytes 612 formatted as follows: a 4-byte version number with value 1, the first 8 613 bytes of the HMAC-MD5 [RFC 2104] of the message and the sequence number. 614 If the blocksize of the chosen cipher is not 1 byte, the padding prefix 615 is one or more octets each containing the number of padding bytes such 616 that length of the message plus the length of the padding prefix is a 617 multiple of the blocksize. 619 SEAL(Ki, Ke, SeqNum, msg) = CIPHER(Ke, { msg, pad}), CMAC(Ki, Ke, 620 SeqNum, msg) 621 CMAC(Ki, Ke, SeqNum, msg) = 622 { 0x00000001, CIPHER(Ke, HMAC(Ki, (SeqNum, msg))[0..7]), SeqNum } 624 where CIPHER is the chosen cipher, Ki and Ke are Kic and Kec for 625 messages sent by the client and Kis and Kes for those sent by the 626 server. The sequence number is initialized to zero, and incremented by 627 one for each message sent. 629 Upon receipt, the message is decrypted, CMAC(Ki, Ke, SeqNum, msg) is 630 computed and compared with the received value; the message is discarded 631 if they differ. 633 Digest Authentication as a SASL Mechanism September 1998 635 3 Security Considerations 637 3.1 Authentication of Clients using Digest Authentication 639 Digest Authentication does not provide a strong authentication 640 mechanism, when compared to public key based mechanisms, for example. 641 However, since it prevents chosen plaintext attacks, it is stronger than 642 (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and 643 IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and 644 even more dangerous use of plaintext passwords; however, since it is 645 still a password based mechanism it avoids some of the potential 646 deployabilty issues with public-key, OTP or similar mechanisms. 648 Digest Authentication offers no confidentiality protection beyond 649 protecting the actual password. All of the rest of the challenge 650 and response are available to an eavesdropper, including the 651 user's name and authentication realm. 653 3.2 Comparison of Digest with Plaintext Passwords 655 The greatest threat to the type of transactions for which these 656 protocols are used is network snooping. This kind of transaction 657 might involve, for example, online access to a mail service whose 658 use is restricted to paying subscribers. With plaintext password 659 authentication an eavesdropper can obtain the password of the 660 user. This not only permits him to access anything in the 661 database, but, often worse, will permit access to anything else 662 the user protects with the same password. 664 3.3 Replay Attacks 666 Replay attacks are defeated if the client or the server chooses a 667 fresh nonce for each authentication, as this specification 668 requires. 670 3.4 Online dictionary attacks 672 If the attacker can eavesdrop, then it can test any overheard 673 nonce/response pairs against a (potentially very large) list of common 674 words. Such a list is usually much smaller than the total number of 675 possible passwords. The cost of computing the response for each password 676 on the list is paid once for each challenge. 678 The server can mitigate this attack by not allowing users to select 679 passwords that are in a dictionary. 681 3.5 Offline dictionary attacks 683 If the attacker can choose the challenge, then it can precompute the 684 possible responses to that challenge for a list of common words. Such a 685 list is usually much smaller than the total number of possible 686 passwords. The cost of computing the response for each password on the 687 list is paid just once. 689 Digest Authentication as a SASL Mechanism September 1998 691 Offline dictionary attacks are defeated if the client chooses a fresh 692 nonce for each authentication, as this specification requires. 694 3.6 Man in the Middle 696 Digest authentication is vulnerable to "man in the middle" (MITM) 697 attacks. Clearly, a MITM would present all the problems of 698 eavesdropping. But it also offers some additional opportunities to the 699 attacker. 701 A possible man-in-the-middle attack would be to substitute a weaker qop 702 scheme for the one(s) sent by the server; the server will not be able to 703 detect this attack. For this reason, the client should always use the 704 strongest scheme that it understands from the choices offered, and 705 should never choose a scheme that does not meet its minimum 706 requirements. 708 3.7 Chosen plaintext attacks 710 A chosen plaintext attack is where a MITM or a malicious server can 711 arbitrarily choose the challenge that the client will use to compute the 712 response. The ability to choose the challenge is known to make 713 cryptanalysis much easier [8]. 715 However, Digest does not permit the attack to choose the challenge as 716 long as the client chooses a fresh nonce for each authentication, as 717 this specification requires. 719 3.8 Spoofing by Counterfeit Servers 721 If a user can be led to believe that she is connecting to a host 722 containing information protected by a password she knows, when in fact 723 she is connecting to a hostile server, then the hostile server can 724 obtain challenge/response pairs where it was able to partly choose the 725 challenge. There is no known way that this can be exploited. 727 3.9 Storing passwords 729 Digest authentication requires that the authenticating agent (usually 730 the server) store some data derived from the user's name and password in 731 a "password file" associated with a given realm. Normally this might 732 contain pairs consisting of username and H(A1), where H(A1) is the 733 digested value of the username, realm, and password as described above. 735 The security implications of this are that if this password file is 736 compromised, then an attacker gains immediate access to documents on the 737 server using this realm. Unlike, say a standard UNIX password file, this 738 information need not be decrypted in order to access documents in the 739 server realm associated with this file. On the other hand, decryption, 740 or more likely a brute force attack, would be necessary to obtain the 741 user's password. This is the reason that the realm is part of the 742 digested data stored in the password file. It means that if one Digest 743 authentication password file is compromised, it does not automatically 744 Digest Authentication as a SASL Mechanism September 1998 746 compromise others with the same username and password (though it does 747 expose them to brute force attack). 749 There are two important security consequences of this. First the 750 password file must be protected as if it contained plaintext passwords, 751 because for the purpose of accessing documents in its realm, it 752 effectively does. 754 A second consequence of this is that the realm string should be unique 755 among all realms that any single user is likely to use. In particular a 756 realm string should include the name of the host doing the 757 authentication. 759 3.10 Summary 761 By modern cryptographic standards Digest Authentication is weak, 762 compared to (say) public key based mechanisms. But for a large range of 763 purposes it is valuable as a replacement for plaintext passwords. Its 764 strength may vary depending on the implementation. 766 4 Example 768 This example shows the use of the Digest SASL mechanism with the IMAP4 769 AUTHENTICATE command [RFC 2060]. The base64 encoding of the challenges 770 and responses is part of the IMAP4 AUTHENTICATE command, not part of the 771 Digest specification itself. (Note: linebreaks added for editorial 772 clarity are not part of the mechanism): 774 Digest Authentication as a SASL Mechanism September 1998 776 * OK elwood.innosoft.com IMAP4 Server PMDF5.3-1 at Mon, 28 Sep 1998 777 09:16:30 -0700 (PDT) 778 c CAPABILITY 779 * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE STARTTLS AUTH=CRAM-MD5 780 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN 781 c OK CAPABILITY completed 782 a AUTHENTICATE DIGEST-MD5 783 + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJENlBpNXVvT2xp 784 RzI4WFZidVRYQ0l3Iixxb3A9ImF1dGgi 785 dXNlcm5hbWU9ImNocmlzIixyZWFsbT0iZWx3b29kLmlubm9zb2Z0LmNvbSIsbm 786 9uY2U9IkQ2UGk1dW9PbGlHMjhYVmJ1VFhDSXciLG5jPTAwMDAwMDAxLGNub25j 787 ZT0iZS9nWG5wRW94ODNzVzNERXU3b1FoZyIscmVzcG9uc2U9IjRmNjA2NTBhYW 788 FmNDQxNzkyOWViNjg3Zjc2NmNlOTMyIixxb3A9ImF1dGgi 789 a OK AUTHENTICATE completed 790 --- 792 Decoding the base64, gets: 794 realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw",qop="auth" 796 and 798 username="chris",realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw", 799 nc=00000001,cnonce="e/gXnpEox83sW3DEu7oQhg", 800 response="4f60650aaaf4417929eb687f766ce932",qop="auth" 802 The password was "secret". 804 The server uses the values of all the directives, plus knowledge of the 805 users password (or the hash of the user�s name, server�s realm and the 806 user�s password) to verify the computations above. If they check, then 807 the user has authenticated. 809 5 References 811 [Digest] Franks, J., et. al., "HTTP Authentication: Basic and Digest 812 Access Authentication", , Work in 813 Progress of the HTTP Working Group, August, 1998 815 [ISO-8859] ISO-8859. International Standard -- Information Processing -- 816 8-bit Single-Byte Coded Graphic Character Sets -- 817 Part 1: Latin alphabet No. 1, ISO-8859-1:1987. 818 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. 819 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. 820 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. 821 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. 822 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. 823 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. 824 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. 825 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. 827 Digest Authentication as a SASL Mechanism September 1998 829 [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet Text 830 Messages," STD 11, RFC 822, UDEL, August 1982. 832 [RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 833 April 1992 835 [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 836 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 837 University of Tennessee, November 1996. 839 [RFC 2060] Crispin, "Internet Message Access Protocol - Version 4rev1", 840 RFC 2060, University of Washington, December 1996. 842 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 843 for Message Authentication", RFC 2104, 02/05/1997 845 [RFC2195] Klensin, J., et. al., "IMAP/POP AUTHorize Extension for Simple 846 Challenge/Response", RFC 2195, September, 1997. 848 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels," RFC 2119, Harvard University, March 1997. 851 [USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code 852 for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. 854 6 Authors' Addresses 856 Paul Leach 857 Microsoft 858 1 Microsoft Way 859 Redmond, WA 98052 860 paulle@microsoft.com 862 Chris Newman 863 Innosoft International, Inc. 864 1050 Lakes Drive 865 West Covina, CA 91790 USA 866 chris.newman@innosoft.com 868 7 ABNF 870 7.1 Augmented BNF 872 All of the mechanisms specified in this document are described in both 873 prose and an augmented Backus-Naur Form (BNF) similar to that used by 874 RFC 822 [RFC 822]. Implementors will need to be familiar with the 875 notation in order to understand this specification. The augmented BNF 876 includes the following constructs: 878 Digest Authentication as a SASL Mechanism September 1998 880 name = definition 881 The name of a rule is simply the name itself (without any enclosing 882 "<" and ">") and is separated from its definition by the equal "=" 883 character. White space is only significant in that indentation of 884 continuation lines is used to indicate a rule definition that spans 885 more than one line. Certain basic rules are in uppercase, such as SP, 886 LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within 887 definitions whenever their presence will facilitate discerning the 888 use of rule names. 890 "literal" 891 Quotation marks surround literal text. Unless stated otherwise, the 892 text is case-insensitive. 894 rule1 | rule2 895 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" 896 will accept yes or no. 898 (rule1 rule2) 899 Elements enclosed in parentheses are treated as a single element. 900 Thus, "(elem (foo | bar) elem)" allows the token sequences 901 "elem foo elem" and "elem bar elem". 903 *rule 904 The character "*" preceding an element indicates repetition. The full 905 form is "*element" indicating at least and at most 906 occurrences of element. Default values are 0 and infinity so that 907 "*(element)" allows any number, including zero; "1*element" requires 908 at least one; and "1*2element" allows one or two. 910 [rule] 911 Square brackets enclose optional elements; "[foo bar]" is equivalent 912 to "*1(foo bar)". 914 N rule 915 Specific repetition: "(element)" is equivalent to 916 "*(element)"; that is, exactly occurrences of (element). 917 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 918 alphabetic characters. 920 #rule 921 A construct "#" is defined, similar to "*", for defining lists of 922 elements. The full form is "#element" indicating at least 923 and at most elements, each separated by one or more commas (",") 924 and OPTIONAL linear white space (LWS). This makes the usual form of 925 lists very easy; a rule such as 926 ( *LWS element *( *LWS "," *LWS element )) 927 can be shown as 928 1#element 929 Wherever this construct is used, null elements are allowed, but do 930 not contribute to the count of elements present. That is, "(element), 931 , (element) " is permitted, but counts as only two elements. 933 Digest Authentication as a SASL Mechanism September 1998 935 Therefore, where at least one element is required, at least one non- 936 null element MUST be present. Default values are 0 and infinity so 937 that "#element" allows any number, including zero; "1#element" 938 requires at least one; and "1#2element" allows one or two. 940 ; comment 941 A semi-colon, set off some distance to the right of rule text, starts 942 a comment that continues to the end of line. This is a simple way of 943 including useful notes in parallel with the specifications. 945 implied *LWS 946 Except where noted otherwise, linear white space ("LWS") can be 947 included between any adjacent "token", "quoted-string", or 948 "separators" constructs, as these are defined in the basic rules 949 below; such LWS is ignored. 951 7.2 Basic Rules 953 The following rules are used throughout this specification to describe 954 basic parsing constructs. The US-ASCII coded character set is defined by 955 ANSI X3.4-1986 [USASCII]. 957 OCTET = 958 CHAR = 959 UPALPHA = 960 LOALPHA = 961 ALPHA = UPALPHA | LOALPHA 962 DIGIT = 963 CTL = 965 CR = 966 LF = 967 SP = 968 HT = 969 <"> = 971 All linear white space, including folding, has the same semantics as SP. 972 A recipient MAY replace any linear white space with a single SP before 973 interpreting the field value or forwarding the message downstream. 975 LWS = [CRLF] 1*( SP | HT ) 977 The TEXT rule is only used for descriptive field contents and values 978 that are not intended to be interpreted by the message parser. Words of 979 *TEXT MAY contain characters from character sets other than ISO-8859-1 980 [ISO 8859] only when encoded according to the rules of RFC 2047 [RFC 981 2047]. 983 TEXT = 985 Digest Authentication as a SASL Mechanism September 1998 987 A CRLF is allowed in the definition of TEXT only as part of a header 988 field continuation. It is expected that the folding LWS will be replaced 989 with a single SP before interpretation of the TEXT value. 991 Hexadecimal numeric characters are used in several protocol elements. 993 HEX = "A" | "B" | "C" | "D" | "E" | "F" 994 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 996 Many HTTP/1.1 header field values consist of words separated by LWS or 997 special characters. These special characters MUST be in a quoted string 998 to be used within a parameter value. 1000 token = 1* 1001 separators = "(" | ")" | "<" | ">" | "@" 1002 | "," | ";" | ":" | "\" | <"> 1003 | "/" | "[" | "]" | "?" | "=" 1004 | "{" | "}" | SP | HT 1006 A string of text is parsed as a single word if it is quoted using 1007 double-quote marks. 1009 quoted-string = ( <"> qdstr-val <"> ) 1010 qdstr-val = *(qdtext | quoted-pair ) 1011 qdtext = > 1013 The backslash character ("\") MAY be used as a single-character quoting 1014 mechanism only within qdstr-val and comment constructs. 1016 quoted-pair = "\" CHAR 1018 The value of this construct is CHAR. Note that an effect of this rule is 1019 that backslash must be quoted. 1021 8 Sample Code 1023 The sample implementation in [Digest] also applies to DIGEST-MD5. 1025 The following code implements the conversion from UTF-8 to 8859-1 if 1026 necessary. 1028 Digest Authentication as a SASL Mechanism September 1998 1030 /* if the string is entirely in the 8859-1 subset of UTF-8, then 1031 translate 1032 * to 8859-1 prior to MD5 1033 */ 1034 void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, int 1035 len) 1036 { 1037 const unsigned char *scan, *end; 1038 unsigned char cbuf; 1040 end = base + len; 1041 for (scan = base; scan < end; ++scan) { 1042 if (*scan > 0xC3) break; /* abort if outside 8859-1 */ 1043 if (*scan >= 0xC0 && *scan <= 0xC3) { 1044 if (++scan == end || *scan < 0x80 || *scan > 0xBF) 1045 break; 1046 } 1047 } 1048 /* if we found a character outside 8859-1, don't alter string 1049 */ 1050 if (scan < end) { 1051 MD5Update(ctx, base, len); 1052 return; 1053 } 1055 /* convert to 8859-1 prior to applying hash 1056 */ 1057 do { 1058 for (scan = base; scan < end && *scan < 0xC0; ++scan) 1059 ; 1060 if (scan != base) MD5Update(ctx, base, scan - base); 1061 if (scan + 1 >= end) break; 1062 cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f); 1063 MD5Update(ctx, &cbuf, 1); 1064 base = scan + 2; 1065 } while (base < end); 1066 } 1068 9 Full Copyright Statement 1070 Copyright (C) The Internet Society (1998). All Rights Reserved. 1072 This document and translations of it may be copied and furnished to 1073 others, and derivative works that comment on or otherwise explain it or 1074 assist in its implmentation may be prepared, copied, published and 1075 distributed, in whole or in part, without restriction of any kind, 1076 provided that the above copyright notice and this paragraph are included 1077 on all such copies and derivative works. However, this document itself 1078 may not be modified in any way, such as by removing the copyright notice 1079 or references to the Internet Society or other Internet organizations, 1080 except as needed for the purpose of developing Internet standards in 1081 which case the procedures for copyrights defined in the Internet 1082 Digest Authentication as a SASL Mechanism September 1998 1084 Standards process must be followed, or as required to translate it into 1085 languages other than English. 1087 The limited permissions granted above are perpetual and will not be 1088 revoked by the Internet Society or its successors or assigns. 1090 This document and the information contained herein is provided on an "AS 1091 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1092 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1093 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1094 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1095 FITNESS FOR A PARTICULAR PURPOSE.