idnits 2.17.1 draft-ietf-sip-sec-agree-01.txt: -(77): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(387): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(408): 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 10 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 147: '...of security mechanisms MUST be secure....' RFC 2119 keyword, line 365: '... hop proxy SHOULD add a Security-Clie...' RFC 2119 keyword, line 368: '...client supports. The client SHOULD NOT...' RFC 2119 keyword, line 369: '... this list. The client MUST also add a...' RFC 2119 keyword, line 378: '... TLS) the client MAY choose not to inc...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 100 has weird spacing: '...hat new metho...' == Line 542 has weird spacing: '... ard o ...' == Line 544 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 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 over a connection. 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 user agent 47 client and its next hop SIP entity. A SIP entity applying this 48 mechanism must always require some minimum security (i.e. integrity 49 protection) from all communicating parties in order to secure the 50 negotiation, but the negotiation can agree on which specific minimum 51 security is used. 53 TABLE OF CONTENTS 55 1. Introduction....................................................2 56 2. The Problem.....................................................3 57 3. Solution........................................................4 58 3.1. Requirements...............................................4 59 3.2. Overview of Operations.....................................5 60 3.3. Syntax.....................................................6 61 3.4. Protocol Operation.........................................7 62 3.4.1 Client Initiated........................................7 63 3.4.2 Server Initiated........................................8 64 3.5. Security Mechanism Initiation..............................9 65 3.6. Duration of the Security Association......................10 66 3.7. Summary of Header Field Use...............................10 67 4. Backwards Compatibility........................................11 68 5. Examples.......................................................11 69 5.1. Client Initiated..........................................10 70 5.2. Server Initiated..........................................12 71 6. Security Considerations........................................13 72 7. IANA Considerations............................................14 73 8. Modifications..................................................14 74 9. Acknowledgments................................................15 75 10. Normative References...........................................15 76 11. Non-Normative References.......................................15 77 12. Authors�s Addresses............................................16 79 1. Introduction 81 Traditionally, security protocols have included facilities to agree 82 on the used mechanisms, algorithms, and other security parameters. 83 The reason for this is that experience has shown that algorithm 84 development uncovers problems in old algorithms and produces new 85 ones. Furthermore, different mechanisms and algorithms are suitable 86 for different situations. Typically, protocols also select other 87 parameters beyond algorithms at the same time. 89 The purpose of this specification is to define a similar negotiation 90 functionality in SIP [1]. SIP has some security functionality built- 91 in such as HTTP Digest authentication [4], secure attachments such as 92 S/MIME [5], and can also use underlying security protocols such as 93 IPsec/IKE [2] or TLS [3]. Some of the built-in security functionality 94 allows also alternative algorithms and other parameters. While some 95 work within the SIP Working Group has been looking towards reducing 96 the number of recommended security solutions (i.e., recommend just 97 one lower layer security protocol), we can not expect to cut down the 98 number of items in the whole list to one. There will still be 99 multiple security solutions utilized by SIP. Furthermore, it is 100 likely that new methods will appear in the future, to complement the 101 methods that exist today. 103 Chapter 2 shows that without a secured method to choose between 104 security mechanisms and/or their parameters, SIP is vulnerable to 105 certain attacks. As the HTTP authentication RFC [4] points out, 106 authentication and integrity protection using multiple alternative 107 methods and algorithms is vulnerable to Man-in-the-Middle (MitM) 108 attacks. More seriously, it is hard or sometimes even impossible to 109 know whether a SIP peer entity is truly unable to perform (e.g., 110 Digest, TLS, or S/MIME) or if a MitM attack is in action. In small 111 networks consisting of workstations and servers these issues are not 112 very relevant, as the administrators can deploy appropriate software 113 versions and set up policies for using exactly the right type of 114 security. However, SIP will be deployed to hundreds of millions of 115 small devices with little or no possibilities for coordinated 116 security policies, let alone software upgrades, and this makes these 117 issues much worse. This conclusion is also supported by the 118 requirements from 3GPP [6]. 120 Chapter 6 documents the proposed solution, and chapter 7 gives some 121 demonstrative examples. 123 2. Problem Description 125 SIP has alternative security mechanisms such as HTTP authentication 126 with integrity protection, lower layer security protocols, and 127 S/MIME. It is likely that their use will continue in the future. SIP 128 security is developing, and is likely to see also new solutions in 129 the future. 131 Deployment of large number of SIP-based consumer devices such as 3GPP 132 terminals requires all network devices to be able to accommodate 133 past, current and future mechanisms; there is no possibility for 134 instantaneous change since the new solutions are coming gradually in 135 as new standards and product releases occur. It is sometimes even 136 impossible to upgrade some of the devices without getting completely 137 new hardware. 139 So, the basic security problem that such a large SIP-based network 140 must consider, would be on how do security mechanisms get selected? 141 It would be desirable to take advantage of new mechanisms as they 142 become available in products. 144 Firstly, we need to know somehow what security should be applied, and 145 preferably find this out without too many additional roundtrips. 147 Secondly, selection of security mechanisms MUST be secure. 148 Traditionally, all security protocols use a secure form of 149 negotiation. For instance, after establishing mutual keys through 150 Diffie-Hellman, IKE sends hashes of the previously sent data -- 151 including the offered crypto mechanisms. This allows the peers to 152 detect if the initial, unprotected offers were tampered with. 154 The security implications of this are subtle, but do have a 155 fundamental importance in building large networks that change over 156 time. Given that the hashes are produced also using algorithms agreed 157 in the first unprotected messages, one could ask what the difference 158 in security really is. Assuming integrity protection is mandatory and 159 only secure algorithms are used, we still need to prevent MitM 160 attackers from modifying other parameters, such as whether encryption 161 is provided or not. Let us first assume two peers capable of using 162 both strong and weak security. If the initial offers are not 163 protected in any way, any attacker can easily "downgrade" the offers 164 by removing the strong options. This would force the two peers to use 165 weak security between them. But if the offers are protected in some 166 way -- such as by hashing, or repeating them later when the selected 167 security is really on -- the situation is different. It would not be 168 sufficient for the attacker to modify a single message. Instead, the 169 attacker would have to modify both the offer message, as well as the 170 message that contains the hash/repetition. More importantly, the 171 attacker would have to forge the weak security that is present in the 172 second message, and would have to do so in real time between the sent 173 offers and the later messages. Otherwise, the peers would notice that 174 the hash is incorrect. If the attacker is able to break the weak 175 security, the security method and/or the algorithm should not be 176 used. 178 In conclusion, the security difference is making a trivial attack 179 possible versus demanding the attacker to break algorithms. An 180 example of where this has a serious consequence is when a network is 181 first deployed with integrity protection (such as HTTP Digest [4]), 182 and then later new devices are added that support also encryption 183 (such as S/MIME [1]). In this situation, an insecure negotiation 184 procedure allows attackers to trivially force even new devices to use 185 only integrity protection. 187 3. Solution 189 3.1 Requirements 191 The solution to the SIP security negotiation problem should have the 192 following properties: 194 (a) It allows the selection of security mechanisms, such as lower 195 layer security protocols or HTTP digest. It also allows the selection 196 of individual algorithms and parameters when the security functions 197 are integrated in SIP (such as in the case of HTTP authentication). 199 (b) It allows first-hop security negotiation. 201 (c) It is secure (i.e., prevents the bidding down attack.) 203 (d) It is capable of running without additional roundtrips. This is 204 important in the cellular environment, where an additional roundtrip 205 could delay the call set up for 1000-1500 ms. 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 RFC 217 itself. More seriously, they have no provisions for allowing 218 encryption to be negotiated. Hence, it would be hard to turn on 219 possible future encryption schemes in a secure 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 header field. 332 This specification defines six values: 334 - "tls" for TLS [3]. 335 - "digest-integrity" for HTTP Digest [4] using additional 336 integrity protection (i.e., the qop parameter) for the Security- 337 Verify header field. 338 - "ipsec-ike" for IPsec with IKE [2]. 339 - "ipsec-man" for manually keyed IPsec without IKE. 340 - "smime" for S/MIME [5]. 342 Preference: The "q" value indicates a relative preference for the 343 particular mechanism. The higher the value the more preferred the 344 mechanism is. 346 Algorithm: An optional algorithm field for those security 347 mechanisms which are not self-describing or which are vulnerable 348 for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP 349 Digest, the same rules apply as defined in [4] for the "algorithm" 350 field in HTTP Digest. 352 3.4. Protocol Operation 354 This section deals with the protocol details involved in the 355 negotiation between a user agent client and its next-hop SIP entity. 356 Throughout the text the next-hop SIP entity is referred to as the 357 first-hop proxy or outbound proxy. However, the reader should bear in 358 mind that a user agent server can also be the next-hop for a user 359 agent client in the absence of proxies. Note as well that a proxy can 360 also have an outbound proxy. 362 3.4.1 Client Initiated 364 A client wishing to establish some type of security with its first- 365 hop proxy SHOULD add a Security-Client header field to a request 366 addressed to this proxy (i.e., the destination of the request is the 367 first-hop proxy). This header field contains a list of all the 368 security mechanisms that the client supports. The client SHOULD NOT 369 add preference parameters to this list. The client MUST also add a 370 Require header field with the value "sec-agree" to its request. 372 The Security-Client header field is used by the server to include any 373 necessary information in its response. For example, if digest- 374 integrity is the chosen mechanism, the server includes a WWW- 375 Authenticate header in the response. If S/MIME is chosen, the 376 appropriate certificate is included. If the security mechanisms 377 supported by the client do not need any further information to be 378 established (e.g., TLS) the client MAY choose not to include the 379 Security-Client header field in its request. 381 A server receiving a request that contains a Require header field 382 with the value "sec-agree" MUST challenge the client with a 494 383 (Security Agreement Required) response. The server MUST add a 384 Security-Server header field to this response listing the security 385 mechanisms that the server supports. The server MUST add its list to 386 the response even if there are no common security mechanisms in the 387 client's and server's lists. The server�s list MUST NOT depend on the 388 contents of the client's list. 390 The server MUST compare the list received in the Security-Client 391 header field with the list to be sent in the Security-Server header 392 field. When the client receives this response, it will choose the 393 common security mechanism with the higher preference value. 394 Therefore, the server MUST add the necessary information so that the 395 client can initiate that mechanism (e.g., a WWW-Authenticate header 396 field for digest-integrity). 398 When the client receives a response with a Security-Server header 399 field, it SHOULD choose the security mechanism in the server�s list 400 with the highest "q" value among all the mechanisms that are known to 401 the client. Then, it MUST initiate that particular security mechanism 402 as described in Section 3.5. This initiation may be carried out 403 without involving any SIP message exchange (e.g., establishing a TLS 404 connection). 406 All the subsequent SIP requests sent by the client SHOULD make use of 407 the security mechanism initiated in the previous step. These requests 408 MUST contain a Security-Verify header field that mirrors the server�s 409 list received previously in the Security-Server header field. This 410 request MAY use SIP loose routing mechanism (i.e., Route header 411 fields) to traverse the proxy, but its final destination may be 412 different than the proxy. In this case, the request SHOULD NOT 413 include a Require header field with the value "sec-agree". 415 For example, the first request was an OPTIONS request directly 416 addressed to the proxy and the second request is an INVITE that 417 will traverse the proxy but that is addressed to a real user (see 418 example in section 4.1). 420 The server MUST check that the security mechanisms listed in the 421 Security-Verify header field of incoming requests correspond to its 422 static list of supported security mechanisms. The server can proceed 423 processing a particular request if, and only if, the list was not 424 modified. If modification of the list is detected, the server MUST 425 challenge the client with a 494 (Security Agreement Required). This 426 response MUST include a challenge with server's unmodified list of 427 supported security mechanisms. 429 Once the security has been negotiated between two SIP entities, the 430 same SIP entities MAY use the same security when communicating with 431 each other in different SIP roles. For example, if a UAC and its 432 outbound proxy negotiate some security, they may try to use the same 433 security for incoming requests (i.e., the UA will be acting as a 434 UAS). 436 The user of a UA MAY be informed about the results of the security 437 mechanism negotiation. The user MAY decline to accept a particular 438 security mechanism, and abort further SIP communications with the 439 peer. 441 3.4.2 Server Initiated 443 A server decides to use the security negotiation described in this 444 document based on local policy. A server that decides to use this 445 negotiation MUST challenge requests regardless of the presence or the 446 absence of any Require or Supported header fields in incoming 447 requests. 449 A server that by policy requires the use of this specification and 450 receives a request that does not have the sec-agree option tag in a 451 Require or Supported header field MUST return a 421 (Extension 452 Required) response. If the request had the sec-agree option tag in a 453 Supported header field, it MUST return a 494 (Security Agreement 454 Required) response. In both situation the server MUST also include in 455 the response a Security-Server header field listing its capabilities 456 and a Require header field with an option-tag 'sec-agree' in it. All 457 the Via header field entries in the response except the topmost value 458 MUST be removed. 460 Clients that support the extension defined in this document MAY add a 461 Supported header field with a value of "sec-agree". In addition to 462 this, clients SHOULD add a Security-Client header field so that they 463 can save a round trip in case the server decides to challenge the 464 request. 466 3.5. Security mechanism initiation 468 Once the client chooses a security mechanism from the list received 469 in the Security-Server header field from the server, it initiates 470 that mechanism. Different mechanisms require different initiation 471 procedures. 473 If TLS is chosen, the client MUST contact the server using the host 474 part of the Request-URI in the first request to the server as the 475 destination of the connection (note that this may involve using 476 standard SIP DNS procedures to locate a server). If this connection 477 attempt fails, the security agreement procedure MUST be considered to 478 have failed, and MUST be terminated. 480 If digest-integrity is chosen, the 494 (Security Agreement Required) 481 response will contain an HTTP authentication challenge. The client 482 MUST use the qos parameter possibly together with some variant of 483 MIME tunneling so that the Security-Verify header field in the 484 request is integrity protected in the MIME body. Note that digest 485 alone would not fulfill the minimum security requirements of this 486 specification. 488 To use "ipsec-ike", the client attempts to establish an IKE 489 connection to the host part of the Request-URI in the first request 490 to the server. If the IKE connection attempt fails, the agreement 491 procedure MUST be considered to have failed, and MUST be terminated. 493 Note that "ipsec-man" will only work if the communicating SIP 494 entities know which keys and other parameters to use. It is outside 495 the scope of this specification to describe how this information can 496 be made known to the peers. 498 In both IPsec-based mechanisms, it is expected that appropriate 499 policy entries for protecting SIP have been configured or will be 500 created before attempting to use the security agreement procedure, 501 and that SIP communications use port numbers and addresses according 502 to these policy entries. It is outside the scope of this 503 specification to describe how this information can be made known to 504 the peers, but it could be typically configured at the same time as 505 the IKE credentials or manual SAs have been entered. 507 To use S/MIME, the client MUST construct its request using S/MIME. 508 The client may have received the server�s certificate in an S/MIME 509 body in the 494 (Security Agreement Required) response. 511 3.6. Duration of Security Associations 513 Once a security mechanism has been negotiated, both the server and 514 the client need to know until when it can be used. All the mechanisms 515 described in this document have a different way to signal the end of 516 a security association. When TLS is used, the termination of the 517 connection indicates that a new negotiation is needed. IKE negotiates 518 the duration of a security association. If the credentials provided 519 by a client using digest-integrity are not longer valid, the server 520 will re-challenge the client. It is assumed that when IPsec-man is 521 used, the same out-of-band mechanism used to distribute keys is used 522 to define the duration of the security association. 524 3.7. Summary of Header Field Use 526 The header fields defined in this document may be used to negotiate 527 the security mechanisms between a UAC and other SIP entities 528 including UAS, proxy, and registrar. Information about the use of 529 headers in relation to SIP methods and proxy processing is summarized 530 in Table 1. 532 Header field where proxy ACK BYE CAN INV OPT REG 534 _________________________________________________________________ 535 Security-Client R ard - o - o o o 536 Security-Server 401,407,421,494 - o - o o o 537 Security-Verify R ard - o - o o o 539 Header field where proxy SUB NOT PRK IFO UPD MSG 541 _________________________________________________________________ 542 Security-Client R ard o o - o o o 543 Security-Server 401,407,421,494 o o - o o o 544 Security-Verify R ard o o - o o o 546 Table 1: Summary of header usage. 548 The "where" column describes the request and response types in which 549 the header field may be used. The header may not appear in other 550 types of SIP messages. Values in the where column are: 552 - R: Header field may appear in requests. 554 - 401, 407 etc.: A numerical value or range indicates response codes 555 with which the header field can be used. 557 The "proxy" column describes the operations a proxy may perform on a 558 header field: 560 - a: A proxy can add or concatenate the header field if not present. 562 - r: A proxy must be able to read the header field, and thus this 563 header field cannot be encrypted. 565 - d: A proxy can delete a header field value. 567 The next six columns relate to the presence of a header field in a 568 method: 570 - o: The header field is optional. 572 4. Backwards Compatibility 574 A server that, by local policy, decides to use the negotiation 575 mechanism defined in this document, will not accept requests from 576 clients that do not support this extension. This obviously breaks 577 interoperability with every plain SIP client. Therefore, this 578 extension should only be used in closed environments where it is 579 ensured somehow that every client implements this extension. 581 5. Examples 583 The following examples illustrate the use of the mechanism defined 584 above. 586 5.1. Client Initiated 588 A UA negotiates the security mechanism to be used with its outbound 589 proxy without knowing beforehand which mechanisms the proxy supports. 591 UAC Proxy UAS 593 | | | 594 |----(1) OPTIONS---->| | 595 | | | 596 |<-----(2) 494-------| | 597 | | | 598 |<=======TLS========>| | 599 | | | 600 |----(3) INVITE----->| | 601 | |----(4) INVITE--->| 602 | | | 603 | |<---(5) 200 OK----| 604 |<---(6) 200 OK------| | 605 | | | 606 |------(7) ACK------>| | 607 | |-----(8) ACK----->| 608 | | | 609 | | | 610 | | | 611 | | | 613 Figure 2: Negotiation initiated by the client 615 The UAC sends an OPTIONS request to its outbound proxy, indicating 616 that it is able to negotiate security mechanisms and that it supports 617 TLS and digest-integrity (Step 1 of figure 1). The outbound proxy 618 challenges the UAC with its own list of security mechanisms � IPsec 619 and TLS (Step 2 of figure 1). The only common security mechanism is 620 TLS, so they establish a TLS connection between them (Step 3 of 621 figure 1). When the connection is successfully established, the UAC 622 sends an INVITE over the TLS connection just established (Step 4 of 623 figure 1). This INVITE contains the server�s security list. The 624 server verifies it, and since it matches its static list, it 625 processes the INVITE and forwards it to the next hop. 627 If this example was run without Security-Server header in Step 2, the 628 UAC would not know what kind of security the other one supports, and 629 would be forced to error-prone trials. 631 More seriously, if the Security-verify was omitted in Step 4, the 632 whole process would be prone for MitM attacks. An attacker could 633 spoof "ICMP Port Unreachable" message on the trials, or remove the 634 stronger security option from the header in Step 1, therefore 635 substantially reducing the security. 637 (1) OPTIONS proxy.example.com 638 Security-Client: tls;q=0.1 639 Security-Client: digest-integrity;q=0.2 640 Require: sec-agree 642 (2) 494 (Security Agreement Required) 643 Security-Server: ipsec-ike;q=0.1 644 Security-Server: tls;q=0.2 646 (3) INVITE proxy.example.com 647 Security-Verify: ipsec-ike;q=0.1 648 Security-Verify: tls;q=0.2 649 Route: callee@domain.com 651 The 200 OK response for the INVITE and the ACK are also sent over the 652 TLS connection. The ACK (7) will contain the same Security-Verify 653 header field as the INVITE (3). 655 5.2. Server Initiated 656 In this example of figure 3 the client sends an INVITE towards the 657 callee using an outbound proxy. This INVITE does not contain any 658 Require header field. 660 UAC Proxy UAS 662 | | | 663 |-----(1) INVITE---->| | 664 | | | 665 |<-----(2) 421-------| | 666 | | | 667 |------(3) ACK------>| | 668 | | | 669 |<=======IKE========>| | 670 | | | 671 |-----(4) INVITE---->| | 672 | |----(5) INVITE--->| 673 | | | 674 | |<---(7) 200 OK----| 675 |<----(6) 200 OK-----| | 676 | | | 677 |------(8) ACK------>| | 678 | |-----(9) ACK----->| 679 | | | 680 | | | 682 Figure 3: Server initiated security negotiation 684 The proxy, following its local policy, challenges the INVITE. It 685 returns a 421 (Extension Required) with a Security-Server header 686 field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE 687 it performs the key exchange and establishes a security association 688 with the proxy. The second INVITE (4) and the ACK (8) contain a 689 Security-Verify header field that mirrors the Security-Server header 690 field received in the 421. The INVITE (4), the 200 OK (6) and the ACK 691 (8) are sent using the security association that has been 692 established. 694 6. Security Considerations 696 This specification is about making it possible to select between 697 various SIP security mechanisms in a secure manner. In particular, 698 the method presented here allow current networks using, for instance, 699 Digest, to be securely upgraded to, for instance, IPsec without 700 requiring a simultaneous modification in all equipment. The method 701 presented in this specification is secure only if the weakest 702 proposed mechanism offers at least integrity protection. 704 Attackers could try to modify the server's list of security 705 mechanisms in the first response. This would be revealed to the 706 server when the client returns the received list using the security. 708 Attackers could also try to modify the repeated list in the second 709 request from the client. However, if the selected security mechanism 710 uses encryption this may not be possible, and if it uses integrity 711 protection any modifications will be detected by the server. 713 Finally, attackers could try to modify the client's list of security 714 mechanisms in the first message. The client selects the security 715 mechanism based on its own knowledge of its own capabilities and the 716 server's list, hence the client's choice would be unaffected by any 717 such modification. However, the server's choice could still be 718 affected as described below: 720 - If the modification affected the server's choice, the server and 721 client would end up choosing different security mechanisms in Step 3 722 or 4 of figure 1. Since they would be unable to communicate to each 723 other, this would be detected as a potential attack. The client would 724 either retry or give up in this situation. 726 - If the modification did not affect the server's choice, there's no 727 effect. 729 All clients that implement this specification MUST select HTTP Digest 730 with integrity, TLS, IPsec, or any stronger method for the protection 731 of the second request. If HTTP Digest is used alone, the security 732 agreement headers MUST be protected. This can be done with HTTP 733 Digest if combined with MIME/SIP tunneling, for example. 735 7. IANA Considerations 737 This specification defines the 'sec-agree' SIP option tag which 738 should be registered in IANA. 740 This specification also defines a new SIP status code, 494 (Security 741 Agreement Failed), which should be registered in IANA. 743 8. Modifications 745 The draft-sip-sec-agree-01.txt version of this specification 746 introduced the following modifications: 748 - Scope narrowed down to first-hop negotiation. 750 - Fixed syntax of header fields. 752 The draft-sip-sec-agree-00.txt version of this specification 753 introduced the following modifications: 755 - Many editorial changes, restructuring and clarifications. 757 - Motivation section has been shortened since this is now a WG 758 item. 760 - Clarified that the solution requires always some base level of 761 security (i.e. integrity) in order to work. Even 'the weak 762 security' must not be broken. 764 - Text related to alternative solutions shortened and moved to a 765 new place. 767 - New rules for possible error and special cases has been added, 768 (e.g., for the case in which an non-adjacent SIP entities try to 769 negotiate hop-by-hop security mechanisms). 771 - Syntax of the header redesigned. Wanted to get rid of the 772 semantics related to the relative position of a header component in 773 the header e.g., first parameters defines the 'from-uri', second 774 the 'to-uri', and third the first supported security mechanism). 775 The option tags are now used to identify the Security Agreement 776 extension, not the individual security mechanisms. 778 - The semantics of the header slightly changed: the AND operator 779 between the indivicual mechanisms is removed because it is really 780 need with HTTP Digest only. And even in this case, the negotiation 781 is not needed beforehand if some underlying security is used. 783 - Options for HTTP Digest algorithms and manually keyed IPsec 784 added. 786 - Explicit rules were added to all mechanisms on how they should be 787 used, such as TLS to be run on port 5061 etc. 789 - References to Enhanced HTTP Digest removed. 791 - Example related to 3GPP generalized. 793 The draft-arkko-sip-sec-agree-01.txt version of this specification 794 introduced the following modifications: 796 - Reversed approach to make servers stateless 798 - Removed discussion of the use of this for Digest algorithm 799 selection, since Enhanced Digest already has bidding-down 800 protection 802 - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed 803 the parameters, as we can rely on Enhanced Digest to perform the 804 algorithm selection. 806 - Removed agreements for full paths. 808 - Simplified syntax 810 9. Acknowledgments 812 The authors wish to thank Lee Valerius, Rolf Blom, James Undery, 813 Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David 814 Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin 815 Euchner, Eric Rescorla and members of the 3GPP SA3 group for 816 interesting discussions in this problem space. 818 10. Normative References 820 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 821 Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation 822 Protocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, 823 February 2002. 825 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 826 Protocol", RFC 2401, IETF, November 1998. 828 [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 829 IETF January 1999. 831 [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access 832 Authentication", RFC 2617, IETF, June 1999. 834 [5] B. Ramsdell and Ed, "S/MIME version 3 message specification," RFC 835 2633, IETF, June 1999. 837 11. Non-Normative References 839 [6] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 840 Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", 841 draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, 842 October 2001. 844 12. Authors's Addresses 846 Jari Arkko 847 Ericsson 848 02420 Jorvas 849 Finland 850 EMail: Jari.Arkko@ericsson.com 852 Vesa Torvinen 853 Ericsson 854 02420 Jorvas 855 Finland 856 EMail: Vesa.Torvinen@ericsson.fi 858 Gonzalo Camarillo 859 Ericsson 860 02420 Jorvas 861 Finland 862 EMail: Gonzalo.Camarillo@ericsson.com 864 Tao Haukka 865 Nokia 866 Finland 867 EMail: Tao.Haukka@nokia.com 869 Sanjoy Sen 870 Nortel Networks 871 2735-B Glenville Drive 872 Richardson, TX 75082, USA 873 EMail: sanjoy@nortelnetworks.com