idnits 2.17.1 draft-smith-sipping-auth-examples-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1203. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1210), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 20 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 136: '... the qop-options MUST be surrounded by...' RFC 2119 keyword, line 138: '... qop-value and MUST NOT be surrounde...' RFC 2119 keyword, line 231: '... transaction and SHOULD have the same ...' RFC 2119 keyword, line 246: '... Nonces SHOULD NOT be generated base...' RFC 2119 keyword, line 322: '... with RFC2617 [3], implementations SHOULD provide a qop-options field....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6889 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? '2' on line 42 looks like a reference -- Missing reference section? '3' on line 1089 looks like a reference -- Missing reference section? '4' on line 98 looks like a reference -- Missing reference section? '5' on line 264 looks like a reference -- Missing reference section? '1' on line 225 looks like a reference -- Missing reference section? '6' on line 324 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sipping 3 Internet Draft Paul D.Smith 4 Expires: November 2005 Data Connection Ltd 5 Ian Clarkson 6 Data Connection Ltd 7 June 2005 9 Digest Authentication Examples for Session Initiation Protocol (SIP) 10 draft-smith-sipping-auth-examples-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire in November, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 RFC3261 [2] recommends that SIP requests be authenticated using HTTP 43 Digest authentication as defined in RFC2617 [3], and many vendors 44 have successfully added this function to their products. However 45 implementation bugs are still being observed both at interoperability 46 events and in the field. 48 This document provides worked examples of Digest authentication usage 49 in SIP. It is intended to help new SIP implementers, and to provide 50 a common set of test authentication examples against which an 51 implementation may be checked. 53 Table of Contents 55 1. Introduction...................................................3 56 2. Common Mistakes................................................3 57 2.1 Quotation marks in Quality-of-protection (QOP) Description..3 58 2.2 Absent QOP and qop=auth result in different digests.........5 59 2.3 Invalid validation of a nonce...............................6 60 3. Worked Examples................................................7 61 3.1 Algorithm and QOP not specified.............................8 62 3.1.1 Challenge...............................................8 63 3.1.2 Authenticated Request...................................8 64 3.1.3 Digest Generation Process...............................9 65 3.2 auth and algorithm unspecified (MD5 assumed)...............11 66 3.2.1 Challenge..............................................11 67 3.2.2 Authenticated Request..................................11 68 3.2.3 Digest Generation Process..............................12 69 3.3 auth and MD5...............................................14 70 3.3.1 Challenge..............................................14 71 3.3.2 Authenticated Request..................................14 72 3.3.3 Digest Generation Process..............................15 73 3.4 auth and MD5-Sess..........................................17 74 3.4.1 Challenge..............................................17 75 3.4.2 Authenticated Request..................................17 76 3.4.3 Digest Generation Process..............................18 77 3.5 auth-int and MD5...........................................20 78 3.5.1 Challenge..............................................20 79 3.5.2 Authenticated Request..................................20 80 3.5.3 Digest Generation Process..............................21 81 3.6 auth-int and MD5-Sess......................................24 82 3.6.1 Challenge..............................................24 83 3.6.2 Authenticated Request..................................24 84 3.6.3 Digest Generation Process..............................25 85 4. Changes.......................................................27 86 4.1 Changes since draft-smith-sip-auth-digest-00...............27 87 4.2 Changes since draft-smith-sipping-auth-digest-00...........27 88 Security Considerations..........................................28 89 IANA Considerations..............................................28 90 Normative References.............................................28 91 Informative References...........................................28 92 Acknowledgments..................................................28 93 Authors' Addresses...............................................29 95 Conventions used in this document 96 The key words "MUST", "MUST NOT" and "SHOULD NOT" in this document 97 should be interpreted as described in RFC2119 [4]. 99 This document uses the representations introduced in 100 draft-ietf-sipping-torture-tests [5] to specify the input and output 101 from cryptographic operations. 103 1. Introduction 105 This document performs two tasks. Firstly, it describes three common 106 problems encountered with Digest authentication usage in SIP 107 implementations. Secondly, it provides SIP implementers with a set 108 of Digest authentication examples, complete with checkpoints, for the 109 various stages of the Digest calculations. These examples can be 110 used to test and prove implementations. 112 This document does not comment on the benefits or deficiencies of 113 HTTP Digest authentication compared to other possible authentication 114 schemes. 116 Similarly, HTTP Basic authentication is deprecated from SIP by 117 RFC3261 [1] so is not covered by this document. 119 It is assumed that the reader is familiar with RFC3261 [1] and 120 RFC2617 [3]. 122 2. Common Mistakes 124 2.1 Quotation marks in Quality-of-protection (QOP) Description 126 In typical SIP usage, the Quality-of-Protection (QOP) indicates 127 whether the authentication digest includes a hash of the body of the 128 SIP message or just the name and password of the caller. 130 A challenging UAS may indicate which of these QOP options is 131 supported by returning a list of permitted QOPs through the 132 qop-options field of a challenge. The requesting UAC then chooses 133 one of these QOPs and indicates which it has chosen through the 134 message-qop field of the credentials. However, since the qop-options 135 in a challenge consists of a comma separated list, the qop-value(s) 136 associated with the qop-options MUST be surrounded by double-quotes. 137 The message-qop in the resulting credentials consists of a single 138 qop-value and MUST NOT be surrounded by double-quotes. 140 Examples of "double-quotes in credentials" and "missing double-quotes 141 in challenges", both of which are invalid, have been observed. 143 The ABNF in RFC2617 [3] that specifies this syntax is reproduced 144 here. The challenge contains a qop-options, and the qop-values are 145 surrounded by double-quotes. Note that this is true even if only a 146 single qop-value is specified. 148 challenge = "Digest" digest-challenge 150 digest-challenge = 1#( realm | [ domain ] | nonce | 151 [ opaque ] |[ stale ] | [ algorithm ] | 152 [ qop-options ] | [auth-param] ) 154 qop-options = "qop" "=" <"> 1#qop-value <"> 155 qop-value = "auth" | "auth-int" | token 157 The credentials contain a single message-qop value which is not 158 surrounded by double quotes. 160 credentials = "Digest" digest-response 161 digest-response = 1#( username | realm | nonce | digest-uri | 162 response | [ algorithm ] | [cnonce] | 163 [opaque] | [message-qop] | 164 [nonce-count] | [auth-param] ) 166 message-qop = "qop" "=" qop-value 168 The following examples, taken from RFC3261 [1], display this subtle 169 point. The WWW-Authenticate header is an example of a challenge, 170 whilst the Authorization header is an example of credentials. 172 WWW-Authenticate: Digest 173 realm="biloxi.com", 174 qop="auth,auth-int", 175 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 176 opaque="5ccc069c403ebaf9f0171e9517f40e41" 178 Authorization: Digest username="bob", 179 realm="biloxi.com", 180 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 181 uri="sip:bob@biloxi.com", 182 qop=auth, 183 nc=00000001, 184 cnonce="0a4f113b", 185 response="6629fae49393a05397450978507c4ef1", 186 opaque="5ccc069c403ebaf9f0171e9517f40e41" 188 2.2 Absent QOP and qop=auth result in different digests 190 Another common mistake arises from the following part of RFC2617 [3]. 192 If the "qop" value is "auth" or "auth-int": 194 request-digest = <"> < KD ( H(A1), unq(nonce-value) 195 ":" nc-value 196 ":" unq(cnonce-value) 197 ":" unq(qop-value) 198 ":" H(A2) ) > 199 <"> 201 If the "qop" directive is not present (this construction is for 202 compatibility with RFC 2069): 204 request-digest = 205 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > 206 <"> 208 Although the values for A1 and A2 are the same regardless of whether 209 the "qop" directive is unspecified or auth, the Digest is different. 211 2.3 Invalid validation of a nonce 213 It has been observed that some implementations create, and then 214 attempt to validate, nonces based on the contents of the request that 215 has been challenged. This causes implementation problems where the 216 partner does not maintain certain SIP header fields between the 217 original and later, authenticated, request. 219 RFC 3261 does not specify a mechanism for creating a nonce for use in 220 an authentication challenge. An implementation is free to generate a 221 nonce in whichever way it sees fit and may choose to do so such that 222 it may be validated and stale nonces detected to avoid replay 223 attacks. 225 RFC3261 [1] section 8.1.3.5 describes how to act on receipt of a 4XX 226 class response, including 401 and 407 challenges, and states the 227 following: 229 In all of the above cases, the request is retried by creating a 230 new request with the appropriate modifications. This new request 231 constitutes a new transaction and SHOULD have the same value of 232 the Call-ID, To, and From of the previous request, but the CSeq 233 should contain a new sequence number that is one higher than the 234 previous. 236 This has been interpreted by some implementations to mean that an 237 authenticated request can be relied upon to always contain the same 238 Call-ID, To and From as the previous request. However this 239 assumption is wrong in the case of dialog creating requests. 241 If an initial dialog creating request fails, the dialog has ended. 242 Reusing the same Call-ID and From tag appears to indicate that the 243 dialog is expected to still exist. It does not and thus reuse of the 244 same Call-ID and From tag should not be assumed. 246 Nonces SHOULD NOT be generated based on information such as the Call- 247 ID and tags unless a dialog has successfully been established and the 248 request is therefore in-dialog. 250 3. Worked Examples 252 This chapter gives worked examples of challenges and the resulting 253 authorized requests using the various combinations of QOP and 254 algorithm options defined in RFC2617 [3]. 256 For each worked example, each phase of the generation of the request- 257 dialog, the value assigned to the "response" parameter of the 258 Authorization header, is presented. These examples, and the 259 checkpoint values, may be used to test and prove new SIP 260 implementations using Digest authentication. 262 In order to remove any doubt regarding possible whitespace, the first 263 example shows key values both using plain text and also the 264 representation [5]. 266 For each example, it may be assumed that a similar, but unauthorized, 267 INVITE has been issued previously which the UAS has challenged. 269 Many SIP header fields that are not pertinent to the explanation of 270 the digest calculation have been omitted for clarity. 272 Finally, it should be noted that in all cases, Bob's password is: 274 zanzibar 276 or 278 7a616e7a69626172 280 3.1 Algorithm and QOP not specified 282 3.1.1 Challenge 284 SIP/2.0 401 Unauthorized 285 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen 286 From: Bob ;tag=9483056782 287 To: Alice ;tag=1928301774 288 Call-ID: a84b4c76e66710 289 CSeq: 314159 INVITE 290 WWW-Authenticate: Digest 291 realm="biloxi.com", 292 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 293 opaque="5ccc069c403ebaf9f0171e9517f40e41" 294 Content-Length: 0 296 3.1.2 Authenticated Request 298 INVITE sip:alice@atlanta.com.com SIP/2.0 299 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 300 Max-Forwards: 70 301 From: Bob 302 To: Alice ;tag=8493745023 303 Call-ID: ab734d9e6b793b 304 CSeq: 83952 INVITE 305 Contact: 306 Authorization: Digest username="bob", 307 realm="biloxi.com", 308 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 309 uri="sip:bob@biloxi.com", 310 nc=00000001, 311 cnonce="0a4f113b", 312 response="bf57e4e0d0bffc0fbaedce64d59add5e", 313 opaque="5ccc069c403ebaf9f0171e9517f40e41" 314 Content-Type: application/sdp 315 Content-Length: 142 317 (Alice's SDP not shown) 319 3.1.3 Digest Generation Process 321 The challenge contains no QOP information. In order to be compliant 322 with RFC2617 [3], implementations SHOULD provide a qop-options field. 323 This field is only optional in RFC2617 [3] for back-compatibility 324 with RFC2069 [6]. 326 However implementations may choose to handle this challenge in order 327 to provide maximum chance of interoperating against other 328 implementations. 330 Given the absence of both algorithm and QOP, RFC2617 [3] defines A1 331 as: 333 If the "algorithm" directive's value is "MD5" or is unspecified, 334 then 336 A1 is: 338 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 340 where 342 passwd = < user's password > 344 This value of A1 is: 346 bob:biloxi.com:zanzibar 348 or 350 626f623a62696c6f78692e636f6d3a7a616e7a69626172 352 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the 353 following value: 355 12af60467a33e8518da5c68bbff12b11 357 From RFC2617 [3], A2 is defined as: 359 If the "qop" directive's value is "auth" or is unspecified, then 360 A2 is: 362 A2 = Method ":" digest-uri-value 364 The value of A2 is 366 INVITE:sip:bob@biloxi.com 368 or 370 494e564954453a7369703a626f624062696c6f78692e636f6d 372 H(A2) then has value: 374 13a14a3eb5e2c24732a1a04fff543e92 376 Finally, the Digest is given by the following: 378 If the "qop" directive is not present (this construction is for 379 compatibility with RFC 2069): 381 request-digest = 382 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > 383 <"> 385 H(A1) and H(A2) have been calculated above. The nonce-value is 386 provided by the server in the challenge. 388 From the definition of KD given in RFC2617 [3] it follows that the 389 request-digest has value 391 <"> H(12af60467a33e8518da5c68bbff12b11: 392 dcd98b7102dd2f0e8b11d0f600bfb0c093: 393 13a14a3eb5e2c24732a1a04fff543e92) <"> 395 or 397 <"> H(313261663630343637613333653835313864613563363862626666 398 31326231313a646364393862373130326464326630653862313164 399 306636303062666230633039333a31336131346133656235653263 400 32343733326131613034666666353433653932) <"> 402 This results in a final value of: 404 Digest = "bf57e4e0d0bffc0fbaedce64d59add5e" 406 3.2 auth and algorithm unspecified (MD5 assumed) 408 3.2.1 Challenge 410 SIP/2.0 401 Unauthorized 411 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen 412 From: Bob ;tag=9483056782 413 To: Alice ;tag=1928301774 414 Call-ID: a84b4c76e66710 415 CSeq: 314159 INVITE 416 WWW-Authenticate: Digest 417 realm="biloxi.com", 418 qop="auth,auth-int", 419 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 420 opaque="5ccc069c403ebaf9f0171e9517f40e41" 421 Content-Length: 0 423 3.2.2 Authenticated Request 425 INVITE sip:alice@atlanta.com.com SIP/2.0 426 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 427 Max-Forwards: 70 428 From: Bob 429 To: Alice ;tag=8493745023 430 Call-ID: ab734d9e6b793b 431 CSeq: 83952 INVITE 432 Contact: 433 Authorization: Digest username="bob", 434 realm="biloxi.com", 435 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 436 uri="sip:bob@biloxi.com", 437 qop=auth, 438 nc=00000001, 439 cnonce="0a4f113b", 440 response="89eb0059246c02b2f6ee02c7961d5ea3", 441 opaque="5ccc069c403ebaf9f0171e9517f40e41" 442 Content-Type: application/sdp 443 Content-Length: 142 445 (Alice's SDP not shown) 447 3.2.3 Digest Generation Process 449 Firstly, it should be noted that the challenge contained two qop- 450 options, "auth" and "auth-int", and the UAC chose to use a message- 451 qop of "auth". Secondly, no algorithm is specified in the challenge 452 so the default value of MD5 is used. 454 Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: 456 If the "algorithm" directive's value is "MD5" or is unspecified, 457 then 459 A1 is: 461 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 463 where 465 passwd = < user's password > 467 This value of A1 is: 469 bob:biloxi.com:zanzibar 471 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the 472 following value: 474 12af60467a33e8518da5c68bbff12b11 476 From RFC2617 [3], A2 is defined as follows: 478 If the "qop" directive's value is "auth" or is unspecified, then 479 A2 is: 481 A2 = Method ":" digest-uri-value 483 Thus the value of A2 is 485 INVITE:sip:bob@biloxi.com 487 H(A2) then has value: 489 13a14a3eb5e2c24732a1a04fff543e92 491 Finally, the Digest is given by the following: 493 If the "qop" value is "auth" or "auth-int": 495 request-digest = <"> < KD ( H(A1), unq(nonce-value) 496 ":" nc-value 497 ":" unq(cnonce-value) 498 ":" unq(qop-value) 499 ":" H(A2) 500 ) <"> 502 H(A1) and H(A2) have been calculated above. The nonce-value is 503 provided by the server in the challenge. The nonce-count (nc-value) 504 and cnonce-value are generated by the client as per RFC2617 [3] and 505 the qop-value is chosen from the qop-options proposed by the server. 507 From the definition of KD given in RFC2617 [3] it follows that the 508 request-digest has value 510 <"> H(12af60467a33e8518da5c68bbff12b11: 511 dcd98b7102dd2f0e8b11d0f600bfb0c093: 512 00000001: 513 0a4f113b: 514 auth: 515 13a14a3eb5e2c24732a1a04fff543e92) <"> 517 This results in a final value of: 519 Digest = "89eb0059246c02b2f6ee02c7961d5ea3" 521 3.3 auth and MD5 523 3.3.1 Challenge 525 SIP/2.0 401 Unauthorized 526 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen 527 From: Bob ;tag=9483056782 528 To: Alice ;tag=1928301774 529 Call-ID: a84b4c76e66710 530 CSeq: 314159 INVITE 531 WWW-Authenticate: Digest 532 realm="biloxi.com", 533 qop="auth,auth-int", 534 algorithm=MD5, 535 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 536 opaque="5ccc069c403ebaf9f0171e9517f40e41" 537 Content-Length: 0 539 3.3.2 Authenticated Request 541 INVITE sip:alice@atlanta.com.com SIP/2.0 542 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 543 Max-Forwards: 70 544 From: Bob 545 To: Alice ;tag=8493745023 546 Call-ID: ab734d9e6b793b 547 CSeq: 83952 INVITE 548 Contact: 549 Authorization: Digest username="bob", 550 realm="biloxi.com", 551 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 552 uri="sip:bob@biloxi.com", 553 qop=auth, 554 algorithm=MD5, 555 nc=00000001, 556 cnonce="0a4f113b", 557 response="89eb0059246c02b2f6ee02c7961d5ea3", 558 opaque="5ccc069c403ebaf9f0171e9517f40e41" 559 Content-Type: application/sdp 560 Content-Length: 142 562 (Alice's SDP not shown) 564 3.3.3 Digest Generation Process 566 No choice is allowed in the selection of an algorithm. The challenge 567 indicates one, and only one algorithm and the challenged party must 568 accept this choice or fail to present an authenticated request. 570 The presence of MD5 as an algorithm is exactly equivalent to no 571 algorithm being specified. 573 Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: 575 If the "algorithm" directive's value is "MD5" or is unspecified, 576 then 578 A1 is: 580 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 582 where 584 passwd = < user's password > 586 This value of A1 is: 588 bob:biloxi.com:zanzibar 590 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the 591 following value: 593 12af60467a33e8518da5c68bbff12b11 595 From RFC2617 [3], A2 is defined as follows: 597 If the "qop" directive's value is "auth" or is unspecified, then 598 A2 is: 600 A2 = Method ":" digest-uri-value 602 Thus the value of A2 is 604 INVITE:sip:bob@biloxi.com 606 H(A2) then has value: 608 13a14a3eb5e2c24732a1a04fff543e92 610 Finally, the Digest is given by the following: 612 If the "qop" value is "auth" or "auth-int": 614 request-digest = <"> < KD ( H(A1), unq(nonce-value) 615 ":" nc-value 616 ":" unq(cnonce-value) 617 ":" unq(qop-value) 618 ":" H(A2) 619 ) <"> 621 H(A1) and H(A2) have been calculated above. The nonce-value is 622 provided by the server in the challenge. The nonce-count (nc-value) 623 and cnonce-value are generated by the client as per RFC2617 [3] and 624 the qop-value is chosen from the qop-options proposed by the server. 626 From the definition of KD given in RFC2617 [3] it follows that the 627 request-digest has value 629 <"> H(12af60467a33e8518da5c68bbff12b11: 630 dcd98b7102dd2f0e8b11d0f600bfb0c093: 631 00000001: 632 0a4f113b: 633 auth: 634 13a14a3eb5e2c24732a1a04fff543e92) <"> 636 This results in a final value of: 638 Digest = "89eb0059246c02b2f6ee02c7961d5ea3" 640 3.4 auth and MD5-Sess 642 3.4.1 Challenge 644 SIP/2.0 401 Unauthorized 645 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen 646 From: Bob ;tag=9483056782 647 To: Alice ;tag=1928301774 648 Call-ID: a84b4c76e66710 649 CSeq: 314159 INVITE 650 WWW-Authenticate: Digest 651 realm="biloxi.com", 652 qop="auth,auth-int", 653 algorithm=MD5-sess, 654 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 655 opaque="5ccc069c403ebaf9f0171e9517f40e41" 656 Content-Length: 0 658 3.4.2 Authenticated Request 660 INVITE sip:alice@atlanta.com.com SIP/2.0 661 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 662 Max-Forwards: 70 663 From: Bob 664 To: Alice ;tag=8493745023 665 Call-ID: ab734d9e6b793b 666 CSeq: 83952 INVITE 667 Contact: 668 Authorization: Digest username="bob", 669 realm="biloxi.com", 670 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 671 uri="sip:bob@biloxi.com", 672 qop=auth, 673 algorithm=MD5-sess, 674 nc=00000001, 675 cnonce="0a4f113b", 676 response="e4e4ea61d186d07a92c9e1f6919902e9", 677 opaque="5ccc069c403ebaf9f0171e9517f40e41" 678 Content-Type: application/sdp 679 Content-Length: 142 681 (Alice's SDP not shown) 683 3.4.3 Digest Generation Process 685 Algorithm MD5-sess can be used to implement a SIP server that never 686 knows the actual password for a given user. The SIP server is 687 required to request the password, through an undefined mechanism, 688 from a 3rd party authentication server, which returns a digest of the 689 password which can then be used to authenticate the user. 691 Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: 693 If the "algorithm" directive's value is "MD5-sess" then 695 A1 = H( unq(username-value) ":" unq(realm-value) 696 ":" passwd ) 697 ":" unq(nonce-value) ":" unq(cnonce-value) 699 where 701 passwd = < user's password > 703 Now the MD5 hash of username-value, realm-value and passwd would 704 normally be returned by the authentication server. This has the 705 following value. 707 H(bob:biloxi.com:zanzibar) 709 or 711 12af60467a33e8518da5c68bbff12b11 713 So the value of A1 is: 715 12af60467a33e8518da5c68bbff12b11: 716 dcd98b7102dd2f0e8b11d0f600bfb0c093: 717 0a4f113b 719 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the 720 following value: 722 4f36886771c77832be5c5a8de5a7ec82 724 From RFC2617 [3], A2 is defined as follows: 726 If the "qop" directive's value is "auth" or is unspecified, then 727 A2 is: 729 A2 = Method ":" digest-uri-value 731 Thus the value of A2 is 733 INVITE:sip:bob@biloxi.com 735 H(A2) then has value: 737 13a14a3eb5e2c24732a1a04fff543e92 739 Finally, the Digest is given by the following: 741 If the "qop" value is "auth" or "auth-int": 743 request-digest = <"> < KD ( H(A1), unq(nonce-value) 744 ":" nc-value 745 ":" unq(cnonce-value) 746 ":" unq(qop-value) 747 ":" H(A2) 748 ) <"> 750 H(A1) and H(A2) have been calculated above. The nonce-value is 751 provided by the server in the challenge. The nonce-count (nc-value) 752 and cnonce-value are generated by the client as per RFC2617 [3] and 753 the qop-value is chosen from the qop-options proposed by the server. 755 From the definition of KD given in RFC2617 [3] it follows that the 756 request-digest has value 758 <"> H(4f36886771c77832be5c5a8de5a7ec82: 759 dcd98b7102dd2f0e8b11d0f600bfb0c093: 760 00000001: 761 0a4f113b: 762 auth: 763 13a14a3eb5e2c24732a1a04fff543e92) <"> 765 This results in a final value of: 767 Digest = "e4e4ea61d186d07a92c9e1f6919902e9" 769 3.5 auth-int and MD5 771 The use of qop value auth-int indicates that integrity protection is 772 required. This means that the calculated digest includes a hash of 773 the body of the authenticated message, which allows a change to the 774 body of the message to be detected. 776 This may lead to possible problems traversing Network Address 777 Translators (NATs), Back-to-back UAs (B2BUAs) and Application Level 778 Gateways (ALGs), any of which may modify the body in order to permit 779 the SIP request to traverse some form of network boundary. In this 780 case, the NAT/B2BUA/ALG must also act as an endpoint and police and 781 possibly modify the authentication header. 783 3.5.1 Challenge 785 SIP/2.0 401 Unauthorized 786 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen 787 From: Bob ;tag=9483056782 788 To: Alice ;tag=1928301774 789 Call-ID: a84b4c76e66710 790 CSeq: 314159 INVITE 791 WWW-Authenticate: Digest 792 realm="biloxi.com", 793 qop="auth,auth-int", 794 algorithm=MD5, 795 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 796 opaque="5ccc069c403ebaf9f0171e9517f40e41" 797 Content-Length: 0 799 3.5.2 Authenticated Request 801 INVITE sip:alice@atlanta.com.com SIP/2.0 802 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 803 Max-Forwards: 70 804 From: Bob 805 To: Alice ;tag=8493745023 806 Call-ID: ab734d9e6b793b 807 CSeq: 83952 INVITE 808 Contact: 809 Authorization: Digest username="bob", 810 realm="biloxi.com", 811 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 812 uri="sip:bob@biloxi.com", 813 qop=auth-int, 814 algorithm=MD5, 815 nc=00000001, 816 cnonce="0a4f113b", 817 response="bdbeebb2da6adb6bca02599c2239e192", 818 opaque="5ccc069c403ebaf9f0171e9517f40e41" 819 Content-Type: application/sdp 820 Content-Length: 142 822 v=0 823 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com 824 s=- 825 c=IN IP4 media.biloxi.com 826 t=0 0 827 m=audio 49170 RTP/AVP 0 828 a=rtpmap:0 PCMU/8000 829 m=video 51372 RTP/AVP 31 830 a=rtpmap:31 H261/90000 831 m=video 53000 RTP/AVP 32 832 a=rtpmap:32 MPV/90000 834 3.5.3 Digest Generation Process 836 No choice is allowed in the selection of an algorithm. The challenge 837 indicates one, and only one algorithm (and thus no double-quotes are 838 present) and the challenged party must accept this choice or fail to 839 present an authenticated request. 841 The presence of MD5 as an algorithm is exactly equivalent to no 842 algorithm being specified. 844 Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: 846 If the "algorithm" directive's value is "MD5" or is unspecified, 847 then 849 A1 is: 851 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 853 where 855 passwd = < user's password > 857 This value of A1 is: 859 bob:biloxi.com:zanzibar 861 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the 862 following value: 864 12af60467a33e8518da5c68bbff12b11 866 From RFC2617 [3], A2 is defined as follows: 868 If the "qop" value is "auth-int", then A2 is: 870 A2 = Method ":" digest-uri-value ":" H(entity-body) 872 Thus the value of A2 is 874 INVITE:sip:bob@biloxi.com:H(entity-body) 876 entity-body consists of every byte comprising the body after the 877 blank line that separates the SIP headers from the SIP body, up to 878 the limit imposed by Content-Length or the end of the UDP datagram if 879 no Content-Length field is present. Note that white-space is 880 relevant in this case. Be careful of the presence, or absence, 881 carriage return an/or linefeeds at the end of the data! 883 Thus H(entity-body) is given by 885 H(v=0 886 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com 887 s=- 888 c=IN IP4 media.biloxi.com 889 t=0 0 890 m=audio 49170 RTP/AVP 0 891 a=rtpmap:0 PCMU/8000 892 m=video 51372 RTP/AVP 31 893 a=rtpmap:31 H261/90000 894 m=video 53000 RTP/AVP 32 895 a=rtpmap:32 MPV/90000 896 ) 898 or 900 H(763D300D0A6F3D626F622032383930383434353236203238393038343435 901 323620494E20495034206D656469612E62696C6F78692E636F6D0D0A733D 902 2D0D0A633D494E20495034206D656469612E62696C6F78692E636F6D0D0A 903 743D3020300D0A6D3D617564696F203439313730205254502F4156502030 904 0D0A613D7274706D61703A302050434D552F383030300D0A6D3D76696465 905 6F203531333732205254502F4156502033310D0A613D7274706D61703A33 906 3120483236312F39303030300D0A6D3D766964656F203533303030205254 907 502F4156502033320D0A613D7274706D61703A3332204D50562F39303030 908 300D0A) 910 H(entity-body) has the value 912 c1ed018b8ec4a3b170c0921f5b564e48 914 H(A2) has the value: 916 3e8ec46a56447dbb073e1171b1be0683 918 Finally, the Digest is given by the following: 920 If the "qop" value is "auth" or "auth-int": 922 request-digest = <"> < KD ( H(A1), unq(nonce-value) 923 ":" nc-value 924 ":" unq(cnonce-value) 925 ":" unq(qop-value) 926 ":" H(A2) 927 ) > <"> 929 H(A1) and H(A2) have been calculated above. The nonce-value is 930 provided by the server in the challenge. The nonce-count (nc-value) 931 and cnonce-value are generated by the client as per RFC2617 [3] and 932 the qop-value is chosen from the qop-options proposed by the server. 934 From the definition of KD given in RFC2617 [3] it follows that the 935 request-digest has value 937 <"> H(12af60467a33e8518da5c68bbff12b11: 938 dcd98b7102dd2f0e8b11d0f600bfb0c093: 939 00000001: 940 0a4f113b: 941 auth-int: 942 3e8ec46a56447dbb073e1171b1be0683) <"> 944 This results in a final value of: 946 Digest = "bdbeebb2da6adb6bca02599c2239e192" 948 3.6 auth-int and MD5-Sess 950 3.6.1 Challenge 952 SIP/2.0 401 Unauthorized 953 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen 954 From: Bob ;tag=9483056782 955 To: Alice ;tag=1928301774 956 Call-ID: a84b4c76e66710 957 CSeq: 314159 INVITE 958 WWW-Authenticate: Digest 959 realm="biloxi.com", 960 qop="auth,auth-int", 961 algorithm=MD5-sess, 962 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 963 opaque="5ccc069c403ebaf9f0171e9517f40e41" 964 Content-Length: 0 966 3.6.2 Authenticated Request 968 INVITE sip:alice@atlanta.com.com SIP/2.0 969 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 970 Max-Forwards: 70 971 From: Bob 972 To: Alice ;tag=8493745023 973 Call-ID: ab734d9e6b793b 974 CSeq: 83952 INVITE 975 Contact: 976 Authorization: Digest username="bob", 977 realm="biloxi.com", 978 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 979 uri="sip:bob@biloxi.com", 980 qop=auth-int, 981 algorithm=MD5-sess, 982 nc=00000001, 983 cnonce="0a4f113b", 984 response="91984da2d8663716e91554859c22ca70", 985 opaque="5ccc069c403ebaf9f0171e9517f40e41" 986 Content-Type: application/sdp 987 Content-Length: 142 989 v=0 990 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com 991 s=- 992 c=IN IP4 media.biloxi.com 993 t=0 0 994 m=audio 49170 RTP/AVP 0 995 a=rtpmap:0 PCMU/8000 996 m=video 51372 RTP/AVP 31 997 a=rtpmap:31 H261/90000 998 m=video 53000 RTP/AVP 32 999 a=rtpmap:32 MPV/90000 1001 3.6.3 Digest Generation Process 1003 Note that no choice is allowed in the selection of an algorithm. The 1004 challenge indicates one, and only one algorithm (and thus no double- 1005 quotes are present) and the challenged party must accept this choice 1006 it fail to present an authenticated request. 1008 Also note that the presence of MD5 as an algorithm is exactly 1009 equivalent to no algorithm being specified. 1011 Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: 1013 If the "algorithm" directive's value is "MD5-sess" then 1015 A1 = H( unq(username-value) ":" unq(realm-value) 1016 ":" passwd ) 1017 ":" unq(nonce-value) ":" unq(cnonce-value) 1019 where 1021 passwd = < user's password > 1023 Now the MD5 hash of username-value, realm-value and passwd would 1024 normally be returned by the authentication server. This has the 1025 following value. 1027 H(bob:biloxi.com:zanzibar) 1029 or 1031 12af60467a33e8518da5c68bbff12b11 1033 So the value of A1 is: 1035 12af60467a33e8518da5c68bbff12b11: 1036 dcd98b7102dd2f0e8b11d0f600bfb0c093: 1037 0a4f113b 1039 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the 1040 following value: 1042 4f36886771c77832be5c5a8de5a7ec82 1044 From RFC2617 [3], A2 is defined as follows: 1046 If the "qop" value is "auth-int", then A2 is: 1048 A2 = Method ":" digest-uri-value ":" H(entity-body) 1050 Thus the value of A2 is 1052 INVITE:sip:bob@biloxi.com:H(entity-body) 1054 Thus H(entity-body) is given by 1056 H(v=0 1057 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com 1058 s=- 1059 c=IN IP4 media.biloxi.com 1060 t=0 0 1061 m=audio 49170 RTP/AVP 0 1062 a=rtpmap:0 PCMU/8000 1063 m=video 51372 RTP/AVP 31 1064 a=rtpmap:31 H261/90000 1065 m=video 53000 RTP/AVP 32 1066 a=rtpmap:32 MPV/90000 1067 ) 1069 H(entity-body) has the value 1071 c1ed018b8ec4a3b170c0921f5b564e48 1073 Finally, the Digest is given by the following: 1075 If the "qop" value is "auth" or "auth-int": 1077 request-digest = <"> < KD ( H(A1), unq(nonce-value) 1078 ":" nc-value 1079 ":" unq(cnonce-value) 1080 ":" unq(qop-value) 1081 ":" H(A2) 1082 ) <"> 1084 H(A1) and H(A2) have been calculated above. The nonce-value is 1085 provided by the server in the challenge. The nonce-count (nc-value) 1086 and cnonce-value are generated by the client as per RFC2617 [3] and 1087 the qop-value is chosen from the qop-options proposed by the server. 1089 From the definition of KD given in RFC2617 [3] it follows that the 1090 request-digest has value 1092 <"> H(4f36886771c77832be5c5a8de5a7ec82: 1093 dcd98b7102dd2f0e8b11d0f600bfb0c093: 1094 00000001: 1095 0a4f113b: 1096 auth-int: 1097 3e8ec46a56447dbb073e1171b1be0683) <"> 1099 This results in a final value of: 1101 Digest = "91984da2d8663716e91554859c22ca70" 1103 4. Changes 1105 *** [Note to RFC editor. Please remove this entire section when this 1106 draft is published as an RFC.] *** 1108 4.1 Changes since draft-smith-sip-auth-digest-00 1110 Moved to Sipping WG and renamed draft-smith-sipping-auth-digest-00. 1112 Corrections to SDP subject field and resultant digest values. 1114 Updated boiler place in accordance with RFC 3667 and RFC 3668. 1116 4.2 Changes since draft-smith-sipping-auth-digest-00 1118 Corrected calculated digests for sections 3.1 and 3.2. 1120 Updated boiler place in accordance with RFC 3978 and RFC 3979. 1122 Security Considerations 1124 This document introduces no new protocol elements and therefore has 1125 no effect on the security of SIP. 1127 IANA Considerations 1129 This document has no actions for IANA. 1131 Normative References 1133 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1134 9, RFC 2026, October 1996. 1136 2 Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 1137 3261, June 2002 1139 3 Franks, J., et al., "HTTP Authentication: Basic and Digest Access 1140 Authentication", RFC 2617, June 1999 1142 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1143 Levels", BCP 14, RFC 2119, March 1997 1145 5 Sparks, R., et al., "Session Initiation Protocol Torture Test 1146 Messages", Internet Draft, October 2003, Work in progress. 1148 6 Franks, J., et al., "Extension to HTTP : Digest Access 1149 Authentication", RFC 2069, January 1997 1151 Informative References 1153 None. 1155 Acknowledgments 1157 Paul and Ian would like to thank their colleagues at Data Connection 1158 for their input during the production of this document, and WG 1159 members for useful feedback. 1161 Authors' Addresses 1163 Paul D.Smith 1164 Data Connection Ltd 1165 100 Church Street 1166 Enfield 1167 Middlesex 1168 EN2 6BQ 1169 United Kingdom 1170 Email: paul.d.smith@dataconnection.com 1172 Ian Clarkson 1173 Data Connection Ltd 1174 100 Church Street 1175 Enfield 1176 Middlesex 1177 EN2 6BQ 1178 United Kingdom 1179 Email: ian.clarkson@dataconnection.com 1181 Disclaimer of validity 1183 The IETF takes no position regarding the validity or scope of any 1184 Intellectual Property Rights or other rights that might be claimed to 1185 pertain to the implementation or use of the technology described in 1186 this document or the extent to which any license under such rights 1187 might or might not be available; nor does it represent that it has 1188 made any independent effort to identify any such rights. Information 1189 on the procedures with respect to rights in RFC documents can be 1190 found in BCP 78 and BCP 79. 1192 Copies of IPR disclosures made to the IETF Secretariat and any 1193 assurances of licenses to be made available, or the result of an 1194 attempt made to obtain a general license or permission for the use of 1195 such proprietary rights by implementers or users of this 1196 specification can be obtained from the IETF on-line IPR repository at 1197 http://www.ietf.org/ipr. 1199 The IETF invites any interested party to bring to its attention any 1200 copyrights, patents or patent applications, or other proprietary 1201 rights that may cover technology that may be required to implement 1202 this standard. Please address the information to the IETF at 1203 ietf-ipr@ietf.org. 1205 Full Copyright Statement 1207 Copyright (C) The Internet Society (2005). This document is 1208 subject to the rights, licenses and restrictions contained in BCP 1209 78, and except as set forth therein, the authors retain all their 1210 rights. 1212 This document and the information contained herein are provided 1213 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1214 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1215 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1216 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1217 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1218 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1219 PARTICULAR PURPOSE.