idnits 2.17.1 draft-veltri-sip-alt-auth-00.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, updated by RFC 4748 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 729. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 308 has weird spacing: '... ii introdu...' -- 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 (April 27, 2008) is 5844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2401' is defined on line 645, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group L. Veltri 3 Internet-Draft Univ. of Parma 4 Intended status: Informational S. Salsano 5 Expires: October 29, 2008 A. Polidoro 6 Univ. of Rome Tor Vergata 7 April 27, 2008 9 HTTP digest authentication using alternate password storage schemes 10 draft-veltri-sip-alt-auth-00 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 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 29, 2008. 37 Abstract 39 This document proposes to extend the HTTP Digest Authentication by 40 adding a set new algorithms. These algorithms use different hash 41 functions and combination of various information such as user name, 42 realm, password, salt, and/or other data, in order to achieve 43 compatibility with existing mechanisms used to store user credentials 44 in various authentication/autorization servers. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. HTTP Digest Authentication for SIP . . . . . . . . . . . . . . 4 52 3. New extensible authentication scheme . . . . . . . . . . . . . 8 53 3.1. First solution . . . . . . . . . . . . . . . . . . . . . . 11 54 3.2. Second solution . . . . . . . . . . . . . . . . . . . . . 13 56 4. Security considerations . . . . . . . . . . . . . . . . . . . 17 58 5. Informative References . . . . . . . . . . . . . . . . . . . . 18 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 61 Intellectual Property and Copyright Statements . . . . . . . . . . 20 63 1. Introduction 65 According to the current SIP specification [RFC3261], the SIP 66 protocol uses the HTTP Digest Authentication defined in [RFC2617] as 67 default mechanism for authenticating and authorizing User Agent 68 Clients (UACs) against remote User Agent Servers (UASs) or 69 intermediate proxys. HTTP Digest Authentication is a challenge- 70 response authentication method and requires that both the supplicant 71 (i.e. the UAC) and the authenticator (i.e. the UAS or the proxy) 72 access the clear-text user password or a non-revertible function 73 (hash-derived) of the password and other information. The HTTP 74 Digest Authentication [RFC2617] specifically define also an 75 authentication scheme named MD5 that requires the UAs and proxys to 76 compute or retrive from a database the MD5 digest of a concatenation 77 (colon-separated) of username, realm, and password. Unfortunately 78 other user authentication/authorization mechanisms use different and 79 non compatible mechanisms to store non-revertible hashes of 80 passwords. This prevents using an existing database of user 81 credentials to offer SIP based services requiring authentication. 82 This document tries to extend the stantard SIP/HTTP Digest 83 Authentication mechanism in order to consider other password-storing 84 schemes that do not naturally cooperate with the current HTTP Digest 85 Authentication scheme. Examples of such password-storing schemes are 86 those generally used in LDAP servers, Unix shadow/password files, 87 Apache's htpasswd file, or SQL-based storage systems used by other 88 specific applications. 90 2. HTTP Digest Authentication for SIP 92 HTTP Digest Authentication [RFC2617] is a general challenge-response 93 mechanism in which a UAS authenticates a UAC based on a shared 94 secret. The challenge response is computed through the use of a one- 95 way function based on various user's credentials. The standard also 96 specifies the use of a particular function (in turn based on the MD5 97 hash function) that requires that both the client and server knows 98 the user secret (normally a password) or, at least, the hash of the 99 concatenation of the user name, the realm, and the password. 101 When the HTTP Digest Authentication [RFC2617] is used in SIP, an UAS 102 that receives a SIP request (example a REGISTER) may challenge the 103 UAC by sending a 401 "Unauthorized" error response (or 407 "Proxy 104 Authentication Required" for proxy authentication) containing a fresh 105 random nonce value as challenge. Both the UAC and the UAS share a 106 secret (usually a password) and they use this secret, together with 107 the nonce value, realm, and other information, respectively to 108 compute the challenge response (the UAC) and to verify such the 109 response (the UAS). The UAS sends the challenge in the 401 110 "Unauthorized" SIP response within a WWW-Authenticate header field 111 (Proxy-Authenticate header for proxy authentication), then the UAC 112 sends the challenge response in a new request message within a 113 Authorization header field (Proxy-Authorization header for proxy 114 authentication), and finally the UAS sends the authentication and 115 authorization result with a new response message (2xx if it 116 successed). 118 According to [RFC2617] the challenge response is computed as: 120 response = KD(H(A1), nonce:nc:cnonce:qop:H(method:uri)) 122 where KD(secret,data) is a general two-parameters digest algorithm 123 applied to "data" with secret "secret", while H(data) is a digest 124 algorithm applied to "data", and A1 is a quantity that should take 125 into account user credentials. 127 As specified in [RFC2617], by default or in case of "algorithm=MD5, 128 the KD(,) H(), and A1 are respectively: 130 KD(secret, data) = MD5(secret:data) 132 H(data) = MD5(data) 134 A1 = username:realm:passwd 136 Particularly, the first term of KD(,) (indicated as "secret") and 137 computed as H(A1) becomes: 139 secret = H(A1) = MD5(username:realm:passwd) 141 Note that both the requestor (the UAC) and the auhenticator (the UAS) 142 do not need to know the user password (eventually retrieved from a 143 local archive), but rather this "secret" i.e. a digest function of 144 username, realm and password itself. 146 Unfortunately, current user's credential databases or storage systems 147 often protect user's password by implementing one-way cryptographic 148 algorithms different from the MD5 hashing mechanism specified for the 149 HTTP Digest Authentication. 151 For example, in LDAP (Lightweight Directory Access Protocol) servers, 152 password values can be stored as plaintext or as one of a variety of 153 hashes. [RFC3112] specifically describes the "MD5" and "SHA1" 154 schemes for a LDAP directory. The MD5 scheme computes the hashed- 155 protected password as the base64 encoding of an MD5 [RFC1321] digest 156 of the concatenation the user password and salt that must be at least 157 64 bit long. The SHA1 scheme computes the hashed-protected password 158 in the same way, by using SHA1 [RFC3174] hash function instead of 159 MD5. 161 These two hash-protected password schemes are also referred as: 163 o SSHA - Salted SHA-1 based hash 165 o SMD5 - Salted MD5 based hash 167 Other hash-protected password schemes normally supported by an LDAP 168 server are: 170 o SHA - SHA-1 based hash. 172 o MD5 - MD5 based hash. 174 o CRYPT - Unix crypt() hash, based on DES, also referred as UNIX; 175 see later. 177 Note that these three schemes are weaker than the previous two, due 178 to the absence of a security salt value. In some lucky cases a LDAP 179 server may also support other schemes that use pre-calculated hash 180 values compatible with HTTP Digest Authentication. 182 An other example is the Unix system in which passwords are usually 183 stored in the "/etc/shadow" file or, in older Unix versions, in the 184 "/etc/password" file. In both cases, passwords are normally stored 185 encrypted (actually hashed) with a one-way algorithm generally 186 referred as "crypt", together with a salt value and an indication of 187 the used algorithm. The traditional crypt algorithm implementation 188 uses a modified form of the DES algorithm that performs 25 DES passes 189 to encrypt an all-bits-zero block using with a 56-bit key formed by 190 the first 7 password characters. A 12-bit salt is used to perturb 191 the original DES algorithm. The salt and the final ciphertext are 192 base64-encoded into a printable string stored in the password or 193 shadow file. Other more robust crypt functions have been defined 194 based on other cryptographic or hash algorithms such as MD5, 195 blowfish, or SHA-1. Such functions generally allow users to have any 196 length password (> 8bytes), and do not limit the password to ASCII 197 (7-bit) text. Currently, the most common crypt function used by 198 Unix/Linux systems supports both the original DES-based and the MD5- 199 based (MD5-crypt) algorithms. The MD5-crypt function is really not a 200 straight implementation of MD5: first the password and salt are MD5 201 hashed together in a first digest, then 1000 iteration loops 202 continuously remix the password, salt and intermediate digest values; 203 the output of the last of these rounds is the resulting hash. A 204 typical output of the stored password together with username, salt, 205 and other information is: 207 alice:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj:12747:0:99999:7::: 209 where $1$ indicates the use of MD5-crypt, while BZftq3sP is the 210 base-64 encoding of the salt and xEeZmr2fGEnKjVAxzjQo68 is the 211 password hash. 213 Other applications also store user's credentials in local files or 214 database, that have they own format but that re-use similar hashing 215 algorithms. For example the Apache's htpasswd tool supports four 216 different methods: 218 PLAINTEXT: passwords are stored without any encryption mechanism. 219 In this case in the file will contain lines of the form: user: 220 passwd 222 CRYPT: passwords are stored encrypted using the traditional Unix 223 crypt function described in the previous section. 225 SHA1: passwords are stored by base64-encoding the SHA-1 digest of 226 the password. The corresponding htpasswd file has lines that look 227 like: 229 alice:{SHA1}VBPuJHI7uixaa6LQGWx4s+5GKNE= 231 where VBPuJHI7uixaa6LQGWx4s+5GKNE= is the base-64 hash of the 232 password. 234 MD5: passwords are stored encrypted through the MD5-crypt function 235 described in the previous section using an Apache-modified version 236 of MD5. An example of a corresponding htpasswd line is: 238 alice:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/ 240 where $apr1$ indicates the use of the Apache's MD5-crypt 241 function, followed by the salt and the effective password hash. 243 3. New extensible authentication scheme 245 The HTTP Digest Authentication [RFC2617] requires that the response 246 to the challenge, regardless of the selected algorithm, is in the 247 form of: 249 response = KD(H(A1),nonce:nc:cnonce:qop:H(method:uri)) 251 In case of "algorithm=MD5", KD(secret,data) is MD5(secret:data), 252 H(data) is MD5(data), while the H(A1) becomes MD5(username:realm: 253 passwd). 255 Assuming for the moment that we have no interest in changing the KD 256 function, we can envisage two possible solutions: 258 a. we can define a different A1 and H(A1) function compatible with 259 the specific authentication system (A1 is a formatted set of 260 parameters that are taken into account by the H() function). For 261 example A1 could be the concatenation passwd:salt and H(A1) could 262 become: H(A1) = MD5(passwd:salt) 264 b. we can reuse the definition of H(A1) and only replace the 265 password parameter with a new derived pseudo-password A3 defined 266 as A3=KP(password,other-params). In this case we are introducing 267 a new function KP() with a new set of parameters that includes 268 the user password. The value A1 becomes: A1=username:realm:A3. 270 For example, if we chose KP() as MD5(passwd:salt) the value H(A1) 271 becomes: 273 H(A1) = MD5(username:realm:A3), i.e.: 275 H(A1) = MD5(username:realm:MD5(passwd:salt)) 277 The first solution (a) has the advantage that it may save some 278 computation of crypto functions. The second option (b) has the 279 advantage that it inherits all the security properties of the current 280 MD5 solution. Moreover one could store in the client the derived 281 password (i.e. the A3 value) instead of the password and maintain a 282 compatibility with existing clients. We are here referring to the 283 approach of several SIP user agents to store the SIP user password 284 rather then requesting it to the user each time. During this "one- 285 time" password storing operation, the A3 value could be computed 286 externally and then manually stored in the SIP client. Of course 287 this is not our suggested solution, i.e. we believe that SIP stacks 288 should be enhanced with the proposed solution so that SIP UA can 289 natively support the new authentication method, anyway it was worth 290 mentioning this possibility to reuse legacy clients in the short 291 term. 293 Once that we have chosen which solution for the algorithm, we should 294 discuss: 296 1. how to introduce the indication of this different authentication 297 algorithms within SIP signaling; 299 2. how to convey the parameters that are needed by the new 300 authentication algorithms. 302 Again, we introduce two different options concerning issue 1): 304 i introduce new algorithms specified as parameter "algorithm" 305 within authentication headers. We could have for example 306 algorithm=md5-ldap-sha1, algorithm=md5-crypt-des and so on. 308 ii introduce a new authentication parameter called "pwd-algo" in 309 order to indicate the chosen algorithm used to compute only the 310 derived-passwd A3. 312 These two choices are not completely independent from the choice of 313 the algorithm definition, as shown in the following table. 315 |----------------------|----------------------|----------------------| 316 | |i)introduce new values|ii)introduce a new | 317 | | for the algorithm | pwd-algo parameter | 318 | | parameter | | 319 |----------------------|----------------------|----------------------| 320 |a)definition of a | | | 321 | new A1 and H(A1) | Yes | No | 322 | | | | 323 |----------------------|----------------------|----------------------| 324 |b)reuse H(A1) and | | | 325 | include a new | | | 326 | A3=KP(pwd,params) in | Possible | Suggested | 327 | place of the passwd | | | 328 | value | | | 329 |----------------------|----------------------|----------------------| 331 Figure 1: Alternatives 333 If we define new A1 and H(A1) this should be signaled by introducing 334 new values for the algorithm parameter. At the contrary, if we reuse 335 H(A1) and introduce A3=KP() in place of the clear password, both 336 options for the signaling are feasible, but we think that keeping the 337 algorithm parameter unchanged (that specify A1, H(), and KD()) and 338 introducing a new pwd-algo is preferable. 340 Now we finally need to discuss how to convey the additional parameter 341 that may be needed by the different authentication mechanisms. We 342 think that three options are possible: 344 1. introduce new parameters with specific names for each 345 authentication algorithm; 347 2. introduce a generic parameter named pwd-param to carry algorithm 348 specific parameters; 350 3. carry the new parameters added inside the nonce parameter. This 351 is the approach that has been followed for example in the 352 specification of the AKA authentication mechanism. 354 We believe that 1) is the worst solution as it may lead to add 355 several new parameters. 2) and 3) are both feasible, where 2) is a 356 "cleaner" approach that requires the definition of an additional 357 parameter, while 3) has the advantage that does not require any new 358 parameter. Considering the various discussed options, we believe 359 that a first possible solution is based on: 361 a. reuse of H(A1) with a modified version of A1 in which the 362 password value is simply replaced by A3 = KP(password,other- 363 params) 365 b. introduction of new "pwd-algo" parameter 367 c. introduction of a new generic "pwd-param" parameter 369 Examples of the new pwd-algo parameter are: 371 pwd-algo= ssha 373 pwd-algo= crypt-md5 375 pwd-algo= crypt-apache 377 A second possible solution, more conservative from the point of view 378 of SIP signaling is the use of A3 = KP(password,other-params) as 379 above, but specifying the chosen algorithm in the existing 380 "algorithm" parameter and carrying the algorithm specific parameters 381 within the "nonce" parameter. Examples of the "algorithm" parameter 382 are: 384 algorithm=md5-pwd-hashed 386 algorithm=sha1-pwd-salt-hashed 388 When we need to specify variants of the algorithm we think that a 389 simple and efficient solution is to carry the name of the variant 390 into the eventual pwd-param or as part of the nonce value. 392 3.1. First solution 394 In the first solution we define two new parameters as follows: 396 pwd-algo = "pwd-algo" "=" ( "plain" | token ) 398 pwd-param = "pwd-param" "=" quoted-string 400 where "pwd-algo" specifies the function KP() used to compute the 401 derived-password A3, while "pwd-param" has a completely opaque value, 402 depending on the particular selected function KP, indicating the 403 values of the (eventual) parameters used in KP() computation. A 404 "pwd-algo=plain" value should indicate that none algorithm has to be 405 used, and hence A3=password. This corresponds to the case in which 406 no pwd-algo parameter is present, as in case of standard MD5-based 407 Digest Authentication. Examples of such parameters are: 409 pwd-algo=crypt-des, pwd-param="fzwhEV6E" 411 pwd-algo=alternative, pwd-param="12" 413 pwd-algo=plain 415 Particularly, in order to support current LDAP, Unix-based, and other 416 storing mechanisms, the following new values are defined: 418 pwd-algo = "pwd-algo" "=" ( "plain" | "ssha" | "smd5" | "sha" | 419 "md5" | crypt-algo | token ) 421 crypt-algo = "crypt-" crypt-hash 423 crypt-hash = "des" | "md5" | "blowfish" | "apache" | token 425 pwd-param = "pwd-param" "=" LDQUOT salt-value RDQUOT 427 salt-value = 429 In case of ssha or smd5 or crypt-XXX, the A3 value is computed as 430 follows: 432 A3 = KP(password,salt) = H(password||salt) 434 where H() is respectively SHA1, MD5, or the the Unix crypt function. 436 Instead, in the remaining cases: 438 A3 = KP(password) = H(password) 440 In case of ssha or smd5 or crypt-XXX, the pwd-param will contain the 441 base-64 encoding of the salt value. 443 Examples of use of such parameters within a SIP transaction are: 445 INVITE sip:bob@neverland.net SIP/2.0 447 To: sip:bob@neverland.net 449 From: sip:alice@wonderland.net 451 [...] 453 SIP/2.0 401 Unauthorized 455 To: sip:bob@neverland.net 457 From: sip:alice@wonderland.net 459 WWW-Authenticate: Digest realm="example.com", 461 nonce="cc5a61b2954e03541847f227102f", 463 qop="auth", algorithm="MD5", pwd-algo="crypt-md5", 465 pwd-param="fzwhEV6E" 467 [...] 469 INVITE sip:bob@neverland.net SIP/2.0 471 To: sip:bob@neverland.net 473 From: sip:alice@wonderland.net 475 Authorization: Digest username="alice", realm="example.com", 477 nonce="cc5a61b2954e03541847f227102f", 479 pwd-algo="crypt-md5", pwd-param="MD5-fzwhEV6E" 481 response="587410ee2dc5edd9bbe9370ddc1fA3a1", 483 uri="sip:bob@neverland.net", qop="auth", nc="00000001" 484 cnonce="226827CAD1C949A18B17FD71EC68" 486 [...] 488 SIP/2.0 200 OK 490 To: sip:bob@neverland.net 492 From: sip:alice@wonderland.net 494 [...] 496 3.2. Second solution 498 The second solution does not require any new authentication 499 parameters since both the selected function KP() (used to generate 500 the new "password" value A3 used in A1) and the eventual parameters 501 of KP() are indicated respectively in the standard algorithm and 502 nonce authentication parameters. According with this solution, the 503 "algorithm" parameter defined in [RFC3261] can be extended as 504 follows: 506 algorithm = "algorithm" EQUAL ( algorithm-value | new-algorithm) 508 algorithm-value = "MD5" | "MD5-sess" | token 510 where "new-algorithm" is a new algorithm name that completely 511 specifies the KD(), H(), A1, and KP() functions for the new 512 authentication scheme. For example, in order to support 513 authentication against a server with Unix-based password archive, we 514 could define: 516 new-algorithm = crypt-algorithm 518 crypt-algorithm = algorithm-value "-crypt" 520 Examples of the use of "algorithm" parameter are: 522 algorithm=MD5 524 algorithm=MD5-crypt 526 In case of KP() function requires additional parameters such as sub- 527 algorithm type, salt, etc, their values will be included within the 528 nonce parameter, in a form named compound-nonce. According to 529 [RFC3261], the "nonce" parameter can be extended as follows: 531 nonce = "nonce" EQUAL (nonce-value | compound-nonce ) 533 compound-nonce = LDQUOT compound-nonce-value RDQUOT 535 compound-nonce-value = algo-param ":" nonce-value 537 algo-param = *( unreserved | algo-mark ) 539 algo-mark = ";" | "/" | "?" | "@" | "&" | "=" | "+" | "$" | "," 541 Examples of the use of nonce parameter are: 543 nonce="cc5a61b2954e0354184" 545 nonce=":cc5a61b2954e0354184" 547 nonce="$1$BZftq3sP:cc5a61b2954e0354184" 549 Particularly, in order to support current LDAP, Unix-based, and other 550 storing mechanisms, the following new values are defined: 552 algorithm = "algorithm" EQUAL ( algorithm-value | new-algorithm) 554 new-algorithm = algorithm-value ( "-pwd-hashed" | "-pwd-salt- 555 hashed" ) 557 In this case, the nonce parameter will contains indication of both 558 password hash algorithm and salt, together with the actual nonce 559 value; that is: 561 nonce = "nonce" EQUAL (nonce-value | compound-nonce ) 563 compound-nonce = LDQUOT compound-nonce-value RDQUOT 565 compound-nonce-value = ( salted-hash-algo | hash-algo ) ":" nonce- 566 value 568 compound-nonce-value = ( crypt-algo-nonce ) ":" nonce-value 570 hash-algo = "sha" | "md5" | "des" | "blowfish" | "apache" | token 572 salted-hash-algo = (hash-algo | crypt-algo) "-" salt-value 574 crypt-algo = "crypt-" hash-algo 576 salt-value = . 578 Examples of use of such parameters within a SIP transaction are: 580 INVITE sip:bob@neverland.net SIP/2.0 582 To: sip:bob@neverland.net 584 From: sip:alice@wonderland.net 586 [...] 588 SIP/2.0 401 Unauthorized 590 To: sip:bob@neverland.net 592 From: sip:alice@wonderland.net 594 WWW-Authenticate: Digest realm="example.com", 596 nonce="crypt-des-fzwhEV6E:cc5a61b2954e03541847f2", 598 qop="auth", algorithm="MD5-crypt" 600 [...] 602 INVITE sip:bob@neverland.net SIP/2.0 604 To: sip:bob@neverland.net 606 From: sip:alice@wonderland.net 608 Authorization: Digest username="alice", realm="example.com", 610 nonce="crypt-des-fzwhEV6E:cc5a61b2954e03541847f2", 612 response="587410ee2dc5edd9bbe9370ddc1fA3a1", 614 uri="sip:bob@neverland.net", qop="auth", nc="00000001" 616 cnonce="226827CAD1C949A18B17FD71EC68" 618 [...] 620 SIP/2.0 200 OK 622 To: sip:bob@neverland.net 624 From: sip:alice@wonderland.net 626 [...] 627 We believe that this second solution is to be preferred to the one 628 presented in the previous sub-section, as it does not require 629 addition of new parameters. This is the same approach that has been 630 followed when defining the SIP-AKA authentication mechanism 631 [RFC3310]. 633 4. Security considerations 635 Put security considerations here 637 5. Informative References 639 [RFC3261] J. Rosenberg et al., "SIP: Session Initiation Protocol", 640 RFC 3261, June 2002. 642 [RFC2617] J. Franks et al., "HTTP Authentication: Basic and Digest 643 Access Authentication", RFC 2617, June 1999. 645 [RFC2401] "Security Architecture for the Internet Protocol", RFC 646 2401, November 1998. 648 [RFC3310] "Hypertext Transfer Protocol (HTTP) Digest Authentication 649 Using Authentication and Key Agreement (AKA)", RFC 3310, 650 September 2002. 652 [RFC3112] "LDAP Authentication Password Schema", RFC 3112, May 2001. 654 [RFC1321] "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 656 [RFC3174] "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, 657 September 2001. 659 Authors' Addresses 661 Luca Veltri 662 DII, University of Parma 663 Viale delle Scienze 181/A 664 Parma 43100 665 Italy 667 Phone: +39 0521 90 5768 668 Email: luca.veltri@unipr.it 669 URI: http://www.tlc.unipr.it/veltri 671 Stefano Salsano 672 DIE, University of Rome "TorVergata" 673 Via Politecnico, 1 674 Rome 00133 675 Italy 677 Phone: +39 06 7259 7770 678 Email: stefano.salsano@uniroma2.it 679 URI: http://netgroup.uniroma2.it/Stefano_Salsano 681 Andrea Polidoro 682 DIE, University of Rome "TorVergata" 683 Via Politecnico, 1 684 Rome 00133 685 Italy 687 Phone: +39 06 7259 7773 688 Email: andrea.polidoro@uniroma2.it 689 URI: http://netgroup.uniroma2.it 691 Full Copyright Statement 693 Copyright (C) The IETF Trust (2008). 695 This document is subject to the rights, licenses and restrictions 696 contained in BCP 78, and except as set forth therein, the authors 697 retain all their rights. 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 702 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 703 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 704 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Intellectual Property 709 The IETF takes no position regarding the validity or scope of any 710 Intellectual Property Rights or other rights that might be claimed to 711 pertain to the implementation or use of the technology described in 712 this document or the extent to which any license under such rights 713 might or might not be available; nor does it represent that it has 714 made any independent effort to identify any such rights. Information 715 on the procedures with respect to rights in RFC documents can be 716 found in BCP 78 and BCP 79. 718 Copies of IPR disclosures made to the IETF Secretariat and any 719 assurances of licenses to be made available, or the result of an 720 attempt made to obtain a general license or permission for the use of 721 such proprietary rights by implementers or users of this 722 specification can be obtained from the IETF on-line IPR repository at 723 http://www.ietf.org/ipr. 725 The IETF invites any interested party to bring to its attention any 726 copyrights, patents or patent applications, or other proprietary 727 rights that may cover technology that may be required to implement 728 this standard. Please address the information to the IETF at 729 ietf-ipr@ietf.org.