idnits 2.17.1 draft-ietf-httpauth-digest-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2617, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 221 has weird spacing: '...quality of th...' == Line 253 has weird spacing: '...eturned by th...' == Line 550 has weird spacing: '...ptional clien...' == Line 596 has weird spacing: '...hanging nonce...' == Line 870 has weird spacing: '...ve) are prote...' -- The document date (January 18, 2014) is 3750 days in the past. Is this intentional? 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 section? 'RFC2119' on line 116 looks like a reference -- Missing reference section? '7' on line 198 looks like a reference -- Missing reference section? 'RFC2069' on line 380 looks like a reference -- Missing reference section? 'RFC2616' on line 736 looks like a reference -- Missing reference section? 'SHA3' on line 722 looks like a reference -- Missing reference section? 'RFC3629' on line 821 looks like a reference -- Missing reference section? 'RFC2818' on line 850 looks like a reference -- Missing reference section? '10' on line 858 looks like a reference -- Missing reference section? '9' on line 859 looks like a reference -- Missing reference section? '8' on line 1015 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAuth Working Group R. Shekh-Yusef, Ed. 3 Internet-Draft D. Ahrens 4 Obsoletes: 2617 (if approved) Avaya 5 Intended Status: Standards Track S. Bremer 6 Expires: July 22, 2014 Netzkonform 7 January 18, 2014 9 HTTP Digest Access Authentication 10 draft-ietf-httpauth-digest-02.txt 12 Abstract 14 HTTP provides a simple challenge-response authentication mechanism 15 that may be used by a server to challenge a client request and by a 16 client to provide authentication information. This document defines 17 the HTTP Digest Authentication scheme that may be used with the 18 authentication mechanism. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 4 61 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 4 62 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 4 63 3.2 Representation of Digest Values . . . . . . . . . . . . . . 4 64 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 5 65 3.4 The Authorization Request Header . . . . . . . . . . . . . . 8 66 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 11 67 3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 12 70 3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 12 71 3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 13 72 3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 14 73 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 15 74 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 17 75 3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 17 76 3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 20 78 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20 79 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20 80 5.2 Authentication of Clients using Digest Authentication . . . 20 81 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 21 82 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 83 5.5 Weakness Created by Multiple Authentication Schemes . . . . 22 84 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 23 85 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 23 86 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 24 87 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 24 88 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 25 89 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 25 90 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 25 91 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 94 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27 95 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 97 8.2 Informative References . . . . . . . . . . . . . . . . . . . 27 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 1 Introduction 102 HTTP provides a simple challenge-response authentication mechanism 103 that may be used by a server to challenge a client request and by a 104 client to provide authentication information. This document defines 105 the HTTP Digest Authentication scheme that may be used with the 106 authentication mechanism. 108 The details of the challenge-response authentication mechanism are 109 specified in the [draft-ietf-httpbis-p7-auth-25] document. 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2 Syntax Convention 119 In the interest of clarity and readability, the extended parameters 120 or the headers and parameters in the examples in this document might 121 be broken into multiple lines. Any line that is indented in this 122 document is a continuation of the preceding line. 124 3 Digest Access Authentication Scheme 126 3.1 Overall Operation 128 The Digest scheme is based on a simple challenge-response paradigm. 129 The Digest scheme challenges using a nonce value. A valid response 130 contains a checksum of the username, the password, the given nonce 131 value, the HTTP method, and the requested URI. In this way, the 132 password is never sent in the clear. The username and password must 133 be prearranged in some fashion not addressed by this document. 135 3.2 Representation of Digest Values 137 An optional header allows the server to specify the algorithm used to 138 create the checksum or digest. This documents adds SHA2-256 and SHA2- 139 512/256 algorithms. To maintain backwards compatibility, the MD5 140 algorithm is still supported but not recommended. 142 The size of the digest depends on the algorithm used. The bits in 143 the digest are converted from the most significant to the least 144 significant bit, four bits at a time to the ASCII representation as 145 follows. Each four bits is represented by its familiar hexadecimal 146 notation from the characters 0123456789abcdef, that is binary 0000 is 147 represented by the character '0', 0001 by '1' and so on up to the 148 representation of 1111 as 'f'. If the MD5 algorithm is used to 149 calculate the digest, then the digest will be represented as 32 150 hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal 151 characters. 153 3.3 The WWW-Authenticate Response Header 155 If a server receives a request for an access-protected object, and an 156 acceptable Authorization header is not sent, the server responds with 157 a "401 Unauthorized" status code, and a WWW-Authenticate header as 158 per the framework defined above, which for the digest scheme is 159 utilized as follows. 161 The following defines the scheme and the parameters for the 162 challenge: 164 auth-scheme = "Digest" digest-challenge 166 digest-challenge = 1#( realm | [ domain ] | nonce | 167 [ opaque ] |[ stale ] | [ algorithm ] | 168 [ qop-options ] | [charset] | [userhash] ) 170 domain = "domain" "=" <"> URI ( 1*SP URI ) <"> 171 URI = absoluteURI | abs_path 172 nonce = "nonce" "=" nonce-value 173 nonce-value = quoted-string 174 opaque = "opaque" "=" quoted-string 175 stale = "stale" "=" ( "true" | "false" ) 176 algorithm = "algorithm" "=" ( 177 "MD5" | "MD5-sess" | 178 "SHA2-256" | "SHA2-256-sess" | 179 "SHA2-512-256" | "SHA2-512-256-sess" | 180 token) 181 qop-options = "qop" "=" <"> 1#qop-value <"> 182 qop-value = "auth" | "auth-int" | token 183 charset = "charset" "=" ("UTF-8" | token) 184 userhash = "userhash" "=" ( "true" | "false" ) 186 The meanings of the values of the directives used above are as 187 follows: 189 realm 190 A string to be displayed to users so they know which username and 191 password to use. This string should contain at least the name of 192 the host performing the authentication and might additionally 193 indicate the collection of users who might have access. An example 194 might be "registered_users@gotham.news.com". 196 domain 197 A quoted, space-separated list of URIs, as specified in RFC XURI 198 [7], that define the protection space. If a URI is an abs_path, 199 it is relative to the canonical root URL of the server being 200 accessed. An absoluteURI in this list may refer to a different 201 server than the one being accessed. The client can use this list 202 to determine the set of URIs for which the same authentication 203 information may be sent: any URI that has a URI in this list as a 204 prefix (after both have been made absolute) may be assumed to be 205 in the same protection space. If this directive is omitted or its 206 value is empty, the client should assume that the protection space 207 consists of all URIs on the responding server. 209 This directive is not meaningful in Proxy-Authenticate headers, 210 for which the protection space is always the entire proxy; if 211 present it should be ignored. 213 nonce 214 A server-specified data string which should be uniquely generated 215 each time a 401 response is made. It is recommended that this 216 string be base64 or hexadecimal data. Specifically, since the 217 string is passed in the header lines as a quoted string, the 218 double-quote character is not allowed. 220 The contents of the nonce are implementation dependent. The 221 quality of the implementation depends on a good choice. A nonce 222 might, for example, be constructed as the base 64 encoding of 224 time-stamp H(time-stamp ":" ETag ":" private-key) 226 where time-stamp is a server-generated time or other non-repeating 227 value, ETag is the value of the HTTP ETag header associated with 228 the requested entity, and private-key is data known only to the 229 server. With a nonce of this form a server would recalculate the 230 hash portion after receiving the client authentication header and 231 reject the request if it did not match the nonce from that header 232 or if the time-stamp value is not recent enough. In this way the 233 server can limit the time of the nonce's validity. The inclusion 234 of the ETag prevents a replay request for an updated version of 235 the resource. (Note: including the IP address of the client in the 236 nonce would appear to offer the server the ability to limit the 237 reuse of the nonce to the same client that originally got it. 238 However, that would break proxy farms, where requests from a 239 single user often go through different proxies in the farm. Also, 240 IP address spoofing is not that hard.) 242 An implementation might choose not to accept a previously used 243 nonce or a previously used digest, in order to protect against a 244 replay attack. Or, an implementation might choose to use one-time 245 nonces or digests for POST or PUT requests and a time-stamp for 246 GET requests. For more details on the issues involved see section 247 5 of this document. 249 The nonce is opaque to the client. 251 opaque 252 A string of data, specified by the server, which should be 253 returned by the client unchanged in the Authorization header of 254 subsequent requests with URIs in the same protection space. It is 255 recommended that this string be base64 or hexadecimal data. 257 stale 258 A case-insensitive flag, indicating that the previous request from 259 the client was rejected because the nonce value was stale. If 260 stale is TRUE, the client may wish to simply retry the request 261 with a new encrypted response, without reprompting the user for a 262 new username and password. The server should only set stale to 263 TRUE if it receives a request for which the nonce is invalid but 264 with a valid digest for that nonce (indicating that the client 265 knows the correct username/password). If stale is FALSE, or 266 anything other than TRUE, or the stale directive is not present, 267 the username and/or password are invalid, and new values must be 268 obtained. 270 algorithm 271 A string indicating a pair of algorithms used to produce the 272 digest and a checksum. If this is not present it is assumed to be 273 "MD5". If the algorithm is not understood, the challenge should be 274 ignored (and a different one used, if there is more than one). 276 In this document the string obtained by applying the digest 277 algorithm to the data "data" with secret "secret" will be denoted 278 by KD(secret, data), and the string obtained by applying the 279 checksum algorithm to the data "data" will be denoted H(data). The 280 notation unq(X) means the value of the quoted-string X without the 281 surrounding quotes. 283 For the "MD5" and "MD5-sess" algorithms 285 H(data) = MD5(data) 287 For the "SHA2-256" and "SHA2-256-sess" algorithms 289 H(data) = SHA2-256(data) 291 For the "SHA2-512-256" and "SHA2-512-256-sess" algorithms 293 H(data) = SHA2-512-256(data) 295 and 297 KD(secret, data) = H(concat(secret, ":", data)) 299 i.e., the digest is the MD5 of the secret concatenated with a 300 colon concatenated with the data. The "MD5-sess" algorithm is 301 intended to allow efficient 3rd party authentication servers; 302 for the difference in usage, see the description in section 303 3.4.2. 305 qop-options 306 This directive is optional, but is made so only for backward 307 compatibility with RFC 2069 [RFC2069]; it SHOULD be used by all 308 implementations compliant with this version of the Digest scheme. 309 If present, it is a quoted string of one or more tokens indicating 310 the "quality of protection" values supported by the server. The 311 value "auth" indicates authentication; the value "auth-int" 312 indicates authentication with integrity protection; see the 313 descriptions below for calculating the response directive value 314 for the application of this choice. Unrecognized options MUST be 315 ignored. 317 charset 318 This is an OPTIONAL parameter that is used by the server to 319 indicate the encoding scheme it supports. 321 userhash 322 This is an OPTIONAL parameter that is used by the server to 323 indicate that it supports username hashing. 325 3.4 The Authorization Request Header 327 The client is expected to retry the request, passing an 328 Authorization header line, which is defined according to the 329 framework above, utilized as follows. 331 The following defines the scheme and the parameters for the 332 response: 334 auth-scheme = "Digest" digest-response 335 digest-response = 1#( username | realm | nonce | 336 digest-uri | response | [ algorithm ] | 337 [cnonce] | [opaque] | [message-qop] | 338 [nonce-count] | [charset] | [userhash]) 339 username = "username" "=" username-value 340 username-value = quoted-string 341 digest-uri = "uri" "=" "digest-uri-value" 342 digest-uri-value = request-uri ; As specified by HTTP/1.1 343 message-qop = "qop" "=" qop-value 344 cnonce = "cnonce" "=" cnonce-value 345 cnonce-value = nonce-value 346 nonce-count = "nc" "=" nc-value 347 nc-value = 8LHEX 348 response = "response" "=" request-digest 349 request-digest = <"> *LHEX <"> 350 LHEX = "0" | "1" | "2" | "3" | 351 "4" | "5" | "6" | "7" | 352 "8" | "9" | "a" | "b" | 353 "c" | "d" | "e" | "f" 354 charset = "charset" "=" ("UTF-8" | token) 355 userhash = "userhash" "=" ( "true" | "false" ) 357 The values of the opaque and algorithm fields must be those 358 supplied in the WWW-Authenticate response header for the entity 359 being requested. 361 response 362 A string of the hex digits computed as defined below, which proves 363 that the user knows a password 365 username 366 The user's name in the specified realm. 368 digest-uri 369 The URI from Request-URI of the Request-Line; duplicated here 370 because proxies are allowed to change the Request-Line in transit. 372 qop 373 Indicates what "quality of protection" the client has applied to 374 the message. If present, its value MUST be one of the alternatives 375 the server indicated it supports in the WWW-Authenticate header. 376 These values affect the computation of the request-digest. Note 377 that this is a single token, not a quoted list of alternatives as 378 in WWW-Authenticate. This directive is optional in order to 379 preserve backward compatibility with a minimal implementation of 380 RFC 2069 [RFC2069], but SHOULD be used if the server indicated 381 that qop is supported by providing a qop directive in the WWW- 382 Authenticate header field. 384 cnonce 385 This MUST be specified if a qop directive is sent (see above), and 386 MUST NOT be specified if the server did not send a qop directive 387 in the WWW-Authenticate header field. The cnonce-value is an 388 opaque quoted string value provided by the client and used by both 389 client and server to avoid chosen plaintext attacks, to provide 390 mutual authentication, and to provide some message integrity 391 protection. See the descriptions below of the calculation of the 392 response- digest and request-digest values. 394 nonce-count 395 This MUST be specified if a qop directive is sent (see above), and 396 MUST NOT be specified if the server did not send a qop directive 397 in the WWW-Authenticate header field. The nc-value is the 398 hexadecimal count of the number of requests (including the current 399 request) that the client has sent with the nonce value in this 400 request. For example, in the first request sent in response to a 401 given nonce value, the client sends "nc=00000001". The purpose of 402 this directive is to allow the server to detect request replays by 403 maintaining its own copy of this count - if the same nc-value is 404 seen twice, then the request is a replay. See the description 405 below of the construction of the request-digest value. 407 charset 408 This OPTIONAL parameter is used by the client to indicate the 409 character encoding used for the username and password. 411 userhash 412 This OPTIONAL parameter is used by the client to indicate that the 413 username has been hashed. 415 If a directive or its value is improper, or required directives are 416 missing, the proper response is 400 Bad Request. If the request- 417 digest is invalid, then a login failure should be logged, since 418 repeated login failures from a single client may indicate an attacker 419 attempting to guess passwords. 421 The definition of request-digest above indicates the encoding for its 422 value. The following definitions show how the value is computed. 424 3.4.1 Request-Digest 426 If the "qop" value is "auth" or "auth-int": 428 request-digest = <"> < KD ( H(A1), unq(nonce-value) 429 ":" nc-value 430 ":" unq(cnonce-value) 431 ":" unq(qop-value) 432 ":" H(A2) 433 ) <"> 435 If the "qop" directive is not present (this construction is for 436 compatibility with RFC 2069): 438 request-digest = 439 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> 441 See below for the definitions for A1 and A2. 443 3.4.2 A1 445 If the "algorithm" directive's value is "MD5", "SHA2-256", or "SHA2- 446 512-256", then A1 is: 448 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 450 where 452 passwd = < user's password > 454 If the "algorithm" directive's value is "MD5-sess", "SHA2-256-sess", 455 or "SHA2-512-256-sess", then A1 is calculated only once - on the 456 first request by the client following receipt of a WWW-Authenticate 457 challenge from the server. It uses the server nonce from that 458 challenge, and the first client nonce value to construct A1 as 459 follows: 461 A1 = H( unq(username-value) ":" unq(realm-value) 462 ":" passwd ) 463 ":" unq(nonce-value) ":" unq(cnonce-value) 465 This creates a 'session key' for the authentication of subsequent 466 requests and responses which is different for each "authentication 467 session", thus limiting the amount of material hashed with any one 468 key. (Note: see further discussion of the authentication session in 469 section 3.6.) Because the server need only use the hash of the user 470 credentials in order to create the A1 value, this construction could 471 be used in conjunction with a third party authentication service so 472 that the web server would not need the actual password value. The 473 specification of such a protocol is beyond the scope of this 474 specification. 476 3.4.3 A2 478 If the "qop" directive's value is "auth" or is unspecified, then A2 479 is: 481 A2 = Method ":" digest-uri-value 483 If the "qop" value is "auth-int", then A2 is: 485 A2 = Method ":" digest-uri-value ":" H(entity-body) 487 3.4.4 Username Hashing 489 To protect the transport of the username from the client to the 490 server, the server SHOULD set the "userhash" parameter with the value 491 of "true" in the WWW-Authentication header. 493 If the client supports the "userhash" parameter, and the "userhash" 494 parameter value in the WWW-Authentication header is set to "true", 495 then the client MUST calculate a hash of the username after any other 496 hash calculation and include the "userhash" parameter with the value 497 of "true" in the Authorization Request Header. If the client does not 498 provide the "username" as a hash value or the "userhash" parameter 499 with the value of "true", the server MAY reject the request. 501 The server may change the nonce value, so the client should be ready 502 to recalculate the hashed username. 504 The following is the operation that the client will take to hash the 505 username: 507 username = H( H( username ":" realm ) ":" nonce) 509 3.4.5 Directive Values and Quoted-String 511 Note that the value of many of the directives, such as "username- 512 value", are defined as a "quoted-string". However, the "unq" notation 513 indicates that surrounding quotation marks are removed in forming the 514 string A1. Thus if the Authorization header includes the fields 516 username="Mufasa", realm=myhost@testrealm.com 518 and the user Mufasa has password "Circle Of Life" then H(A1) would be 519 H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks 520 in the digested string. 522 No white space is allowed in any of the strings to which the digest 523 function H() is applied unless that white space exists in the quoted 524 strings or entity body whose contents make up the string to be 525 digested. For example, the string A1 illustrated above must be 527 Mufasa:myhost@testrealm.com:Circle Of Life 529 with no white space on either side of the colons, but with the white 530 space between the words used in the password value. Likewise, the 531 other strings digested by H() must not have white space on either 532 side of the colons which delimit their fields unless that white space 533 was in the quoted strings or entity body being digested. 535 Also note that if integrity protection is applied (qop=auth-int), the 536 H(entity-body) is the hash of the entity body, not the message body - 537 it is computed before any transfer encoding is applied by the sender 538 and after it has been removed by the recipient. Note that this 539 includes multipart boundaries and embedded headers in each part of 540 any multipart content-type. 542 3.4.6 Various Considerations 544 The "Method" value is the HTTP request method as specified in section 545 5.1.1 of [RFC2616]. The "request-uri" value is the Request-URI from 546 the request line as specified in section 5.1.2 of [RFC2616]. This may 547 be "*", an "absoluteURL" or an "abs_path" as specified in section 548 5.1.2 of [RFC2616], but it MUST agree with the Request-URI. In 549 particular, it MUST be an "absoluteURL" if the Request-URI is an 550 "absoluteURL". The "cnonce-value" is an optional client-chosen value 551 whose purpose is to foil chosen plaintext attacks. 553 The authenticating server must assure that the resource designated by 554 the "uri" directive is the same as the resource specified in the 555 Request-Line; if they are not, the server SHOULD return a 400 Bad 556 Request error. (Since this may be a symptom of an attack, server 557 implementers may want to consider logging such errors.) The purpose 558 of duplicating information from the request URL in this field is to 559 deal with the possibility that an intermediate proxy may alter the 560 client's Request-Line. This altered (but presumably semantically 561 equivalent) request would not result in the same digest as that 562 calculated by the client. 564 Implementers should be aware of how authenticated transactions 565 interact with shared caches. The HTTP/1.1 protocol specifies that 566 when a shared cache (see section 13.7 of [RFC2616]) has received a 567 request containing an Authorization header and a response from 568 relaying that request, it MUST NOT return that response as a reply to 569 any other request, unless one of two Cache-Control (see section 14.9 570 of [RFC2616]) directives was present in the response. If the original 571 response included the "must-revalidate" Cache-Control directive, the 572 cache MAY use the entity of that response in replying to a subsequent 573 request, but MUST first revalidate it with the origin server, using 574 the request headers from the new request to allow the origin server 575 to authenticate the new request. Alternatively, if the original 576 response included the "public" Cache-Control directive, the response 577 entity MAY be returned in reply to any subsequent request. 579 3.5 The Authentication-Info Header 581 The Authentication-Info header is used by the server to communicate 582 some information regarding the successful authentication in the 583 response. 585 AuthenticationInfo = "Authentication-Info" ":" auth-info 586 auth-info = 1#(nextnonce | [ message-qop ] 587 | [ response-auth ] | [ cnonce ] 588 | [nonce-count] ) 589 nextnonce = "nextnonce" "=" nonce-value 590 response-auth = "rspauth" "=" response-digest 591 response-digest = <"> *LHEX <"> 593 The value of the nextnonce directive is the nonce the server wishes 594 the client to use for a future authentication response. The server 595 may send the Authentication-Info header with a nextnonce field as a 596 means of implementing one-time or otherwise changing nonces. If the 597 nextnonce field is present the client SHOULD use it when constructing 598 the Authorization header for its next request. Failure of the client 599 to do so may result in a request to re-authenticate from the server 600 with the "stale=TRUE". 602 Server implementations should carefully consider the performance 603 implications of the use of this mechanism; pipelined requests will 604 not be possible if every response includes a nextnonce directive 605 that must be used on the next request received by the server. 606 Consideration should be given to the performance vs. security 607 tradeoffs of allowing an old nonce value to be used for a limited 608 time to permit request pipelining. Use of the nonce-count can 609 retain most of the security advantages of a new server nonce 610 without the deleterious affects on pipelining. 612 message-qop 613 Indicates the "quality of protection" options applied to the 614 response by the server. The value "auth" indicates 615 authentication; the value "auth-int" indicates authentication with 616 integrity protection. The server SHOULD use the same value for the 617 message- qop directive in the response as was sent by the client 618 in the corresponding request. 620 The optional response digest in the "response-auth" directive 621 supports mutual authentication -- the server proves that it knows the 622 user's secret, and with qop=auth-int also provides limited integrity 623 protection of the response. The "response-digest" value is calculated 624 as for the "request-digest" in the Authorization header, except that 625 if "qop=auth" or is not specified in the Authorization header for the 626 request, A2 is 628 A2 = ":" digest-uri-value 630 and if "qop=auth-int", then A2 is 632 A2 = ":" digest-uri-value ":" H(entity-body) 634 where "digest-uri-value" is the value of the "uri" directive on the 635 Authorization header in the request. The "cnonce-value" and "nc- 636 value" MUST be the ones for the client request to which this message 637 is the response. The "response-auth", "cnonce", and "nonce-count" 638 directives MUST BE present if "qop=auth" or "qop=auth-int" is 639 specified. 641 The Authentication-Info header is allowed in the trailer of an HTTP 642 message transferred via chunked transfer-coding. 644 3.6 Digest Operation 646 Upon receiving the Authorization header, the server may check its 647 validity by looking up the password that corresponds to the submitted 648 username. Then, the server must perform the same digest operation 649 (e.g., MD5) performed by the client, and compare the result to the 650 given request-digest value. 652 Note that the HTTP server does not actually need to know the user's 653 cleartext password. As long as H(A1) is available to the server, the 654 validity of an Authorization header may be verified. 656 The client response to a WWW-Authenticate challenge for a protection 657 space starts an authentication session with that protection space. 658 The authentication session lasts until the client receives another 659 WWW-Authenticate challenge from any server in the protection space. A 660 client should remember the username, password, nonce, nonce count and 661 opaque values associated with an authentication session to use to 662 construct the Authorization header in future requests within that 663 protection space. The Authorization header may be included 664 preemptively; doing so improves server efficiency and avoids extra 665 round trips for authentication challenges. The server may choose to 666 accept the old Authorization header information, even though the 667 nonce value included might not be fresh. Alternatively, the server 668 may return a 401 response with a new nonce value, causing the client 669 to retry the request; by specifying stale=TRUE with this response, 670 the server tells the client to retry with the new nonce, but without 671 prompting for a new username and password. 673 Because the client is required to return the value of the opaque 674 directive given to it by the server for the duration of a session, 675 the opaque data may be used to transport authentication session state 676 information. (Note that any such use can also be accomplished more 677 easily and safely by including the state in the nonce.) For example, 678 a server could be responsible for authenticating content that 679 actually sits on another server. It would achieve this by having the 680 first 401 response include a domain directive whose value includes a 681 URI on the second server, and an opaque directive whose value 682 contains the state information. The client will retry the request, at 683 which time the server might respond with a 301/302 redirection, 684 pointing to the URI on the second server. The client will follow the 685 redirection, and pass an Authorization header , including the 686 data. 688 As with the basic scheme, proxies must be completely transparent in 689 the Digest access authentication scheme. That is, they must forward 690 the WWW-Authenticate, Authentication-Info and Authorization headers 691 untouched. If a proxy wants to authenticate a client before a request 692 is forwarded to the server, it can be done using the Proxy- 693 Authenticate and Proxy-Authorization headers described in section 3.6 694 below. 696 3.7 Security Protocol Negotiation 698 It is useful for a server to be able to know which security schemes a 699 client is capable of handling. 701 It is possible that a server may want to require Digest as its 702 authentication method, even if the server does not know that the 703 client supports it. A client is encouraged to fail gracefully if the 704 server specifies only authentication schemes it cannot handle. 706 When a server receives a request to access a resource, the server 707 might challenge the client by responding with "401 Unauthorized" 708 status code, and include one or more WWW-Authenticate headers. If the 709 server challenges with multiple Digest headers, then each one of 710 these headers MUST use a different digest algorithm. The server MUST 711 add these Digest headers to the response in order of preference, 712 starting with the most preferred header, followed by the less 713 preferred headers. 715 This specification defines the following preference list, starting 716 with the most preferred algorithm: 718 * SHA2-256. 719 * SHA2-512/256. 720 * MD5 (for backward compatibility). 722 A future version of this document might add SHA3 [SHA3] as a backup 723 algorithm, once its definition has been finalized and published. 725 When the client receives the response it SHOULD use the topmost 726 header that it supports, unless a local policy dictates otherwise. 727 The client should ignore any challenge it does not understand. 729 3.8 Proxy-Authentication and Proxy-Authorization 731 The digest authentication scheme may also be used for authenticating 732 users to proxies, proxies to proxies, or proxies to origin servers by 733 use of the Proxy-Authenticate and Proxy-Authorization headers. These 734 headers are instances of the Proxy-Authenticate and Proxy- 735 Authorization headers specified in sections 10.33 and 10.34 of the 736 HTTP/1.1 specification [RFC2616] and their behavior is subject to 737 restrictions described there. The transactions for proxy 738 authentication are very similar to those already described. Upon 739 receiving a request which requires authentication, the proxy/server 740 must issue the "407 Proxy Authentication Required" response with a 741 "Proxy-Authenticate" header. The digest-challenge used in the Proxy- 742 Authenticate header is the same as that for the WWW- Authenticate 743 header as defined above in section 3.2.1. 745 The client/proxy must then re-issue the request with a Proxy- 746 Authorization header, with directives as specified for the 747 Authorization header in section 3.4 above. 749 On subsequent responses, the server sends Proxy-Authentication-Info 750 with directives the same as those for the Authentication-Info header 751 field. 753 Note that in principle a client could be asked to authenticate itself 754 to both a proxy and an end-server, but never in the same response. 756 3.9 Example 758 The following example assumes that an access protected document is 759 being requested from the server via a GET request. The URI of the 760 document is http://www.nowhere.org/dir/index.html". Both client and 761 server know that the username for this document is "Mufasa" and the 762 password is "Circle of Life" ( with one space between each of the 763 three words). 765 The first time the client requests the document, no Authorization 766 header is sent, so the server responds with: 768 HTTP/1.1 401 Unauthorized 769 WWW-Authenticate: Digest 770 realm = "testrealm@host.com", 771 qop="auth, auth-int", 772 algorithm="SHA2-256", 773 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 774 opaque="5ccc069c403ebaf9f0171e9517f40e41" 775 WWW-Authenticate: Digest 776 realm="testrealm@host.com", 777 qop="auth, auth-int", 778 algorithm="MD5", 779 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 780 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 782 The client may prompt the user for their username and password, after 783 which it will respond with a new request, including the following 784 Authorization header if the client chooses MD5 digest: 786 Authorization:Digest username="Mufasa", 787 realm="testrealm@host.com", 788 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 789 uri="/dir/index.html", 790 qop="auth", 791 algorithm="MD5", 792 nc=00000001, 793 cnonce="0a4f113b", 794 response="6629fae49393a05397450978507c4ef1", 795 opaque="5ccc069c403ebaf9f0171e9517f40e41" 797 If the client chooses to use the SHA2-256 algorithm for calculating 798 the response, the client responds with a new request including the 799 following Authorization header: 801 Authorization:Digest username="Mufasa", 802 realm="testrealm@host.com", 803 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 804 uri="/dir/index.html", 805 qop="auth", 806 algorithm="SHA2-256", 807 nc=00000001, 808 cnonce="0a4f113b", 809 response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93 810 a59b630c13dfe0a5dc6e38b", 811 opaque="5ccc069c403ebaf9f0171e9517f40e41" 813 4 Internationalization 815 In challenges, servers SHOULD use the "charset" authentication 816 parameter (case-insensitive) to express the character encoding they 817 expect the user agent to use. 819 The only allowed value is "UTF-8", to be matched case-insensitively, 820 indicating that the server expects the UTF-8 character encoding to be 821 used ([RFC3629]). 823 If the user agent supports the encoding indicated by the server, it 824 MAY add the "charset" parameter, with the value it received from the 825 server, to the Proxy-Authenticate or WWW-Authenticate header fields 826 it sends back to the server. 828 If the user agent does not support the encoding indicated by the 829 server, it MAY add the "charset" parameter to the Proxy-Authenticate 830 or WWW-Authenticate header fields it sends back to the server, but 831 the value in the parameter should be preceded by an exclamation point 832 (!). 834 5 Security Considerations 836 5.1 Limitations 838 HTTP Digest authentication, when used with human-memorable passwords, 839 is vulnerable to dictionary attacks. Such attacks are much easier 840 than cryptographic attacks on any widely used algorithm, including 841 those that are no longer considered secure. In other words, algorithm 842 agility does not make this usage any more secure. 844 As a result, Digest authentication SHOULD be used only with passwords 845 that have a reasonable amount of entropy, e.g. 128-bit or more. Such 846 passwords typically cannot be memorized by humans but can be used for 847 automated web services. 849 Digest authentication SHOULD be used over a secure channel like HTTPS 850 [RFC2818]. 852 5.2 Authentication of Clients using Digest Authentication 854 Digest Authentication does not provide a strong authentication 855 mechanism, when compared to public key based mechanisms, for example. 857 However, it is significantly stronger than (e.g.) CRAM-MD5, which has 858 been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 859 [9]). It is intended to replace the much weaker and even more 860 dangerous Basic mechanism. 862 Digest Authentication offers no confidentiality protection beyond 863 protecting the actual username and password. All of the rest of the 864 request and response are available to an eavesdropper. 866 Digest Authentication offers only limited integrity protection for 867 the messages in either direction. If qop=auth-int mechanism is used, 868 those parts of the message used in the calculation of the WWW- 869 Authenticate and Authorization header field response directive values 870 (see section 3.2 above) are protected. Most header fields and their 871 values could be modified as a part of a man-in-the-middle attack. 873 Many needs for secure HTTP transactions cannot be met by Digest 874 Authentication. For those needs TLS or SHTTP are more appropriate 875 protocols. In particular Digest authentication cannot be used for any 876 transaction requiring confidentiality protection. Nevertheless many 877 functions remain for which Digest authentication is both useful and 878 appropriate. 880 5.3 Limited Use Nonce Values 882 The Digest scheme uses a server-specified nonce to seed the 883 generation of the request-digest value (as specified in section 884 3.2.2.1 above). As shown in the example nonce in section 3.2.1, the 885 server is free to construct the nonce such that it may only be used 886 from a particular client, for a particular resource, for a limited 887 period of time or number of uses, or any other restrictions. Doing 888 so strengthens the protection provided against, for example, replay 889 attacks (see 4.5). However, it should be noted that the method 890 chosen for generating and checking the nonce also has performance and 891 resource implications. For example, a server may choose to allow 892 each nonce value to be used only once by maintaining a record of 893 whether or not each recently issued nonce has been returned and 894 sending a next-nonce directive in the Authentication-Info header 895 field of every response. This protects against even an immediate 896 replay attack, but has a high cost checking nonce values, and perhaps 897 more important will cause authentication failures for any pipelined 898 requests (presumably returning a stale nonce indication). Similarly, 899 incorporating a request-specific element such as the Etag value for a 900 resource limits the use of the nonce to that version of the resource 901 and also defeats pipelining. Thus it may be useful to do so for 902 methods with side effects but have unacceptable performance for those 903 that do not. 905 5.4 Replay Attacks 907 A replay attack against Digest authentication would usually be 908 pointless for a simple GET request since an eavesdropper would 909 already have seen the only document he could obtain with a replay. 910 This is because the URI of the requested document is digested in the 911 client request and the server will only deliver that document. By 912 contrast under Basic Authentication once the eavesdropper has the 913 user's password, any document protected by that password is open to 914 him. 916 Thus, for some purposes, it is necessary to protect against replay 917 attacks. A good Digest implementation can do this in various ways. 918 The server created "nonce" value is implementation dependent, but if 919 it contains a digest of the client IP, a time-stamp, the resource 920 ETag, and a private server key (as recommended above) then a replay 921 attack is not simple. An attacker must convince the server that the 922 request is coming from a false IP address and must cause the server 923 to deliver the document to an IP address different from the address 924 to which it believes it is sending the document. An attack can only 925 succeed in the period before the time-stamp expires. Digesting the 926 client IP and time-stamp in the nonce permits an implementation which 927 does not maintain state between transactions. 929 For applications where no possibility of replay attack can be 930 tolerated the server can use one-time nonce values which will not be 931 honored for a second use. This requires the overhead of the server 933 remembering which nonce values have been used until the nonce time- 934 stamp (and hence the digest built with it) has expired, but it 935 effectively protects against replay attacks. 937 An implementation must give special attention to the possibility of 938 replay attacks with POST and PUT requests. Unless the server employs 939 one-time or otherwise limited-use nonces and/or insists on the use of 940 the integrity protection of qop=auth-int, an attacker could replay 941 valid credentials from a successful request with counterfeit form 942 data or other message body. Even with the use of integrity protection 943 most metadata in header fields is not protected. Proper nonce 944 generation and checking provides some protection against replay of 945 previously used valid credentials, but see 4.8. 947 5.5 Weakness Created by Multiple Authentication Schemes 949 An HTTP/1.1 server may return multiple challenges with a 401 950 (Authenticate) response, and each challenge may use a different auth- 951 scheme. A user agent MUST choose to use the strongest auth- scheme it 952 understands and request credentials from the user based upon that 953 challenge. 955 Note that many browsers will only recognize Basic and will require 956 that it be the first auth-scheme presented. Servers should only 957 include Basic if it is minimally acceptable. 959 When the server offers choices of authentication schemes using the 960 WWW-Authenticate header, the strength of the resulting authentication 961 is only as good as that of the of the weakest of the authentication 962 schemes. See section 5.7 below for discussion of particular attack 963 scenarios that exploit multiple authentication schemes. 965 5.6 Online dictionary attacks 967 If the attacker can eavesdrop, then it can test any overheard 968 nonce/response pairs against a list of common words. Such a list is 969 usually much smaller than the total number of possible passwords. The 970 cost of computing the response for each password on the list is paid 971 once for each challenge. 973 The server can mitigate this attack by not allowing users to select 974 passwords that are in a dictionary. 976 5.7 Man in the Middle 978 Both Basic and Digest authentication are vulnerable to "man in the 979 middle" (MITM) attacks, for example, from a hostile or compromised 980 proxy. Clearly, this would present all the problems of eavesdropping. 981 But it also offers some additional opportunities to the attacker. 983 A possible man-in-the-middle attack would be to add a weak 984 authentication scheme to the set of choices, hoping that the client 985 will use one that exposes the user's credentials (e.g. password). For 986 this reason, the client should always use the strongest scheme that 987 it understands from the choices offered. 989 An even better MITM attack would be to remove all offered choices, 990 replacing them with a challenge that requests only Basic 991 authentication, then uses the cleartext credentials from the Basic 992 authentication to authenticate to the origin server using the 993 stronger scheme it requested. A particularly insidious way to mount 994 such a MITM attack would be to offer a "free" proxy caching service 995 to gullible users. 997 User agents should consider measures such as presenting a visual 998 indication at the time of the credentials request of what 999 authentication scheme is to be used, or remembering the strongest 1000 authentication scheme ever requested by a server and produce a 1001 warning message before using a weaker one. It might also be a good 1002 idea for the user agent to be configured to demand Digest 1003 authentication in general, or from specific sites. 1005 Or, a hostile proxy might spoof the client into making a request the 1006 attacker wanted rather than one the client wanted. Of course, this is 1007 still much harder than a comparable attack against Basic 1008 Authentication. 1010 5.8 Chosen plaintext attacks 1012 With Digest authentication, a MITM or a malicious server can 1013 arbitrarily choose the nonce that the client will use to compute the 1014 response. This is called a "chosen plaintext" attack. The ability to 1015 choose the nonce is known to make cryptanalysis much easier [8]. 1017 However, no way to analyze the MD5 one-way function used by Digest 1018 using chosen plaintext is currently known. 1020 The countermeasure against this attack is for clients to be 1021 configured to require the use of the optional "cnonce" directive; 1022 this allows the client to vary the input to the hash in a way not 1023 chosen by the attacker. 1025 5.9 Precomputed dictionary attacks 1027 With Digest authentication, if the attacker can execute a chosen 1028 plaintext attack, the attacker can precompute the response for many 1029 common words to a nonce of its choice, and store a dictionary of 1030 (response, password) pairs. Such precomputation can often be done in 1031 parallel on many machines. It can then use the chosen plaintext 1032 attack to acquire a response corresponding to that challenge, and 1033 just look up the password in the dictionary. Even if most passwords 1034 are not in the dictionary, some might be. Since the attacker gets to 1035 pick the challenge, the cost of computing the response for each 1036 password on the list can be amortized over finding many passwords. A 1037 dictionary with 100 million password/response pairs would take about 1038 3.2 gigabytes of disk storage. 1040 The countermeasure against this attack is to for clients to be 1041 configured to require the use of the optional "cnonce" directive. 1043 5.10 Batch brute force attacks 1045 With Digest authentication, a MITM can execute a chosen plaintext 1046 attack, and can gather responses from many users to the same nonce. 1047 It can then find all the passwords within any subset of password 1048 space that would generate one of the nonce/response pairs in a single 1049 pass over that space. It also reduces the time to find the first 1050 password by a factor equal to the number of nonce/response pairs 1051 gathered. This search of the password space can often be done in 1052 parallel on many machines, and even a single machine can search large 1053 subsets of the password space very quickly -- reports exist of 1054 searching all passwords with six or fewer letters in a few hours. 1056 The countermeasure against this attack is to for clients to be 1057 configured to require the use of the optional "cnonce" directive. 1059 5.11 Spoofing by Counterfeit Servers 1061 Basic Authentication is vulnerable to spoofing by counterfeit 1062 servers. If a user can be led to believe that she is connecting to a 1063 host containing information protected by a password she knows, when 1064 in fact she is connecting to a hostile server, then the hostile 1065 server can request a password, store it away for later use, and feign 1066 an error. This type of attack is more difficult with Digest 1067 Authentication -- but the client must know to demand that Digest 1068 authentication be used, perhaps using some of the techniques 1069 described above to counter "man-in-the-middle" attacks. Again, the 1070 user can be helped in detecting this attack by a visual indication of 1071 the authentication mechanism in use with appropriate guidance in 1072 interpreting the implications of each scheme. 1074 5.12 Storing passwords 1076 Digest authentication requires that the authenticating agent (usually 1077 the server) store some data derived from the user's name and password 1078 in a "password file" associated with a given realm. Normally this 1079 might contain pairs consisting of username and H(A1), where H(A1) is 1080 the digested value of the username, realm, and password as described 1081 above. 1083 The security implications of this are that if this password file is 1084 compromised, then an attacker gains immediate access to documents on 1085 the server using this realm. Unlike, say a standard UNIX password 1086 file, this information need not be decrypted in order to access 1087 documents in the server realm associated with this file. On the other 1088 hand, decryption, or more likely a brute force attack, would be 1089 necessary to obtain the user's password. This is the reason that the 1090 realm is part of the digested data stored in the password file. It 1091 means that if one Digest authentication password file is compromised, 1092 it does not automatically compromise others with the same username 1093 and password (though it does expose them to brute force attack). 1095 There are two important security consequences of this. First the 1096 password file must be protected as if it contained unencrypted 1097 passwords, because for the purpose of accessing documents in its 1098 realm, it effectively does. 1100 A second consequence of this is that the realm string should be 1101 unique among all realms which any single user is likely to use. In 1102 particular a realm string should include the name of the host doing 1103 the authentication. The inability of the client to authenticate the 1104 server is a weakness of Digest Authentication. 1106 5.13 Summary 1108 By modern cryptographic standards Digest Authentication is weak. But 1109 for a large range of purposes it is valuable as a replacement for 1110 Basic Authentication. It remedies some, but not all, weaknesses of 1111 Basic Authentication. Its strength may vary depending on the 1112 implementation. In particular the structure of the nonce (which is 1113 dependent on the server implementation) may affect the ease of 1114 mounting a replay attack. A range of server options is appropriate 1115 since, for example, some implementations may be willing to accept the 1116 server overhead of one-time nonces or digests to eliminate the 1117 possibility of replay. Others may satisfied with a nonce like the one 1118 recommended above restricted to a single IP address and a single ETag 1119 or with a limited lifetime. 1121 The bottom line is that *any* compliant implementation will be 1122 relatively weak by cryptographic standards, but *any* compliant 1123 implementation will be far superior to Basic Authentication. 1125 6 IANA Considerations 1127 This specification creates a new IANA registry named "HTTP Digest 1128 Hash Algorithms". When registering a new hash algorithm, the 1129 following information MUST be provided: 1131 o Hash Algorithm 1132 The textual name of the hash algorithm. 1134 o Digest Size 1135 The size of the algorithm's output in hexadecimal characters. 1137 o Preference 1138 The preference of the algorithm, with zero being the least 1139 preferred. 1141 o Reference 1142 A reference to the specification that describes the new algorithm. 1144 The update policy for this registry shall be Specification Required. 1146 The initial registry will contain the following entries: 1148 Hash Algorithm Digest Size Preference Reference 1149 -------------- ----------- ---------- --------- 1150 "MD5" 32 0 RFC XXXX 1151 "SHA2-256" 64 1 RFC XXXX 1152 "SHA2-512-256" 64 2 RFC XXXX 1154 Each one of the algorithms defined in the registry might have a -sess 1155 variant, e.g. MD5-sess, SHA2-256-sess, etc. 1157 7 Acknowledgments 1159 TODO 1161 8 References 1163 TODO 1165 8.1 Normative References 1167 8.2 Informative References 1168 Authors' Addresses 1170 Rifaat Shekh-Yusef (Editor) 1171 Avaya 1172 250 Sydney Street 1173 Belleville, Ontario 1174 Canada 1176 Phone: +1-613-967-5267 1177 Email: rifaat.ietf@gmail.com 1179 David Ahrens 1180 Avaya 1181 California 1182 USA 1184 EMail: ahrensdc@gmail.com 1186 Sophie Bremer 1187 Netzkonform 1188 Germany 1190 Email: sophie.bremer@netzkonform.de