idnits 2.17.1 draft-ietf-sip-sec-agree-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** 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. RFC 2119 keyword, line 146: '...of security mechanisms MUST be secure....' RFC 2119 keyword, line 368: '... hop proxy MUST add a Security-Client...' RFC 2119 keyword, line 371: '...client supports. The client SHOULD NOT...' RFC 2119 keyword, line 372: '... this list. The client MUST add both a...' RFC 2119 keyword, line 382: '... TLS) the client MAY choose not to inc...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...hat new metho...' == Line 379 has weird spacing: '...allenge in th...' == Line 551 has weird spacing: '... ard o ...' == Line 553 has weird spacing: '... ard o ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2633 (ref. '5') (Obsoleted by RFC 3851) == Outdated reference: A later version (-03) exists of draft-garcia-sipping-3gpp-reqs-00 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group Jari Arkko 3 INTERNET-DRAFT Vesa Torvinen 4 Gonzalo Camarillo 5 June 2002 Ericsson 6 Expires: December 2002 Tao Haukka 7 Nokia 8 Sanjoy Sen 9 Nortel Networks 11 Security Mechanism Agreement for SIP Sessions 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is an individual submission to the IETF. Comments 34 should be directed to the authors. 36 Abstract 38 SIP has a number of security mechanisms. Some of them have been built 39 in to the SIP protocol, such as HTTP authentication or secure 40 attachments. These mechanisms have even alternative algorithms and 41 parameters. SIP does not currently provide any mechanism for 42 selecting which security mechanisms to use between two entities. In 43 particular, even if some mechanisms such as OPTIONS were used to make 44 this selection, the selection would be vulnerable against the 45 Bidding-Down attack. This document defines three header fields for 46 negotiating the security mechanisms within SIP between a SIP entity 47 and its next SIP hop. A SIP entity applying this mechanism must 48 always require some minimum security (i.e. integrity protection) from 49 all communicating parties in order to secure the negotiation, but the 50 negotiation can agree on which specific security is used. 52 TABLE OF CONTENTS 54 1. Introduction....................................................2 55 2. The Problem.....................................................3 56 3. Solution........................................................4 57 3.1. Requirements...............................................4 58 3.2. Overview of Operations.....................................5 59 3.3. Syntax.....................................................6 60 3.4. Protocol Operation.........................................7 61 3.4.1 Client Initiated........................................7 62 3.4.2 Server Initiated........................................8 63 3.5. Security Mechanism Initiation..............................9 64 3.6. Duration of the Security Association......................10 65 3.7. Summary of Header Field Use...............................10 66 4. Backwards Compatibility........................................11 67 5. Examples.......................................................11 68 5.1. Client Initiated..........................................10 69 5.2. Server Initiated..........................................12 70 5.3. Security Negotiation between Proxies......................13 71 6. Security Considerations........................................13 72 7. IANA Considerations............................................15 73 8. Acknowledgments................................................15 74 9. Normative References...........................................15 75 10. Non-Normative References.......................................16 76 11. Authors's Addresses............................................16 78 1. Introduction 80 Traditionally, security protocols have included facilities to agree 81 on the used mechanisms, algorithms, and other security parameters. 82 The reason for this is that algorithm development typically uncovers 83 problems in old algorithms and sometimes even produces new problems. 84 Furthermore, different mechanisms and algorithms are suitable for 85 different situations. Typically, protocols also select other 86 parameters beyond algorithms at the same time. 88 The purpose of this specification is to define a similar negotiation 89 functionality in SIP [1]. SIP has some security functionality built- 90 in (e.g. HTTP Digest authentication [4]), it can utilize secure 91 attachments (e.g. S/MIME [5]), and it can also use underlying 92 security protocols (e.g. IPsec/IKE [2] or TLS [3]). Some of the 93 built-in security functionality allows also alternative algorithms 94 and other parameters. While some work within the SIP Working Group 95 has been looking towards reducing the number of recommended security 96 solutions (i.e., recommend just one lower layer security protocol), 97 we can not expect to cut down the number of items in the whole list 98 to one. There will still be multiple security solutions utilized by 99 SIP. Furthermore, it is likely that new methods will appear in the 100 future, to complement the methods that exist today. 102 Chapter 2 shows that without a secured method to choose between 103 security mechanisms and/or their parameters, SIP is vulnerable to 104 certain attacks. As the HTTP authentication RFC [4] points out, 105 authentication and integrity protection using multiple alternative 106 methods and algorithms is vulnerable to Man-in-the-Middle (MitM) 107 attacks. More seriously, it is hard or sometimes even impossible to 108 know whether a SIP peer entity is truly unable to perform (e.g., 109 Digest, TLS, or S/MIME) or if a MitM attack is in action. In small 110 networks consisting of workstations and servers these issues are not 111 very relevant, as the administrators can deploy appropriate software 112 versions and set up policies for using exactly the right type of 113 security. However, SIP will be deployed to hundreds of millions of 114 small devices with little or no possibilities for coordinated 115 security policies, let alone software upgrades, and this makes these 116 issues much worse. This conclusion is also supported by the 117 requirements from 3GPP [7]. 119 Chapter 6 documents the proposed solution, and chapter 7 gives some 120 demonstrative examples. 122 2. Problem Description 124 SIP has alternative security mechanisms such as HTTP authentication 125 with integrity protection, lower layer security protocols, and 126 S/MIME. It is likely that their use will continue in the future. SIP 127 security is developing, and is likely to see also new solutions in 128 the future. 130 Deployment of large number of SIP-based consumer devices such as 3GPP 131 terminals requires all network devices to be able to accommodate 132 past, current and future mechanisms; there is no possibility for 133 instantaneous change since the new solutions are coming gradually in 134 as new standards and product releases occur. It is sometimes even 135 impossible to upgrade some of the devices without getting completely 136 new hardware. 138 So, the basic security problem that such a large SIP-based network 139 must consider, would be on how do security mechanisms get selected? 140 It would be desirable to take advantage of new mechanisms as they 141 become available in products. 143 Firstly, we need to know somehow what security should be applied, and 144 preferably find this out without too many additional roundtrips. 146 Secondly, selection of security mechanisms MUST be secure. 147 Traditionally, all security protocols use a secure form of 148 negotiation. For instance, after establishing mutual keys through 149 Diffie-Hellman, IKE sends hashes of the previously sent data -- 150 including the offered crypto mechanisms. This allows the peers to 151 detect if the initial, unprotected offers were tampered with. 153 The security implications of this are subtle, but do have a 154 fundamental importance in building large networks that change over 155 time. Given that the hashes are produced also using algorithms agreed 156 in the first unprotected messages, one could ask what the difference 157 in security really is. Assuming integrity protection is mandatory and 158 only secure algorithms are used, we still need to prevent MitM 159 attackers from modifying other parameters, such as whether encryption 160 is provided or not. Let us first assume two peers capable of using 161 both strong and weak security. If the initial offers are not 162 protected in any way, any attacker can easily "downgrade" the offers 163 by removing the strong options. This would force the two peers to use 164 weak security between them. But if the offers are protected in some 165 way -- such as by hashing, or repeating them later when the selected 166 security is really on -- the situation is different. It would not be 167 sufficient for the attacker to modify a single message. Instead, the 168 attacker would have to modify both the offer message, as well as the 169 message that contains the hash/repetition. More importantly, the 170 attacker would have to forge the weak security that is present in the 171 second message, and would have to do so in real time between the sent 172 offers and the later messages. Otherwise, the peers would notice that 173 the hash is incorrect. If the attacker is able to break the weak 174 security, the security method and/or the algorithm should not be 175 used. 177 In conclusion, the security difference is making a trivial attack 178 possible versus demanding the attacker to break algorithms. An 179 example of where this has a serious consequence is when a network is 180 first deployed with integrity protection (such as HTTP Digest [4]), 181 and then later new devices are added that support also encryption 182 (such as S/MIME [1]). In this situation, an insecure negotiation 183 procedure allows attackers to trivially force even new devices to use 184 only integrity protection. 186 3. Solution 188 3.1 Requirements 190 The solution to the SIP security negotiation problem should have the 191 following properties: 193 (a) It allows the selection of security mechanisms, such as lower 194 layer security protocols or HTTP digest. It also allows the selection 195 of individual algorithms and parameters when the security functions 196 are integrated in SIP (such as in the case of HTTP authentication). 198 (b) It allows next-hop security negotiation. 200 (c) It is secure (i.e., prevents the bidding down attack.) 202 (d) It is capable of running without additional roundtrips. This is 203 important in the cellular environment, where an additional roundtrip 204 could delay the call set up for 1000-1500 ms. 206 (e) It does not introduce any additional state to servers and 207 proxies. 209 Currently, SIP does not have any mechanism which fulfills all the 210 requirements above. The basic SIP features such as OPTIONS and 211 Require, Supported headers are capable of informing peers about 212 various capabilities including security mechanisms. However, the 213 straight forward use of these features can not guarantee a secured 214 agreement. HTTP Digest algorithm lists [4] are not secure for picking 215 among the digest integrity algorithms, as is described in the HTTP 216 authentication RFC [4] itself. More seriously, they have no 217 provisions for allowing encryption to be negotiated. Hence, it would 218 be hard to turn on possible future encryption schemes in a secure 219 manner. 221 A self-describing security mechanism is a security mechanism that, 222 when used, contains all necessary information about the method being 223 used as well as all of its parameters such as algorithms. 225 A non-self-describing security mechanism is a security mechanism 226 that, when used, requires that the use of the method or some of its 227 parameters have been agreed beforehand. 229 Most security mechanisms used with SIP are self-describing. The use 230 of HTTP digest, as well as the chosen algorithm is visible from the 231 HTTP authentication headers. The use of S/MIME is indicated by the 232 MIME headers, and the CMS structures inside S/MIME describe the used 233 algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE 234 is used, IKE negotiates all the necessary parameters. 236 The only exception to this list is the use of manually keyed IPsec. 237 IPsec headers do not contain information about the used algorithms. 238 Furthermore, peers have to set up IPsec Security Associations before 239 they can be used to receive traffic. In contrast S/MIME can be 240 received even if no Security Association was in place, because the 241 application can search for a Security Association (or create a new 242 one) after having received a message that contains S/MIME. 244 In order to make it possible to negotiate both self-describing and 245 non-self-describing security mechanisms, we need another requirement 246 on the security agreement scheme: 248 (f) The security agreement scheme must allow both sides to decide on 249 the desired security mechanism before it is actually used. 251 This decision can, and must, take place on both sides before we can 252 be sure that the negotiation has not been tampered by a man-in-the- 253 middle. This tampering will be detected later. 255 3.2. Overview of Operations 257 The message flow below illustrates how the mechanism defined in this 258 document works: 260 1. Client ----------client list---------> Server 261 2. Client <---------server list---------- Server 262 3. Client ------(turn on security)------- Server 263 4. Client ----------server list---------> Server 264 5. Client <---------ok or error---------- Server 266 Figure 1: Security negotiation message flow 268 Step 1: Clients wishing to use this specification can send a list of 269 their supported security mechanisms along the first request to the 270 server. 272 Step 2: Servers wishing to use this specification can challenge the 273 client to perform the security agreement procedure. The security 274 mechanisms and parameters supported by the server are sent along in 275 this challenge. 277 Step 3: The client then proceeds to select the highest-preference 278 security mechanism they have in common and to turn on the selected 279 security. 281 Step 4: The client contacts the server again, now using the selected 282 security mechanism. The server's list of supported security 283 mechanisms is returned as a response to the challenge. 285 Step 5: The server verifies its own list of security mechanisms in 286 order to ensure that the original list had not been modified. 288 This procedure is stateless for servers (unless the used security 289 mechanisms require the server to keep some state). 291 The client and the server lists are both static (i.e., they do not 292 and cannot change based on the input from the other side). Nodes may, 293 however, maintain several static lists, one for each interface, for 294 example. 296 Between Steps 1 and 2, the server may set up a non-self-describing 297 security mechanism if necessary. Note that with this type of security 298 mechanisms, the server is necessarily stateful. The client would set 299 up the non-self-describing security mechanism between Steps 2 and 4. 301 3.3. Syntax 303 We define three new SIP header fields, namely Security-Client, 304 Security-Server and Security-Verify. Their BNF syntax is provided 305 below: 307 security-client = "Security-Client" HCOLON 308 sec-mechanism *(COMMA sec-mechanism) 309 security-server = "Security-Server" HCOLON 310 sec-mechanism *(COMMA sec-mechanism) 311 security-verify = "Security-Verify" HCOLON 312 sec-mechanism *(COMMA sec-mechanism) 313 sec-mechanism = mechanism-name *(SEMI mech-parameters) 314 mechanism-name = ( "digest-integrity" / "tls" / "ipsec-ike" / 315 "ipsec-man" / "smime" / token ) 316 mech-parameters = ( preference / algorithm / extension ) 317 preference = "q" EQUAL qvalue 318 qvalue = ( "0" [ "." 0*3DIGIT ] ) 319 / ( "1" [ "." 0*3("0") ] ) 320 algorithm = "alg" EQUAL token 321 extension = generic-param 323 Note that qvalue is already defined in the SIP BNF [1]. We have 324 copied its definitions here for completeness. 326 The parameters described by the BNF above have the following 327 semantics: 329 Mechanism-name: It identifies the security mechanism supported by 330 the client, when it appears in a Security-Client header fields, or 331 by the server, when it appears in a Security-Server or in a 332 Security-Verify header field. This specification defines five 333 values: 335 - "tls" for TLS [3]. 336 - "digest-integrity" for HTTP Digest [4] using additional 337 integrity protection for the Security-Verify header field. The 338 additional integrity protection consists of using the qop 339 parameter to protect a sipfrag body part [6] that contains the 340 Security-Verify header field. 341 - "ipsec-ike" for IPsec with IKE [2]. 342 - "ipsec-man" for manually keyed IPsec without IKE. 343 - "smime" for S/MIME [5]. 345 Preference: The "q" value indicates a relative preference for the 346 particular mechanism. The higher the value the more preferred the 347 mechanism is. 349 Algorithm: An optional algorithm field for those security 350 mechanisms which are not self-describing or which are vulnerable 351 for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP 352 Digest, the same rules apply as defined in RFC 2617 [4] for the 353 "algorithm" field in HTTP Digest. 355 3.4. Protocol Operation 357 This section deals with the protocol details involved in the 358 negotiation between a SIP entity and its next-hop SIP entity. 359 Throughout the text the next-hop SIP entity is referred to as the 360 first-hop proxy or outbound proxy. However, the reader should bear in 361 mind that a user agent server can also be the next-hop for a proxy 362 or, in absence of proxies, for a user agent client. Note as well that 363 a proxy can also have an outbound proxy. 365 3.4.1 Client Initiated 367 A client wishing to establish some type of security with its first- 368 hop proxy MUST add a Security-Client header field to a request 369 addressed to this proxy (i.e., the destination of the request is the 370 first-hop proxy). This header field contains a list of all the 371 security mechanisms that the client supports. The client SHOULD NOT 372 add preference parameters to this list. The client MUST add both a 373 Require and Proxy-Require header field with the value "sec-agree" to 374 its request. 376 The Security-Client header field is used by the server to include any 377 necessary information in its response. For example, if digest- 378 integrity is the chosen mechanism, the server includes an HTTP 379 authentication challenge in the response. If S/MIME is chosen, the 380 appropriate certificate is included. If the security mechanisms 381 supported by the client do not need any further information to be 382 established (e.g., TLS) the client MAY choose not to include the 383 Security-Client header field in its request. 385 A server receiving an unprotected request that contains a Require or 386 Proxy-Require header field with the value "sec-agree" MUST challenge 387 the client with a 494 (Security Agreement Required) response. The 388 server MUST add a Security-Server header field to this response 389 listing the security mechanisms that the server supports. The server 390 MUST add its list to the response even if there are no common 391 security mechanisms in the client's and server's lists. The servers 392 list MUST NOT depend on the contents of the client's list. 394 The server MUST compare the list received in the Security-Client 395 header field with the list to be sent in the Security-Server header 396 field. When the client receives this response, it will choose the 397 common security mechanism with the highest "q" value. Therefore, the 398 server MUST add the necessary information so that the client can 399 initiate that mechanism (e.g., a WWW-Authenticate header field for 400 digest-integrity). 402 When the client receives a response with a Security-Server header 403 field, it SHOULD choose the security mechanism in the servers list 404 with the highest "q" value among all the mechanisms that are known to 405 the client. Then, it MUST initiate that particular security mechanism 406 as described in Section 3.5. This initiation may be carried out 407 without involving any SIP message exchange (e.g., establishing a TLS 408 connection). 410 If an attacker modified the Security-Client header field in the 411 request, the server may not include in its response the information 412 needed to establish the common security mechanism with the highest 413 preference value (e.g., the WWW-authenticate header field is 414 missing). A client detecting such a lack of information in the 415 response MUST consider the current security negotiation process 416 aborted, and MAY try to start it again by sending a new request with 417 a Security-Client header field as described above. 419 All the subsequent SIP requests sent by the client to that server 420 SHOULD make use of the security mechanism initiated in the previous 421 step. These requests MUST contain a Security-Verify header field 422 that mirrors the servers list received previously in the Security- 423 Server header field. These requests MUST also have both a Require 424 and Proxy-Require header fields with the value "sec-agree". 426 The server MUST check that the security mechanisms listed in the 427 Security-Verify header field of incoming requests correspond to its 428 static list of supported security mechanisms. The server can proceed 429 processing a particular request if, and only if, the list was not 430 modified. If modification of the list is detected, the server MUST 431 challenge the client with a 494 (Security Agreement Required). This 432 response MUST include a challenge with server's unmodified list of 433 supported security mechanisms. If the list was not modified, and the 434 server is a proxy, it MUST remove the "sec-agree" value from both the 435 Require and Proxy-Require header fields, and then remove the header 436 fields if no values remain. 438 Once the security has been negotiated between two SIP entities, the 439 same SIP entities MAY use the same security when communicating with 440 each other in different SIP roles. For example, if a UAC and its 441 outbound proxy negotiate some security, they may try to use the same 442 security for incoming requests (i.e., the UA will be acting as a 443 UAS). 445 The user of a UA MAY be informed about the results of the security 446 mechanism negotiation. The user MAY decline to accept a particular 447 security mechanism, and abort further SIP communications with the 448 peer. 450 3.4.2 Server Initiated 452 A server decides to use the security negotiation described in this 453 document based on local policy. A server that decides to use this 454 negotiation MUST challenge unprotected requests regardless of the 455 presence or the absence of any Require, Proxy-Require or Supported 456 header fields in incoming requests. 458 A server that by policy requires the use of this specification and 459 receives a request that does not have the sec-agree option tag in a 460 Require, Proxy-Require or Supported header field MUST return a 421 461 (Extension Required) response. If the request had the sec-agree 462 option tag in a Supported header field, it MUST return a 494 463 (Security Agreement Required) response. In both situation the server 464 MUST also include in the response a Security-Server header field 465 listing its capabilities and a Require header field with an option- 466 tag "sec-agree" in it. All the Via header field entries in the 467 response except the topmost value MUST be removed. This ensures that 468 the previous hop is the one processing the response (see example in 469 Section 5.3). 471 Clients that support the extension defined in this document MAY add a 472 Supported header field with a value of "sec-agree". In addition to 473 this, clients SHOULD add a Security-Client header field so that they 474 can save a round trip in case the server decides to challenge the 475 request. 477 3.5. Security mechanism initiation 479 Once the client chooses a security mechanism from the list received 480 in the Security-Server header field from the server, it initiates 481 that mechanism. Different mechanisms require different initiation 482 procedures. 484 If TLS is chosen, the client uses the procedures of Section 8.1.2 of 485 [1] to determine the URI to be used as an input to the DNS procedures 486 of [7]. However, if the URI is a sip URI, it MUST treat the scheme as 487 if it were sips, not sip. If the URI scheme is not sip, the request 488 MUST be sent using TLS. 490 If digest-integrity is chosen, the 494 (Security Agreement Required) 491 response will contain an HTTP authentication challenge. The client 492 MUST use the qop parameter to protect a sipfrag body part [6] that 493 contains the Security-Verify header field in the request. Note that 494 digest alone would not fulfill the minimum security requirements of 495 this specification. 497 To use "ipsec-ike", the client attempts to establish an IKE 498 connection to the host part of the Request-URI in the first request 499 to the server. If the IKE connection attempt fails, the agreement 500 procedure MUST be considered to have failed, and MUST be terminated. 502 Note that "ipsec-man" will only work if the communicating SIP 503 entities know which keys and other parameters to use. It is outside 504 the scope of this specification to describe how this information can 505 be made known to the peers. 507 In both IPsec-based mechanisms, it is expected that appropriate 508 policy entries for protecting SIP have been configured or will be 509 created before attempting to use the security agreement procedure, 510 and that SIP communications use port numbers and addresses according 511 to these policy entries. It is outside the scope of this 512 specification to describe how this information can be made known to 513 the peers, but it could be typically configured at the same time as 514 the IKE credentials or manual SAs have been entered. 516 To use S/MIME, the client MUST construct its request using S/MIME. 517 The client may have received the servers certificate in an S/MIME 518 body in the 494 (Security Agreement Required) response. Note that 519 S/MIME can only be used if the next hop SIP entity is a UA. 521 3.6. Duration of Security Associations 523 Once a security mechanism has been negotiated, both the server and 524 the client need to know until when it can be used. All the mechanisms 525 described in this document have a different way to signal the end of 526 a security association. When TLS is used, the termination of the 527 connection indicates that a new negotiation is needed. IKE negotiates 528 the duration of a security association. If the credentials provided 529 by a client using digest-integrity are not longer valid, the server 530 will re-challenge the client. It is assumed that when IPsec-man is 531 used, the same out-of-band mechanism used to distribute keys is used 532 to define the duration of the security association. 534 3.7. Summary of Header Field Use 536 The header fields defined in this document may be used to negotiate 537 the security mechanisms between a UAC and other SIP entities 538 including UAS, proxy, and registrar. Information about the use of 539 headers in relation to SIP methods and proxy processing is summarized 540 in Table 1. 542 Header field where proxy ACK BYE CAN INV OPT REG 544 _________________________________________________________________ 545 Security-Client R ard - o - o o o 546 Security-Server 401,407,421,494 - o - o o o 547 Security-Verify R ard - o - o o o 548 Header field where proxy SUB NOT PRK IFO UPD MSG 550 _________________________________________________________________ 551 Security-Client R ard o o - o o o 552 Security-Server 401,407,421,494 o o - o o o 553 Security-Verify R ard o o - o o o 555 Table 1: Summary of header usage. 557 The "where" column describes the request and response types in which 558 the header field may be used. The header may not appear in other 559 types of SIP messages. Values in the where column are: 561 - R: Header field may appear in requests. 563 - 401, 407 etc.: A numerical value or range indicates response codes 564 with which the header field can be used. 566 The "proxy" column describes the operations a proxy may perform on a 567 header field: 569 - a: A proxy can add or concatenate the header field if not present. 571 - r: A proxy must be able to read the header field, and thus this 572 header field cannot be encrypted. 574 - d: A proxy can delete a header field value. 576 The next six columns relate to the presence of a header field in a 577 method: 579 - o: The header field is optional. 581 4. Backwards Compatibility 583 A server that, by local policy, decides to use the negotiation 584 mechanism defined in this document, will not accept requests from 585 clients that do not support this extension. This obviously breaks 586 interoperability with every plain SIP client. Therefore, this 587 extension should only be used in closed environments where it is 588 ensured somehow that every client implements this extension. 590 5. Examples 592 The following examples illustrate the use of the mechanism defined 593 above. 595 5.1. Client Initiated 597 A UA negotiates the security mechanism to be used with its outbound 598 proxy without knowing beforehand which mechanisms the proxy supports. 600 UAC Proxy UAS 602 | | | 603 |----(1) OPTIONS---->| | 604 | | | 605 |<-----(2) 494-------| | 606 | | | 607 |<=======TLS========>| | 608 | | | 609 |----(3) INVITE----->| | 610 | |----(4) INVITE--->| 611 | | | 612 | |<---(5) 200 OK----| 613 |<---(6) 200 OK------| | 614 | | | 615 |------(7) ACK------>| | 616 | |-----(8) ACK----->| 617 | | | 618 | | | 619 | | | 620 | | | 622 Figure 2: Negotiation initiated by the client 624 The UAC sends an OPTIONS request to its outbound proxy, indicating 625 that it is able to negotiate security mechanisms and that it supports 626 TLS and digest-integrity (Step 1 of figure 1). The outbound proxy 627 challenges the UAC with its own list of security mechanisms IPsec 628 and TLS (Step 2 of figure 1). The only common security mechanism is 629 TLS, so they establish a TLS connection between them (Step 3 of 630 figure 1). When the connection is successfully established, the UAC 631 sends an INVITE over the TLS connection just established (Step 4 of 632 figure 1). This INVITE contains the servers security list. The 633 server verifies it, and since it matches its static list, it 634 processes the INVITE and forwards it to the next hop. 636 If this example was run without Security-Server header in Step 2, the 637 UAC would not know what kind of security the other one supports, and 638 would be forced to error-prone trials. 640 More seriously, if the Security-Verify was omitted in Step 4, the 641 whole process would be prone for MitM attacks. An attacker could 642 spoof "ICMP Port Unreachable" message on the trials, or remove the 643 stronger security option from the header in Step 1, therefore 644 substantially reducing the security. 646 (1) OPTIONS sip:proxy.example.com SIP/2.0 647 Security-Client: tls 648 Security-Client: digest-integrity 649 Require: sec-agree 650 Proxy-Require: sec-agree 652 (2) SIP/2.0 494 Security Agreement Required 653 Security-Server: ipsec-ike;q=0.1 654 Security-Server: tls;q=0.2 656 (3) INVITE sip:proxy.example.com SIP/2.0 657 Security-Verify: ipsec-ike;q=0.1 658 Security-Verify: tls;q=0.2 659 Route: sip:callee@domain.com 660 Require: sec-agree 661 Proxy-Require: sec-agree 663 The 200 OK response for the INVITE and the ACK are also sent over the 664 TLS connection. The ACK (7) will contain the same Security-Verify 665 header field as the INVITE (3). 667 5.2. Server Initiated 669 In this example of figure 3 the client sends an INVITE towards the 670 callee using an outbound proxy. This INVITE does not contain any 671 Require header field. 673 UAC Proxy UAS 675 | | | 676 |-----(1) INVITE---->| | 677 | | | 678 |<-----(2) 421-------| | 679 | | | 680 |------(3) ACK------>| | 681 | | | 682 |<=======IKE========>| | 683 | | | 684 |-----(4) INVITE---->| | 685 | |----(5) INVITE--->| 686 | | | 687 | |<---(6) 200 OK----| 688 |<----(7) 200 OK-----| | 689 | | | 690 |------(8) ACK------>| | 691 | |-----(9) ACK----->| 692 | | | 693 | | | 695 Figure 3: Server initiated security negotiation 697 The proxy, following its local policy, challenges the INVITE. It 698 returns a 421 (Extension Required) with a Security-Server header 699 field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE 700 it performs the key exchange and establishes a security association 701 with the proxy. The second INVITE (4) and the ACK (8) contain a 702 Security-Verify header field that mirrors the Security-Server header 703 field received in the 421. The INVITE (4), the 200 OK (7) and the ACK 704 (8) are sent using the security association that has been 705 established. 707 5.3 Security Negotiation between Proxies 709 The example in Figure 4 shows a security negotiation between two 710 adjacent proxies. P1 forwards an INVITE (2) to P2. P2, by policy, 711 requires that a security negotiation takes place before accepting any 712 request. Therefore, it challenges P1 with a 421 (Extension Required) 713 response (3). P2 removes all the Via entries except the topmost one 714 (i.e., P1) so that P1 itself processes the response rather than 715 forwarding it to the UAC. This 421 response contains a Security- 716 Server header field listing the server's capabilities and a Require 717 header field with an option-tag "sec-agree" in it. P2 includes "TLS" 718 and "ipsec-ike" in the Security-Server header field. P1 sends an ACK 719 (4) for the response and proceeds to establish a TLS connection, 720 since this is the only security mechanism supported by P1. Once the 721 TLS connection is established, session establishment proceeds 722 normally. Messages (5), (8) and (11) are sent using the just 723 established TLS connection. Messages (5) and (11) contain a Security- 724 Verify header field that P2 removes before forwarding them to the 725 UAS. Note that, following normal SIP procedures, P1 uses a different 726 branch ID for INVITE (5) than the one it used for INVITE (2). 728 UAC P1 P2 UAS 729 | | | | 730 |-(1) INVITE->| | | 731 | |-(2) INVITE->| | 732 | | | | 733 | |<--(3) 421---| | 734 | | | | 735 | |---(4) ACK-->| | 736 | | | | 737 | |<====TLS====>| | 738 | | | | 739 | |-(5) INVITE->| | 740 | | |-(6) INVITE->| 741 | | | | 742 | | |<-(7) 200 OK-| 743 | |<-(8) 200 OK-| | 744 |<-(9) 200 OK-| | | 745 | | | | 746 |--(10) ACK-->| | | 747 | |--(11) ACK-->| | 748 | | |--(12) ACK-->| 749 | | | | 751 Figure 4: Negotiation between two proxies 753 6. Security Considerations 755 This specification is about making it possible to select between 756 various SIP security mechanisms in a secure manner. In particular, 757 the method presented here allow current networks using, for instance, 758 Digest, to be securely upgraded to, for instance, IPsec without 759 requiring a simultaneous modification in all equipment. The method 760 presented in this specification is secure only if the weakest 761 proposed mechanism offers at least integrity protection. 763 Attackers could try to modify the server's list of security 764 mechanisms in the first response. This would be revealed to the 765 server when the client returns the received list using the security. 767 Attackers could also try to modify the repeated list in the second 768 request from the client. However, if the selected security mechanism 769 uses encryption this may not be possible, and if it uses integrity 770 protection any modifications will be detected by the server. 772 Finally, attackers could try to modify the client's list of security 773 mechanisms in the first message. The client selects the security 774 mechanism based on its own knowledge of its own capabilities and the 775 server's list, hence the client's choice would be unaffected by any 776 such modification. However, the server's choice could still be 777 affected as described below: 779 - If the modification affected the server's choice, the server and 780 client would end up choosing different security mechanisms in Step 3 781 or 4 of figure 1. Since they would be unable to communicate to each 782 other, this would be detected as a potential attack. The client would 783 either retry or give up in this situation. 785 - If the modification did not affect the server's choice, there's no 786 effect. 788 All clients that implement this specification MUST select HTTP Digest 789 with integrity, TLS, IPsec, or any stronger method for the protection 790 of the second request. If HTTP Digest is used alone, the security 791 agreement headers MUST be protected. This can be done with HTTP 792 Digest if combined with MIME/SIP tunneling, for example. 794 7. IANA Considerations 796 This specification defines three new header fields, namely Security- 797 Client, Security-Server and Security-Verify that should be included 798 in the registry for SIP header fields maintained by IANA. 800 This specification defines the 'sec-agree' SIP option tag which 801 should be registered in IANA. 803 This specification also defines a new SIP status code, 494 (Security 804 Agreement Failed), which should be registered in IANA. 806 8. Acknowledgments 808 The authors wish to thank Lee Valerius, Rolf Blom, James Undery, 809 Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David 810 Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin 811 Euchner, Eric Rescorla and members of the 3GPP SA3 group for 812 interesting discussions in this problem space. 814 9. Normative References 816 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 817 Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation 818 Protocol", Work in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, 819 February 2002. 821 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 822 Protocol", RFC 2401, IETF, November 1998. 824 [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 825 IETF January 1999. 827 [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access 828 Authentication", RFC 2617, IETF, June 1999. 830 [5] B. Ramsdell and Ed, "S/MIME version 3 message specification", RFC 831 2633, IETF, June 1999. 833 [6] R. Sparks, "Internet Media Type message/sipfrag", Work in 834 Progress, draft-sparks-sip-mimetypes-03.txt, IETF, April 2002. 836 [7] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers", 837 Work in Progress, draft-ietf-sip-srv-06.txt, IETF, February 2002. 839 10. Non-Normative References 841 [7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 842 Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", 843 draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, 844 October 2001. 846 11. Authors's Addresses 848 Jari Arkko 849 Ericsson 850 02420 Jorvas 851 Finland 852 EMail: Jari.Arkko@ericsson.com 854 Vesa Torvinen 855 Ericsson 856 02420 Jorvas 857 Finland 858 EMail: Vesa.Torvinen@ericsson.fi 860 Gonzalo Camarillo 861 Ericsson 862 02420 Jorvas 863 Finland 864 EMail: Gonzalo.Camarillo@ericsson.com 866 Tao Haukka 867 Nokia 868 Finland 869 EMail: Tao.Haukka@nokia.com 871 Sanjoy Sen 872 Nortel Networks 873 2735-B Glenville Drive 874 Richardson, TX 75082, USA 875 EMail: sanjoy@nortelnetworks.com