idnits 2.17.1 draft-ietf-sip-sec-agree-02.txt: -(76): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(420): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 65 lines 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 SHOULD add a Security-Clie...' RFC 2119 keyword, line 371: '...client supports. The client SHOULD NOT...' RFC 2119 keyword, line 372: '... this list. The client MUST also add a...' RFC 2119 keyword, line 381: '... TLS) the client MAY choose not to inc...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...hat new metho...' == Line 556 has weird spacing: '... ard o ...' == Line 558 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 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 May 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 minimum 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 experience has shown that algorithm 83 development uncovers problems in old algorithms and produces new 84 ones. Furthermore, different mechanisms and algorithms are suitable 85 for 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 such as HTTP Digest authentication [4], secure attachments such as 91 S/MIME [5], and can also use underlying security protocols such as 92 IPsec/IKE [2] or TLS [3]. Some of the built-in security functionality 93 allows also alternative algorithms and other parameters. While some 94 work within the SIP Working Group has been looking towards reducing 95 the number of recommended security solutions (i.e., recommend just 96 one lower layer security protocol), we can not expect to cut down the 97 number of items in the whole list to one. There will still be 98 multiple security solutions utilized by SIP. Furthermore, it is 99 likely that new methods will appear in the future, to complement the 100 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 six 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 SHOULD 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 also add a 373 Require header field with the value "sec-agree" to its request. 375 The Security-Client header field is used by the server to include any 376 necessary information in its response. For example, if digest- 377 integrity is the chosen mechanism, the server includes a WWW- 378 Authenticate header in the response. If S/MIME is chosen, the 379 appropriate certificate is included. If the security mechanisms 380 supported by the client do not need any further information to be 381 established (e.g., TLS) the client MAY choose not to include the 382 Security-Client header field in its request. 384 A server receiving a request that contains a Require header field 385 with the value "sec-agree" MUST challenge the client with a 494 386 (Security Agreement Required) response. The server MUST add a 387 Security-Server header field to this response listing the security 388 mechanisms that the server supports. The server MUST add its list to 389 the response even if there are no common security mechanisms in the 390 client's and server's lists. The server�s list MUST NOT depend on the 391 contents of the client's list. 393 The server MUST compare the list received in the Security-Client 394 header field with the list to be sent in the Security-Server header 395 field. When the client receives this response, it will choose the 396 common security mechanism with the higher preference value. 397 Therefore, the server MUST add the necessary information so that the 398 client can initiate that mechanism (e.g., a WWW-Authenticate header 399 field for digest-integrity). 401 When the client receives a response with a Security-Server header 402 field, it SHOULD choose the security mechanism in the server�s list 403 with the highest "q" value among all the mechanisms that are known to 404 the client. Then, it MUST initiate that particular security mechanism 405 as described in Section 3.5. This initiation may be carried out 406 without involving any SIP message exchange (e.g., establishing a TLS 407 connection). 409 If an attacker modified the Security-Client header field in the 410 request, the server may not include in its response the information 411 needed to establish the common security mechanism with the highest 412 preference value (e.g., the WWW-authenticate header field is 413 missing). A client detecting such a lack of information in the 414 response MUST consider the current security negotiation process 415 aborted, and MAY try to start it again by sending a new request with 416 a Security-Client header field as described above. 418 All the subsequent SIP requests sent by the client SHOULD make use of 419 the security mechanism initiated in the previous step. These requests 420 MUST contain a Security-Verify header field that mirrors the server�s 421 list received previously in the Security-Server header field. This 422 request MAY use SIP loose routing mechanism (i.e., Route header 423 fields) to traverse the proxy, but its final destination may be 424 different than the proxy. In this case, the request SHOULD NOT 425 include a Require header field with the value "sec-agree". 427 For example, the first request was an OPTIONS request directly 428 addressed to the proxy and the second request is an INVITE that 429 will traverse the proxy but that is addressed to a real user (see 430 example in section 4.1). 432 The server MUST check that the security mechanisms listed in the 433 Security-Verify header field of incoming requests correspond to its 434 static list of supported security mechanisms. The server can proceed 435 processing a particular request if, and only if, the list was not 436 modified. If modification of the list is detected, the server MUST 437 challenge the client with a 494 (Security Agreement Required). This 438 response MUST include a challenge with server's unmodified list of 439 supported security mechanisms. 441 Once the security has been negotiated between two SIP entities, the 442 same SIP entities MAY use the same security when communicating with 443 each other in different SIP roles. For example, if a UAC and its 444 outbound proxy negotiate some security, they may try to use the same 445 security for incoming requests (i.e., the UA will be acting as a 446 UAS). 448 The user of a UA MAY be informed about the results of the security 449 mechanism negotiation. The user MAY decline to accept a particular 450 security mechanism, and abort further SIP communications with the 451 peer. 453 3.4.2 Server Initiated 455 A server decides to use the security negotiation described in this 456 document based on local policy. A server that decides to use this 457 negotiation MUST challenge requests regardless of the presence or the 458 absence of any Require or Supported header fields in incoming 459 requests. 461 A server that by policy requires the use of this specification and 462 receives a request that does not have the sec-agree option tag in a 463 Require or Supported header field MUST return a 421 (Extension 464 Required) response. If the request had the sec-agree option tag in a 465 Supported header field, it MUST return a 494 (Security Agreement 466 Required) response. In both situation the server MUST also include in 467 the response a Security-Server header field listing its capabilities 468 and a Require header field with an option-tag "sec-agree" in it. All 469 the Via header field entries in the response except the topmost value 470 MUST be removed. This ensures that the previous hop is the one 471 processing the response (see example in Section 5.3). 473 Clients that support the extension defined in this document MAY add a 474 Supported header field with a value of "sec-agree". In addition to 475 this, clients SHOULD add a Security-Client header field so that they 476 can save a round trip in case the server decides to challenge the 477 request. 479 3.5. Security mechanism initiation 481 Once the client chooses a security mechanism from the list received 482 in the Security-Server header field from the server, it initiates 483 that mechanism. Different mechanisms require different initiation 484 procedures. 486 If TLS is chosen, the client MUST contact the server using the host 487 part of the topmost Route entry in the first request to the server as 488 the destination of the connection (note that this may involve using 489 standard SIP DNS procedures to locate a server). In the absence of a 490 Route header field, the host part of the Request-URI is used as the 491 destination of the connection instead. If this connection attempt 492 fails, the security agreement procedure MUST be considered to have 493 failed, and MUST be terminated. 495 If digest-integrity is chosen, the 494 (Security Agreement Required) 496 response will contain an HTTP authentication challenge. The client 497 MUST use the qop parameter to protect a sipfrag body part [6] that 498 contains the Security-Verify header field in the request. Note that 499 digest alone would not fulfill the minimum security requirements of 500 this specification. 502 To use "ipsec-ike", the client attempts to establish an IKE 503 connection to the host part of the Request-URI in the first request 504 to the server. If the IKE connection attempt fails, the agreement 505 procedure MUST be considered to have failed, and MUST be terminated. 507 Note that "ipsec-man" will only work if the communicating SIP 508 entities know which keys and other parameters to use. It is outside 509 the scope of this specification to describe how this information can 510 be made known to the peers. 512 In both IPsec-based mechanisms, it is expected that appropriate 513 policy entries for protecting SIP have been configured or will be 514 created before attempting to use the security agreement procedure, 515 and that SIP communications use port numbers and addresses according 516 to these policy entries. It is outside the scope of this 517 specification to describe how this information can be made known to 518 the peers, but it could be typically configured at the same time as 519 the IKE credentials or manual SAs have been entered. 521 To use S/MIME, the client MUST construct its request using S/MIME. 522 The client may have received the server�s certificate in an S/MIME 523 body in the 494 (Security Agreement Required) response. 525 3.6. Duration of Security Associations 527 Once a security mechanism has been negotiated, both the server and 528 the client need to know until when it can be used. All the mechanisms 529 described in this document have a different way to signal the end of 530 a security association. When TLS is used, the termination of the 531 connection indicates that a new negotiation is needed. IKE negotiates 532 the duration of a security association. If the credentials provided 533 by a client using digest-integrity are not longer valid, the server 534 will re-challenge the client. It is assumed that when IPsec-man is 535 used, the same out-of-band mechanism used to distribute keys is used 536 to define the duration of the security association. 538 3.7. Summary of Header Field Use 540 The header fields defined in this document may be used to negotiate 541 the security mechanisms between a UAC and other SIP entities 542 including UAS, proxy, and registrar. Information about the use of 543 headers in relation to SIP methods and proxy processing is summarized 544 in Table 1. 546 Header field where proxy ACK BYE CAN INV OPT REG 548 _________________________________________________________________ 549 Security-Client R ard - o - o o o 550 Security-Server 401,407,421,494 - o - o o o 551 Security-Verify R ard - o - o o o 553 Header field where proxy SUB NOT PRK IFO UPD MSG 555 _________________________________________________________________ 556 Security-Client R ard o o - o o o 557 Security-Server 401,407,421,494 o o - o o o 558 Security-Verify R ard o o - o o o 560 Table 1: Summary of header usage. 562 The "where" column describes the request and response types in which 563 the header field may be used. The header may not appear in other 564 types of SIP messages. Values in the where column are: 566 - R: Header field may appear in requests. 568 - 401, 407 etc.: A numerical value or range indicates response codes 569 with which the header field can be used. 571 The "proxy" column describes the operations a proxy may perform on a 572 header field: 574 - a: A proxy can add or concatenate the header field if not present. 576 - r: A proxy must be able to read the header field, and thus this 577 header field cannot be encrypted. 579 - d: A proxy can delete a header field value. 581 The next six columns relate to the presence of a header field in a 582 method: 584 - o: The header field is optional. 586 4. Backwards Compatibility 588 A server that, by local policy, decides to use the negotiation 589 mechanism defined in this document, will not accept requests from 590 clients that do not support this extension. This obviously breaks 591 interoperability with every plain SIP client. Therefore, this 592 extension should only be used in closed environments where it is 593 ensured somehow that every client implements this extension. 595 5. Examples 597 The following examples illustrate the use of the mechanism defined 598 above. 600 5.1. Client Initiated 602 A UA negotiates the security mechanism to be used with its outbound 603 proxy without knowing beforehand which mechanisms the proxy supports. 605 UAC Proxy UAS 607 | | | 608 |----(1) OPTIONS---->| | 609 | | | 610 |<-----(2) 494-------| | 611 | | | 612 |<=======TLS========>| | 613 | | | 614 |----(3) INVITE----->| | 615 | |----(4) INVITE--->| 616 | | | 617 | |<---(5) 200 OK----| 618 |<---(6) 200 OK------| | 619 | | | 620 |------(7) ACK------>| | 621 | |-----(8) ACK----->| 622 | | | 623 | | | 624 | | | 625 | | | 627 Figure 2: Negotiation initiated by the client 629 The UAC sends an OPTIONS request to its outbound proxy, indicating 630 that it is able to negotiate security mechanisms and that it supports 631 TLS and digest-integrity (Step 1 of figure 1). The outbound proxy 632 challenges the UAC with its own list of security mechanisms � IPsec 633 and TLS (Step 2 of figure 1). The only common security mechanism is 634 TLS, so they establish a TLS connection between them (Step 3 of 635 figure 1). When the connection is successfully established, the UAC 636 sends an INVITE over the TLS connection just established (Step 4 of 637 figure 1). This INVITE contains the server�s security list. The 638 server verifies it, and since it matches its static list, it 639 processes the INVITE and forwards it to the next hop. 641 If this example was run without Security-Server header in Step 2, the 642 UAC would not know what kind of security the other one supports, and 643 would be forced to error-prone trials. 645 More seriously, if the Security-verify was omitted in Step 4, the 646 whole process would be prone for MitM attacks. An attacker could 647 spoof "ICMP Port Unreachable" message on the trials, or remove the 648 stronger security option from the header in Step 1, therefore 649 substantially reducing the security. 651 (1) OPTIONS sip:proxy.example.com SIP/2.0 652 Security-Client: tls;q=0.1 653 Security-Client: digest-integrity;q=0.2 654 Require: sec-agree 656 (2) SIP/2.0 494 Security Agreement Required 657 Security-Server: ipsec-ike;q=0.1 658 Security-Server: tls;q=0.2 660 (3) INVITE sip:proxy.example.com SIP/2.0 661 Security-Verify: ipsec-ike;q=0.1 662 Security-Verify: tls;q=0.2 663 Route: sip:callee@domain.com 665 The 200 OK response for the INVITE and the ACK are also sent over the 666 TLS connection. The ACK (7) will contain the same Security-Verify 667 header field as the INVITE (3). 669 5.2. Server Initiated 671 In this example of figure 3 the client sends an INVITE towards the 672 callee using an outbound proxy. This INVITE does not contain any 673 Require header field. 675 UAC Proxy UAS 677 | | | 678 |-----(1) INVITE---->| | 679 | | | 680 |<-----(2) 421-------| | 681 | | | 682 |------(3) ACK------>| | 683 | | | 684 |<=======IKE========>| | 685 | | | 686 |-----(4) INVITE---->| | 687 | |----(5) INVITE--->| 688 | | | 689 | |<---(6) 200 OK----| 690 |<----(7) 200 OK-----| | 691 | | | 692 |------(8) ACK------>| | 693 | |-----(9) ACK----->| 694 | | | 695 | | | 697 Figure 3: Server initiated security negotiation 699 The proxy, following its local policy, challenges the INVITE. It 700 returns a 421 (Extension Required) with a Security-Server header 701 field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE 702 it performs the key exchange and establishes a security association 703 with the proxy. The second INVITE (4) and the ACK (8) contain a 704 Security-Verify header field that mirrors the Security-Server header 705 field received in the 421. The INVITE (4), the 200 OK (7) and the ACK 706 (8) are sent using the security association that has been 707 established. 709 5.3 Security Negotiation between Proxies 711 The example in Figure 4 shows a security negotiation between two 712 adjacent proxies. P1 forwards an INVITE (2) to P2. P2, by policy, 713 requires that a security negotiation takes place before accepting any 714 request. Therefore, it challenges P1 with a 421 (Extension Required) 715 response (3). P2 removes all the Via entries except the topmost one 716 (i.e., P1) so that P1 itself processes the response rather than 717 forwarding it to the UAC. This 421 response contains a Security- 718 Server header field listing the server's capabilities and a Require 719 header field with an option-tag "sec-agree" in it. P2 includes "TLS" 720 and "ipsec-ike" in the Security-Server header field. P1 sends an ACK 721 (4) for the response and proceeds to establish a TLS connection, 722 since this is the only security mechanism supported by P1. Once the 723 TLS connection is established, session establishment proceeds 724 normally. Messages (5), (8) and (11) are sent using the just 725 established TLS connection. Messages (5) and (11) contain a Security- 726 Verify header field that P2 removes before forwarding them to the 727 UAS. Note that, following normal SIP procedures, P1 uses a different 728 branch ID for INVITE (5) than the one it used for INVITE (2). 730 UAC P1 P2 UAS 731 | | | | 732 |-(1) INVITE->| | | 733 | |-(2) INVITE->| | 734 | | | | 735 | |<--(3) 421---| | 736 | | | | 737 | |---(4) ACK-->| | 738 | | | | 739 | |<====TLS====>| | 740 | | | | 741 | |-(5) INVITE->| | 742 | | |-(6) INVITE->| 743 | | | | 744 | | |<-(7) 200 OK-| 745 | |<-(8) 200 OK-| | 746 |<-(9) 200 OK-| | | 747 | | | | 748 |--(10) ACK-->| | | 749 | |--(11) ACK-->| | 750 | | |--(12) ACK-->| 751 | | | | 753 Figure 4: Negotiation between two proxies 755 6. Security Considerations 757 This specification is about making it possible to select between 758 various SIP security mechanisms in a secure manner. In particular, 759 the method presented here allow current networks using, for instance, 760 Digest, to be securely upgraded to, for instance, IPsec without 761 requiring a simultaneous modification in all equipment. The method 762 presented in this specification is secure only if the weakest 763 proposed mechanism offers at least integrity protection. 765 Attackers could try to modify the server's list of security 766 mechanisms in the first response. This would be revealed to the 767 server when the client returns the received list using the security. 769 Attackers could also try to modify the repeated list in the second 770 request from the client. However, if the selected security mechanism 771 uses encryption this may not be possible, and if it uses integrity 772 protection any modifications will be detected by the server. 774 Finally, attackers could try to modify the client's list of security 775 mechanisms in the first message. The client selects the security 776 mechanism based on its own knowledge of its own capabilities and the 777 server's list, hence the client's choice would be unaffected by any 778 such modification. However, the server's choice could still be 779 affected as described below: 781 - If the modification affected the server's choice, the server and 782 client would end up choosing different security mechanisms in Step 3 783 or 4 of figure 1. Since they would be unable to communicate to each 784 other, this would be detected as a potential attack. The client would 785 either retry or give up in this situation. 787 - If the modification did not affect the server's choice, there's no 788 effect. 790 All clients that implement this specification MUST select HTTP Digest 791 with integrity, TLS, IPsec, or any stronger method for the protection 792 of the second request. If HTTP Digest is used alone, the security 793 agreement headers MUST be protected. This can be done with HTTP 794 Digest if combined with MIME/SIP tunneling, for example. 796 7. IANA Considerations 798 This specification defines three new header fields, namely Security- 799 Client, Security-Server and Security-Verify that should be included 800 in the registry for SIP header fields maintained by IANA. 802 This specification defines the 'sec-agree' SIP option tag which 803 should be registered in IANA. 805 This specification also defines a new SIP status code, 494 (Security 806 Agreement Failed), which should be registered in IANA. 808 8. Acknowledgments 810 The authors wish to thank Lee Valerius, Rolf Blom, James Undery, 811 Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David 812 Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin 813 Euchner, Eric Rescorla and members of the 3GPP SA3 group for 814 interesting discussions in this problem space. 816 9. Normative References 818 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 819 Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation 820 Protocol", Work in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, 821 February 2002. 823 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 824 Protocol", RFC 2401, IETF, November 1998. 826 [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 827 IETF January 1999. 829 [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access 830 Authentication", RFC 2617, IETF, June 1999. 832 [5] B. Ramsdell and Ed, "S/MIME version 3 message specification", RFC 833 2633, IETF, June 1999. 835 [6] R. Sparks, "Internet Media Type message/sipfrag", Work in 836 Progress, draft-sparks-sip-mimetypes-03.txt, IETF, April 2002. 838 10. Non-Normative References 840 [7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 841 Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", 842 draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, 843 October 2001. 845 11. Authors's Addresses 847 Jari Arkko 848 Ericsson 849 02420 Jorvas 850 Finland 851 EMail: Jari.Arkko@ericsson.com 853 Vesa Torvinen 854 Ericsson 855 02420 Jorvas 856 Finland 857 EMail: Vesa.Torvinen@ericsson.fi 859 Gonzalo Camarillo 860 Ericsson 861 02420 Jorvas 862 Finland 863 EMail: Gonzalo.Camarillo@ericsson.com 865 Tao Haukka 866 Nokia 867 Finland 868 EMail: Tao.Haukka@nokia.com 870 Sanjoy Sen 871 Nortel Networks 872 2735-B Glenville Drive 873 Richardson, TX 75082, USA 874 EMail: sanjoy@nortelnetworks.com