idnits 2.17.1 draft-ietf-sip-sec-agree-04.txt: -(76): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(501): 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 8 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 17 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 348: '...urity mechanisms MUST have different "...' RFC 2119 keyword, line 371: '... hop proxy MUST add a Security-Client...' RFC 2119 keyword, line 374: '...client supports. The client SHOULD NOT...' RFC 2119 keyword, line 375: '... this list. The client MUST add both a...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...hat new metho...' == Line 382 has weird spacing: '...allenge in th...' == Line 560 has weird spacing: '... ard o ...' == Line 562 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 (~~), 8 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 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 link delays are 204 relatively high, and an additional roundtrip could delay the call 205 set up further. 207 (e) It does not introduce any additional state to servers and 208 proxies. 210 Currently, SIP does not have any mechanism which fulfills all the 211 requirements above. The basic SIP features such as OPTIONS and 212 Require, Supported headers are capable of informing peers about 213 various capabilities including security mechanisms. However, the 214 straight forward use of these features can not guarantee a secured 215 agreement. HTTP Digest algorithm lists [4] are not secure for picking 216 among the digest integrity algorithms, as is described in the HTTP 217 authentication RFC [4] itself. More seriously, they have no 218 provisions for allowing encryption to be negotiated. Hence, it would 219 be hard to turn on possible future encryption schemes in a secure 220 manner. 222 A self-describing security mechanism is a security mechanism that, 223 when used, contains all necessary information about the method being 224 used as well as all of its parameters such as algorithms. 226 A non-self-describing security mechanism is a security mechanism 227 that, when used, requires that the use of the method or some of its 228 parameters have been agreed beforehand. 230 Most security mechanisms used with SIP are self-describing. The use 231 of HTTP digest, as well as the chosen algorithm is visible from the 232 HTTP authentication headers. The use of S/MIME is indicated by the 233 MIME headers, and the CMS structures inside S/MIME describe the used 234 algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE 235 is used, IKE negotiates all the necessary parameters. 237 The only exception to this list is the use of manually keyed IPsec. 238 IPsec headers do not contain information about the used algorithms. 239 Furthermore, peers have to set up IPsec Security Associations before 240 they can be used to receive traffic. In contrast S/MIME can be 241 received even if no Security Association was in place, because the 242 application can search for a Security Association (or create a new 243 one) after having received a message that contains S/MIME. 245 In order to make it possible to negotiate both self-describing and 246 non-self-describing security mechanisms, we need another requirement 247 on the security agreement scheme: 249 (f) The security agreement scheme must allow both sides to decide on 250 the desired security mechanism before it is actually used. 252 This decision can, and must, take place on both sides before we can 253 be sure that the negotiation has not been tampered by a man-in-the- 254 middle. This tampering will be detected later. 256 3.2. Overview of Operations 258 The message flow below illustrates how the mechanism defined in this 259 document works: 261 1. Client ----------client list---------> Server 262 2. Client <---------server list---------- Server 263 3. Client ------(turn on security)------- Server 264 4. Client ----------server list---------> Server 265 5. Client <---------ok or error---------- Server 267 Figure 1: Security negotiation message flow 269 Step 1: Clients wishing to use this specification can send a list of 270 their supported security mechanisms along the first request to the 271 server. 273 Step 2: Servers wishing to use this specification can challenge the 274 client to perform the security agreement procedure. The security 275 mechanisms and parameters supported by the server are sent along in 276 this challenge. 278 Step 3: The client then proceeds to select the highest-preference 279 security mechanism they have in common and to turn on the selected 280 security. 282 Step 4: The client contacts the server again, now using the selected 283 security mechanism. The server's list of supported security 284 mechanisms is returned as a response to the challenge. 286 Step 5: The server verifies its own list of security mechanisms in 287 order to ensure that the original list had not been modified. 289 This procedure is stateless for servers (unless the used security 290 mechanisms require the server to keep some state). 292 The client and the server lists are both static (i.e., they do not 293 and cannot change based on the input from the other side). Nodes may, 294 however, maintain several static lists, one for each interface, for 295 example. 297 Between Steps 1 and 2, the server may set up a non-self-describing 298 security mechanism if necessary. Note that with this type of security 299 mechanisms, the server is necessarily stateful. The client would set 300 up the non-self-describing security mechanism between Steps 2 and 4. 302 3.3. Syntax 304 We define three new SIP header fields, namely Security-Client, 305 Security-Server and Security-Verify. Their BNF syntax is provided 306 below: 308 security-client = "Security-Client" HCOLON 309 sec-mechanism *(COMMA sec-mechanism) 310 security-server = "Security-Server" HCOLON 311 sec-mechanism *(COMMA sec-mechanism) 312 security-verify = "Security-Verify" HCOLON 313 sec-mechanism *(COMMA sec-mechanism) 314 sec-mechanism = mechanism-name *(SEMI mech-parameters) 315 mechanism-name = ( "digest-integrity" / "tls" / "ipsec-ike" / 316 "ipsec-man" / "smime" / token ) 317 mech-parameters = ( preference / algorithm / extension ) 318 preference = "q" EQUAL qvalue 319 qvalue = ( "0" [ "." 0*3DIGIT ] ) 320 / ( "1" [ "." 0*3("0") ] ) 321 algorithm = "alg" EQUAL token 322 extension = generic-param 324 Note that qvalue is already defined in the SIP BNF [1]. We have 325 copied its definitions here for completeness. 327 The parameters described by the BNF above have the following 328 semantics: 330 Mechanism-name: It identifies the security mechanism supported by 331 the client, when it appears in a Security-Client header fields, or 332 by the server, when it appears in a Security-Server or in a 333 Security-Verify header field. This specification defines five 334 values: 336 - "tls" for TLS [3]. 337 - "digest-integrity" for HTTP Digest [4] using additional 338 integrity protection for the Security-Verify header field. The 339 additional integrity protection consists of using the qop 340 parameter to protect a MIME body (e.g., "message/sip") that 341 contains the Security-Verify header field. 342 - "ipsec-ike" for IPsec with IKE [2]. 343 - "ipsec-man" for manually keyed IPsec without IKE. 344 - "smime" for S/MIME [5]. 346 Preference: The "q" value indicates a relative preference for the 347 particular mechanism. The higher the value the more preferred the 348 mechanism is. All the security mechanisms MUST have different "q" 349 values. It is an error to provide two mechanisms with the same "q" 350 value. 352 Algorithm: An optional algorithm field for those security 353 mechanisms which are not self-describing or which are vulnerable 354 for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP 355 Digest, the same rules apply as defined in RFC 2617 [4] for the 356 "algorithm" field in HTTP Digest. 358 3.4. Protocol Operation 360 This section deals with the protocol details involved in the 361 negotiation between a SIP entity and its next-hop SIP entity. 362 Throughout the text the next-hop SIP entity is referred to as the 363 first-hop proxy or outbound proxy. However, the reader should bear in 364 mind that a user agent server can also be the next-hop for a proxy 365 or, in absence of proxies, for a user agent client. Note as well that 366 a proxy can also have an outbound proxy. 368 3.4.1 Client Initiated 370 A client wishing to establish some type of security with its first- 371 hop proxy MUST add a Security-Client header field to a request 372 addressed to this proxy (i.e., the destination of the request is the 373 first-hop proxy). This header field contains a list of all the 374 security mechanisms that the client supports. The client SHOULD NOT 375 add preference parameters to this list. The client MUST add both a 376 Require and Proxy-Require header field with the value "sec-agree" to 377 its request. 379 The Security-Client header field is used by the server to include any 380 necessary information in its response. For example, if digest- 381 integrity is the chosen mechanism, the server includes an HTTP 382 authentication challenge in the response. If S/MIME is chosen, the 383 appropriate certificate is included. 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 server�s 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 MUST choose the security mechanism in the server�s 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 that 422 mirrors the server�s list received previously in the Security-Server 423 header field. These requests MUST also have both a Require and Proxy- 424 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. 430 Note that, following the standard SIP header field comparison rules 431 defined in [1], both lists have to contain the same security 432 mechanisms in the same order to be considered equivalent. In 433 addition, for each particular security mechanism, its parameters in 434 both lists need to have the same values. 436 The server can proceed processing a particular request if, and only 437 if, the list was not modified. If modification of the list is 438 detected, the server MUST challenge the client with a 494 (Security 439 Agreement Required). This response MUST include a challenge with 440 server's unmodified list of supported security mechanisms. If the 441 list was not modified, and the server is a proxy, it MUST remove the 442 "sec-agree" value from both the Require and Proxy-Require header 443 fields, and then remove the header fields if no values remain. 445 Once the security has been negotiated between two SIP entities, the 446 same SIP entities MAY use the same security when communicating with 447 each other in different SIP roles. For example, if a UAC and its 448 outbound proxy negotiate some security, they may try to use the same 449 security for incoming requests (i.e., the UA will be acting as a 450 UAS). 452 The user of a UA SHOULD be informed about the results of the security 453 mechanism negotiation. The user MAY decline to accept a particular 454 security mechanism, and abort further SIP communications with the 455 peer. 457 3.4.2 Server Initiated 459 A server decides to use the security negotiation described in this 460 document based on local policy. A server that decides to use this 461 negotiation MUST challenge unprotected requests regardless of the 462 presence or the absence of any Require, Proxy-Require or Supported 463 header fields in incoming requests. 465 A server that by policy requires the use of this specification and 466 receives a request that does not have the sec-agree option tag in a 467 Require, Proxy-Require or Supported header field MUST return a 421 468 (Extension Required) response. If the request had the sec-agree 469 option tag in a Supported header field, it MUST return a 494 470 (Security Agreement Required) response. In both situation the server 471 MUST also include in the response a Security-Server header field 472 listing its capabilities and a Require header field with an option- 473 tag "sec-agree" in it. All the Via header field entries in the 474 response except the topmost value MUST be removed. This ensures that 475 the previous hop is the one processing the response (see example in 476 Section 5.3). 478 Clients that support the extension defined in this document MAY add a 479 Supported header field with a value of "sec-agree". In addition to 480 this, clients SHOULD add a Security-Client header field so that they 481 can save a round trip in case the server decides to challenge the 482 request. 484 3.5. Security mechanism initiation 486 Once the client chooses a security mechanism from the list received 487 in the Security-Server header field from the server, it initiates 488 that mechanism. Different mechanisms require different initiation 489 procedures. 491 If TLS is chosen, the client uses the procedures of Section 8.1.2 of 492 [1] to determine the URI to be used as an input to the DNS procedures 493 of [6]. However, if the URI is a sip URI, it MUST treat the scheme as 494 if it were sips, not sip. If the URI scheme is not sip, the request 495 MUST be sent using TLS. 497 If digest-integrity is chosen, the 494 (Security Agreement Required) 498 response will contain an HTTP Digest authentication challenge. The 499 client MUST use the qop parameter to protect a MIME body (e.g., 500 "message/sip") that contains the Security-Verify header field in the 501 request. Currently, only the qop value �auth-int� is able to provide 502 required protection. Note that digest alone without placing Security- 503 Verify header in the body would not fulfill the minimum security 504 requirements of this specification. 506 To use "ipsec-ike", the client attempts to establish an IKE 507 connection to the host part of the Request-URI in the first request 508 to the server. If the IKE connection attempt fails, the agreement 509 procedure MUST be considered to have failed, and MUST be terminated. 511 Note that "ipsec-man" will only work if the communicating SIP 512 entities know which keys and other parameters to use. It is outside 513 the scope of this specification to describe how this information can 514 be made known to the peers. 516 In both IPsec-based mechanisms, it is expected that appropriate 517 policy entries for protecting SIP have been configured or will be 518 created before attempting to use the security agreement procedure, 519 and that SIP communications use port numbers and addresses according 520 to these policy entries. It is outside the scope of this 521 specification to describe how this information can be made known to 522 the peers, but it could be typically configured at the same time as 523 the IKE credentials or manual SAs have been entered. 525 To use S/MIME, the client MUST construct its request using S/MIME. 526 The client may have received the server�s certificate in an S/MIME 527 body in the 494 (Security Agreement Required) response. Note that 528 S/MIME can only be used if the next hop SIP entity is a UA. 530 3.6. Duration of Security Associations 532 Once a security mechanism has been negotiated, both the server and 533 the client need to know until when it can be used. All the mechanisms 534 described in this document have a different way to signal the end of 535 a security association. When TLS is used, the termination of the 536 connection indicates that a new negotiation is needed. IKE negotiates 537 the duration of a security association. If the credentials provided 538 by a client using digest-integrity are not longer valid, the server 539 will re-challenge the client. It is assumed that when IPsec-man is 540 used, the same out-of-band mechanism used to distribute keys is used 541 to define the duration of the security association. 543 3.7. Summary of Header Field Use 545 The header fields defined in this document may be used to negotiate 546 the security mechanisms between a UAC and other SIP entities 547 including UAS, proxy, and registrar. Information about the use of 548 headers in relation to SIP methods and proxy processing is summarized 549 in Table 1. 551 Header field where proxy ACK BYE CAN INV OPT REG 552 _________________________________________________________________ 553 Security-Client R ard - o - o o o 554 Security-Server 401,407,421,494 - o - o o o 555 Security-Verify R ard - o - o o o 557 Header field where proxy SUB NOT PRK IFO UPD MSG 559 _________________________________________________________________ 560 Security-Client R ard o o - o o o 561 Security-Server 401,407,421,494 o o - o o o 562 Security-Verify R ard o o - o o o 564 Table 1: Summary of header usage. 566 The "where" column describes the request and response types in which 567 the header field may be used. The header may not appear in other 568 types of SIP messages. Values in the where column are: 570 - R: Header field may appear in requests. 572 - 401, 407 etc.: A numerical value or range indicates response codes 573 with which the header field can be used. 575 The "proxy" column describes the operations a proxy may perform on a 576 header field: 578 - a: A proxy can add or concatenate the header field if not present. 580 - r: A proxy must be able to read the header field, and thus this 581 header field cannot be encrypted. 583 - d: A proxy can delete a header field value. 585 The next six columns relate to the presence of a header field in a 586 method: 588 - o: The header field is optional. 590 4. Backwards Compatibility 592 A server that, by local policy, decides to use the negotiation 593 mechanism defined in this document, will not accept requests from 594 clients that do not support this extension. This obviously breaks 595 interoperability with every plain SIP client. Therefore, this 596 extension should be used in environments where it is somehow ensured 597 that every client implements this extension. This extension may also 598 be used in environments where insecure communication is not 599 acceptable if the option of not being able to communicate is also 600 accepted. 602 5. Examples 604 The following examples illustrate the use of the mechanism defined 605 above. 607 5.1. Client Initiated 609 A UA negotiates the security mechanism to be used with its outbound 610 proxy without knowing beforehand which mechanisms the proxy supports. 612 UAC Proxy UAS 614 | | | 615 |----(1) OPTIONS---->| | 616 | | | 617 |<-----(2) 494-------| | 618 | | | 619 |<=======TLS========>| | 620 | | | 621 |----(3) INVITE----->| | 622 | |----(4) INVITE--->| 623 | | | 624 | |<---(5) 200 OK----| 625 |<---(6) 200 OK------| | 626 | | | 627 |------(7) ACK------>| | 628 | |-----(8) ACK----->| 629 | | | 630 | | | 631 | | | 632 | | | 634 Figure 2: Negotiation initiated by the client 636 The UAC sends an OPTIONS request to its outbound proxy, indicating 637 that it is able to negotiate security mechanisms and that it supports 638 TLS and digest-integrity (Step 1 of figure 1). The outbound proxy 639 challenges the UAC with its own list of security mechanisms � IPsec 640 and TLS (Step 2 of figure 1). The only common security mechanism is 641 TLS, so they establish a TLS connection between them (Step 3 of 642 figure 1). When the connection is successfully established, the UAC 643 sends an INVITE over the TLS connection just established (Step 4 of 644 figure 1). This INVITE contains the server�s security list. The 645 server verifies it, and since it matches its static list, it 646 processes the INVITE and forwards it to the next hop. 648 If this example was run without Security-Server header in Step 2, the 649 UAC would not know what kind of security the other one supports, and 650 would be forced to error-prone trials. 652 More seriously, if the Security-Verify was omitted in Step 4, the 653 whole process would be prone for MitM attacks. An attacker could 654 spoof "ICMP Port Unreachable" message on the trials, or remove the 655 stronger security option from the header in Step 1, therefore 656 substantially reducing the security. 658 (1) OPTIONS sip:proxy.example.com SIP/2.0 659 Security-Client: tls 660 Security-Client: digest-integrity 661 Require: sec-agree 662 Proxy-Require: sec-agree 664 (2) SIP/2.0 494 Security Agreement Required 665 Security-Server: ipsec-ike;q=0.1 666 Security-Server: tls;q=0.2 668 (3) INVITE sip:proxy.example.com SIP/2.0 669 Security-Verify: ipsec-ike;q=0.1 670 Security-Verify: tls;q=0.2 671 Route: sip:callee@domain.com 672 Require: sec-agree 673 Proxy-Require: sec-agree 675 The 200 OK response for the INVITE and the ACK are also sent over the 676 TLS connection. The ACK (7) will contain the same Security-Verify 677 header field as the INVITE (3). 679 5.2. Server Initiated 681 In this example of figure 3 the client sends an INVITE towards the 682 callee using an outbound proxy. This INVITE does not contain any 683 Require header field. 685 UAC Proxy UAS 687 | | | 688 |-----(1) INVITE---->| | 689 | | | 690 |<-----(2) 421-------| | 691 | | | 692 |------(3) ACK------>| | 693 | | | 694 |<=======IKE========>| | 695 | | | 696 |-----(4) INVITE---->| | 697 | |----(5) INVITE--->| 698 | | | 699 | |<---(6) 200 OK----| 700 |<----(7) 200 OK-----| | 701 | | | 702 |------(8) ACK------>| | 703 | |-----(9) ACK----->| 704 | | | 705 | | | 707 Figure 3: Server initiated security negotiation 709 The proxy, following its local policy, challenges the INVITE. It 710 returns a 421 (Extension Required) with a Security-Server header 711 field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE 712 it performs the key exchange and establishes a security association 713 with the proxy. The second INVITE (4) and the ACK (8) contain a 714 Security-Verify header field that mirrors the Security-Server header 715 field received in the 421. The INVITE (4), the 200 OK (7) and the ACK 716 (8) are sent using the security association that has been 717 established. 719 5.3 Security Negotiation between Proxies 721 The example in Figure 4 shows a security negotiation between two 722 adjacent proxies. P1 forwards an INVITE (2) to P2. P2, by policy, 723 requires that a security negotiation takes place before accepting any 724 request. Therefore, it challenges P1 with a 421 (Extension Required) 725 response (3). P2 removes all the Via entries except the topmost one 726 (i.e., P1) so that P1 itself processes the response rather than 727 forwarding it to the UAC. This 421 response contains a Security- 728 Server header field listing the server's capabilities and a Require 729 header field with an option-tag "sec-agree" in it. P2 includes "TLS" 730 and "ipsec-ike" in the Security-Server header field. P1 sends an ACK 731 (4) for the response and proceeds to establish a TLS connection, 732 since this is the only security mechanism supported by P1. Once the 733 TLS connection is established, session establishment proceeds 734 normally. Messages (5), (8) and (11) are sent using the just 735 established TLS connection. Messages (5) and (11) contain a Security- 736 Verify header field that P2 removes before forwarding them to the 737 UAS. Note that, following normal SIP procedures, P1 uses a different 738 branch ID for INVITE (5) than the one it used for INVITE (2). 740 UAC P1 P2 UAS 741 | | | | 742 |-(1) INVITE->| | | 743 | |-(2) INVITE->| | 744 | | | | 745 | |<--(3) 421---| | 746 | | | | 747 | |---(4) ACK-->| | 748 | | | | 749 | |<====TLS====>| | 750 | | | | 751 | |-(5) INVITE->| | 752 | | |-(6) INVITE->| 753 | | | | 754 | | |<-(7) 200 OK-| 755 | |<-(8) 200 OK-| | 756 |<-(9) 200 OK-| | | 757 | | | | 758 |--(10) ACK-->| | | 759 | |--(11) ACK-->| | 760 | | |--(12) ACK-->| 761 | | | | 763 Figure 4: Negotiation between two proxies 765 6. Security Considerations 767 This specification is about making it possible to select between 768 various SIP security mechanisms in a secure manner. In particular, 769 the method presented here allow current networks using, for instance, 770 Digest, to be securely upgraded to, for instance, IPsec without 771 requiring a simultaneous modification in all equipment. The method 772 presented in this specification is secure only if the weakest 773 proposed mechanism offers at least integrity protection. 775 Attackers could try to modify the server's list of security 776 mechanisms in the first response. This would be revealed to the 777 server when the client returns the received list using the security. 779 Attackers could also try to modify the repeated list in the second 780 request from the client. However, if the selected security mechanism 781 uses encryption this may not be possible, and if it uses integrity 782 protection any modifications will be detected by the server. 784 Finally, attackers could try to modify the client's list of security 785 mechanisms in the first message. The client selects the security 786 mechanism based on its own knowledge of its own capabilities and the 787 server's list, hence the client's choice would be unaffected by any 788 such modification. However, the server's choice could still be 789 affected as described below: 791 - If the modification affected the server's choice, the server and 792 client would end up choosing different security mechanisms in Step 3 793 or 4 of figure 1. Since they would be unable to communicate to each 794 other, this would be detected as a potential attack. The client would 795 either retry or give up in this situation. 797 - If the modification did not affect the server's choice, there's no 798 effect. 800 All clients that implement this specification MUST select HTTP Digest 801 with integrity, TLS, IPsec, or any stronger method for the protection 802 of the second request. 804 7. IANA Considerations 806 This specification defines three new header fields, namely Security- 807 Client, Security-Server and Security-Verify that should be included 808 in the registry for SIP header fields maintained by IANA. 810 This specification defines the 'sec-agree' SIP option tag which 811 should be registered in IANA. 813 This specification also defines a new SIP status code, 494 (Security 814 Agreement Failed), which should be registered in IANA. 816 8. Acknowledgments 817 The authors wish to thank Lee Valerius, Allison Mankin, Rolf Blom, 818 James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister 819 Boman, David Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri 820 Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3 821 group for interesting discussions in this problem space. 823 9. Normative References 825 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 826 Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation 827 Protocol", Work in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, 828 February 2002. 830 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 831 Protocol", RFC 2401, IETF, November 1998. 833 [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 834 IETF January 1999. 836 [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access 837 Authentication", RFC 2617, IETF, June 1999. 839 [5] B. Ramsdell and Ed, "S/MIME version 3 message specification", RFC 840 2633, IETF, June 1999. 842 [6] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers", 843 Work in Progress, draft-ietf-sip-srv-06.txt, IETF, February 2002. 845 10. Non-Normative References 847 [7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 848 Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", 849 draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, 850 October 2001. 852 11. Authors's Addresses 854 Jari Arkko 855 Ericsson 856 02420 Jorvas 857 Finland 858 EMail: Jari.Arkko@ericsson.com 860 Vesa Torvinen 861 Ericsson 862 02420 Jorvas 863 Finland 864 EMail: Vesa.Torvinen@ericsson.fi 866 Gonzalo Camarillo 867 Ericsson 868 02420 Jorvas 869 Finland 870 EMail: Gonzalo.Camarillo@ericsson.com 871 Tao Haukka 872 Nokia 873 Finland 874 EMail: Tao.Haukka@nokia.com 876 Sanjoy Sen 877 Nortel Networks 878 2735-B Glenville Drive 879 Richardson, TX 75082, USA 880 EMail: sanjoy@nortelnetworks.com