idnits 2.17.1 draft-ietf-sip-sec-agree-00.txt: -(16): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(18): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(44): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(47): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(80): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(92): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(98): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(101): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(102): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(129): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(140): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(147): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(152): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(158): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(166): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(170): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(189): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(205): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(220): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(273): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(297): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(328): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(340): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(488): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(569): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(580): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(590): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(591): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(596): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(648): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(651): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(666): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(684): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(689): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(694): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(699): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(706): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(721): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(743): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(764): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(765): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(769): 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 Internet-Drafts being working documents. ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 51 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 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** There are 214 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 140: '...urity mechanisms MUST be secure. Trad...' RFC 2119 keyword, line 257: '...from the other side. Nodes MAY, how�...' RFC 2119 keyword, line 269: '...ep 1: The client MUST announce a list ...' RFC 2119 keyword, line 270: '...uest. The client SHOULD also add the o...' RFC 2119 keyword, line 273: '...ep 2: The server MUST announce a list ...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 33 has weird spacing: '...t>, and expir...' -- 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: 14 errors (**), 0 flaws (~~), 6 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 Ericsson 5 April 2002 Tao Haukka 6 Nokia 7 Sanjoy Sen 8 Lee Valerius 9 Nortel Networks 11 Security Mechanism Agreement for SIP Sessions 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. Internet-Drafts are working docu� 17 ments of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute work� 19 ing documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or made obsolete by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as work in progress. 26 The list of current Internet-Drafts may be found at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories may be found at 30 http://www.ietf.org/shadow.html. 32 The distribution of this memo is unlimited. It is filed as , and expires October, 2002. Please send 34 comments to the author or to SIPPING or SIP working group. 36 2. Abstract 38 SIP has a number of security mechanisms for hop-by-hop and end-to-end 39 protection. Some of the security mechanisms have been built in to the 40 SIP protocol, such as HTTP authentication or secure attachments. In 41 these mechanisms there are even alternative algorithms and parameters. 42 Currently it isn't possible to select which security mechanisms to use 43 over a connection. In particular, even if some mechanisms such as 44 OPTIONS were used to make this selection, the selection would be vul� 45 nerable against the Bidding-Down attack. This document defines a 46 header for negotiating the security mechanisms within SIP. A SIP 47 entity applying this mechanism must always require some minimum secu� 48 rity (i.e. integrity protection) from all communicating parties in 49 order to secure the negotiation, but the negotiation can agree on 50 which specific minimum security is used. 52 3. Contents 54 1. Status of this Memo..................................1 55 2. Abstract.............................................1 56 3. Contents.............................................2 57 4. Introduction.........................................2 58 5. The Problem..........................................3 59 6. Solution.............................................4 60 6.1. Requirements.........................................4 61 6.2. Different Mechanisms.................................5 62 6.3. Overview of Operations...............................5 63 6.4. Header descriptions..................................7 64 7. Summary of header usage..............................9 65 8. Backwards Compatibility..............................10 66 9. Examples.............................................10 67 9.1. Selecting Between New and Old Mechanisms.............10 68 9.2. Selections Along the Path............................11 69 10. Security Considerations..............................13 70 11. IANA Considerations..................................13 71 12. Modifications........................................14 72 13. Acknowledgments......................................15 74 4. Introduction 76 Traditionally, security protocols have included facilities to agree on 77 the used mechanisms, algorithms, and other security parameters. The 78 reason for this is that experience has shown that e.g. algorithm 79 development uncovers problems in old algorithms and produces new ones. 80 Furthermore, different mechanisms and algorithms are suitable for dif� 81 ferent situations. Typically, protocols also select other parameters 82 beyond algorithms at the same time. 84 The purpose of this specification is to define a similar negotiation 85 functionality in SIP [1]. SIP has some security functionality built-in 86 such as HTTP Digest authentication [4], secure attachments such as 87 S/MIME [5], and can also use underlying security protocols such as 88 IPSec/IKE [2] or TLS [3]. Some of the built-in security functionality 89 allows also alternative algorithms and other parameters. While some 90 work within the SIP Working Group has been looking towards reducing 91 the number of recommended security solutions (e.g. recommend just one 92 lower layer security protocol), we can not expect to cut down the num� 93 ber of items in the whole list to one. There will still be multiple 94 security solutions utilized by SIP. Furthermore, it is likely that new 95 methods will appear in the future, to complete the methods that exist 96 today. 98 Chapter 5 shows that without a secured method to choose between secu� 99 rity mechanisms and/or their parameters, SIP is vulnerable to certain 100 attacks. As the HTTP authentication RFC [4] points out, authentication 101 and integrity protection using multiple alternative methods and algo� 102 rithms is vulnerable to Man-in-the-Middle (MITM) attacks. More seri� 103 ously, it is hard or sometimes even impossible to know whether a SIP 104 peer entity is truly unable to perform e.g. Digest, TLS, or S/MIME, 105 or if a MITM attack is in action. In small networks consisting of 106 workstations and servers these issues are not very relevant, as the 107 administrators can deploy appropriate software versions and set up 108 policies for using exactly the right type of security. However, SIP 109 will soon be deployed to hundreds of millions of small devices with 110 little or no possibilities for coordinated security policies, let 111 alone software upgrades, and this makes these issues much worse. This 112 conclusion is also supported by the requirements from 3GPP [6]. 114 Chapter 6 documents the proposed solution, and chapter 7 gives some 115 demonstrative examples. 117 5. The Problem 119 SIP has alternative security mechanisms such as HTTP authentication / 120 integrity protection, lower layer security protocols, and S/MIME. It 121 is likely that their use will continue in the future. SIP security is 122 developing, and is likely to see also new solutions in the future. 124 Deployment of large number of SIP-based consumer devices such as 3GPP 125 terminals requires all network devices to be able to accommodate past, 126 current and future mechanisms; there is no possiblity for instanta� 127 neous change since the new solutions are coming gradually in as new 128 standards and product releases occur. It is sometimes even impossible 129 to upgrade some of the devices without getting completely new hard� 130 ware. 132 So, the basic security problem that such a large SIP-based network 133 must consider, would be on how do security mechanisms get selected? It 134 would be desirable to take advantage of new mechanisms as they become 135 available in products. 137 Firstly, we need to know somehow what security should be applied, and 138 preferably find this out without too many additional roundtrips. 140 Secondly, selection of security mechanisms MUST be secure. Tradition� 141 ally, all security protocols use a secure form of negotiation. For 142 instance, after establishing mutual keys through Diffie-Hellman, IKE 143 sends hashes of the previously sent data -- including the offered 144 crypto mechanisms. This allows the peers to detect if the initial, 145 unprotected offers were tampered with. 147 The security implications of this are subtle, but do have a fundamen� 148 tal importance in building large networks that change over time. Given 149 that the hashes are produced also using algorithms agreed in the first 150 unprotected messages, one could ask what the difference in security 151 really is. Assuming integrity protection is mandatory and only secure 152 algorithms are used, we still need to prevent MITM attackers from mod� 153 ifying other parameters, such as whether encryption is provided or 154 not. Let us first assume two peers capable of using both strong and 155 weak security. If the initial offers are not protected in any way, any 156 attacker can easily "downgrade" the offers by removing the strong 157 options. This would force the two peers to use weak security between 158 them. But if the offers are protected in some way -- such as by hash� 159 ing, or repeating them later when the selected security is really on 160 -- the situation is different. It would not be sufficient for the 161 attacker to modify a single message. Instead, the attacker would have 162 to modify both the offer message, as well as the message that contains 163 the hash/repetition. More importantly, the attacker would have to 164 forge the weak security that is present in the second message, and 165 would have to do so in real time between the sent offers and the later 166 messages. Otherwise, the peers would notice that the hash is incor� 167 rect. If the attacker is able to break the weak security, the security 168 method and/or the algorithm should not be used. 170 In conclusion, the security difference is making a trivial attack pos� 171 sible versus demanding the attacker to break algorithms. An example of 172 where this has a serious consequence is when a network is first 173 deployed with integrity protection (such as HTTP Digest [4]), and then 174 later new devices are added that support also encryption (such as 175 S/MIME [1]). In this situation, an insecure negotiation procedure 176 allows attackers to trivially force even new devices to use only 177 integrity protection. 179 6. Solution 181 6.1. Requirements 183 The solution to the SIP security negotiation problem should have the 184 following properties: 186 (a) It allows the selection of security mechanisms, such as lower 187 layer security protocols or secure attachments. It also allows the 188 selection of individual algorithms and parameters when the security 189 functions are integrated in SIP (such as in the case of HTTP authenti� 190 cation or secure attachments). 192 (b) It allows both end-to-end and hop-by-hop negotiation. 194 (c) It is secure, e.g. prevents the bidding down attack. 196 (d) It is capable of running without additional roundtrips. This is 197 important in the cellular environment, where an additional roundtrip 198 could delay the call set up for 1000-1500 ms. 200 (e) It does not introduce any additional state to servers and proxies. 202 Currently, SIP does not have any mechanism which fulfills all the 203 requirements above. The basic SIP features such as OPTIONS and 204 Require, Supported headers are capable of informing peers about vari� 205 ous capabilities including security mechanisms. However, the straight� 206 forward use of these features can not guarantee a secured agreement. 207 HTTP Digest algorithm lists [4] are not secure for picking among the 208 digest integrity algorithms, as is described in the RFC itself. More 209 seriously, they have no provisions for allowing encryption to be nego� 210 tiated. Hence, it would be hard to turn on possible future encryption 211 schemes in a secure manner. 213 6.2. Different Mechanisms 215 A self-describing security mechanism is a security mechanism that, 216 when used, contains all necessary information about the method being 217 used as well as all of its parameters such as algorithms. 219 A non-self-describing security mechanism is a security mechanism that, 220 when used, requires that the use of the method or some of its parame� 221 ters have been agreed beforehand. 223 Most security mechanisms used with SIP are self-describing. The use 224 of HTTP digest, as well as the chosen algorithm is visible from the 225 HTTP authentication headers. The use of S/MIME is indicated by the 226 MIME headers, and the CMS structures inside S/MIME describe the used 227 algorithms. TLS is run on a separate port in SIP, and where IPsec/IKE 228 is used, IKE negotiates all the necessary parameters. 230 The only exception to this list is the use of manually keyed IPsec. 231 IPsec headers do not contain information about the used algorithms. 232 Furthermore, peers have to set up IPsec Security Associations before 233 they can be used to receive traffic. In contrast S/MIME can be 234 received even if no Security Association was in place, because the 235 application can search for a Security Association (or create a new 236 one) after having received a message that contains S/MIME. 238 In order to make it possible to negotiate both self-describing and 239 non-self-describing security mechanisms, the security agreement scheme 240 must allow both sides to decide on the desired security mechanism 241 before it is actually used. This decision can, and must, take place 242 on both sides before we can be sure that the negotiation has not been 243 tampered by a man-in-the-middle. This tampering will be detected 244 later. 246 6.3. Overview of Operations 248 This specification uses the following approach. The clients and 249 servers offer their lists of supported security mechanisms and parame� 250 ters in the first, unprotected messages. They then proceed to turn on 251 the selected security, and finally repeat some information under this 252 security in order to ensure that the first exchanged lists had not 253 been modified. This procedure is stateless for servers (unless the 254 used security mechanisms require the server to keep some state). 256 The client and the server lists are both static i.e. they do not and 257 can not change based on the input from the other side. Nodes MAY, how� 258 ever, maintain several static lists, one for each interface, for exam� 259 ple. 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 The steps are explained below: 269 - Step 1: The client MUST announce a list of supported security mecha� 270 nisms in their fist request. The client SHOULD also add the option-tag 271 'sec-agree' to the Supported header. 273 - Step 2: The server MUST announce a list of supported security mecha� 274 nisms in their first response. The server MUST add its list to the 275 response even if there were no common security mechanisms in the 276 client's and server's lists, and the list MUST NOT depend on the con� 277 tents of the client's list. The list MUST also be added regardless of 278 any potential error codes in the response. 280 An error has occurred if the client list is not present in the request 281 of Step 1, this request is not OPTIONS, and the server's policy 282 requires the use of this specification. This error will be reported by 283 returning 421 (Extension Required). In this case the server MUST also 284 include a Require header with an option-tag 'sec-agree' in its 285 response. 287 - Step 3: The peers MUST initiate the security mechanism, if necessary 288 to carry this outside the request in Step 4. For instance, TLS should 289 be turned on at this stage. 291 - Step 4: The client MUST select and use the first matching security 292 mechanism from the server's list. The client MUST also repeat the 293 server's list. 295 - Step 5: The server MUST check that the server list sent in the 296 secured message in Step 4 corresponds to its static list of supported 297 security mechanisms. The server MUST send a positive answer or pro� 298 ceed to execute the requested operation if and only if the list was 299 not modified. If modification of the list is detected, the server 300 MUST return a 494 (Security Agreement Failed) response or disconnect. 301 The 494 response MUST include server's unmodified list of supported 302 security mechanisms. The server MUST NOT copy any Security-Mechanism 303 header from the request in Step 4 to the 494 response in Step 5. 305 The server MAY decide to use a security mechanism between Steps 1 and 306 2 but it MUST do so before processing request in Step 4. The client 307 MUST decide to use a security mechanism between Steps 2 and 3. 309 Between Steps 1 and 2, the server MAY set up a non-self-describing 310 security mechanism if necessary. Note that with this type of security 311 mechanisms, the server is necessarily stateful. Between Steps 2 and 4, 312 the client MAY set up a non-self-describing security mechanism. 314 Note that non-adjacent SIP entities can not use hop-by-hop security 315 mechanisms such as TLS or IPsec. If a client receives a list of hop- 316 by-hop security mechanisms from a server several hops away, it MUST 317 NOT try to use these mechanisms with the first hop proxy. The client 318 MAY try to contact the server directly leaving the proxies in between 319 away. 321 Once the security has been negotiated between two SIP entities, the 322 same SIP entities MAY use the same security when communicating with 323 each other in different SIP roles. For example, if a UAC in a end-user 324 equipment and a UAS in a proxy negotiate some security, they may try 325 to use the same security for terminating requests. 327 The results of the security mechanism negotiation MAY be informed to 328 the user of an UAC or an UAS. The user MAY decline to accept a partic� 329 ular security mechanism, and abort further SIP communications with the 330 peer. 332 One SIP request MAY include several independent list. Only one list 333 SHOULD be used between two SIP entities. This allows a negotiation of 334 the first-hop security mechanism while at the same time running e.g. a 335 REGISTER with Digest authentication to a server some hops away. 337 6.4. Header descriptions 339 The Security-Mechanism header indicates who wants security towards 340 whom, and what kind of security. The security features are repre� 341 sented using the header syntax described below. 343 The following ABNF describes the syntax of this header and extends 344 section 25.1 in [1]: 346 "Security-Mechanism" HCOLON to-uri from-uri mechanism-list 348 to-uri = "to" EQUAL sip-uri COMMA 349 from-uri = "from" EQUAL sip-uri COMMA 350 mechanism-list = 1*(COMMA mechanism [SEMI preference] 351 [SEMI algorithm] [SEMI params]) 352 mechanism = "mech" EQUAL ( "digest" / "tls" / "ipsec-ike" / 353 "ipsec-man" / "smime" / token ) 354 preference = "pref" EQUAL preference-value 355 algorithm = "alg" EQUAL algorithm-value 356 params = parameter *[SEMI parameter] 357 parameter = param-name EQUAL param-value 358 param-name = token 359 param-value = token / quoted-string 361 The meaning of these fields is as follows: 363 to-uri Indicates the desired receiver of the information. 364 The value of this field should be a SIP URI. When 365 sent by a client, the value would typically (but 366 not necessarily) contain just the host and port 367 number parts. 369 from-uri Indicates the sender of the security agreement 370 information. The value of this is also a SIP URI. 371 When sent by a client, the value would typically 372 (but not necessarily) include a username part. 374 mechanism The security mechanism supported by the SIP entity 375 identified in the from-uri. 377 This specification defines six values: 379 - "tls" for TLS [3], 380 - "digest" for HTTP Digest [4], 381 - "ipsec-ike" for IPsec with IKE [2], 382 - "ipsec-man" for manually keyed IPsec without IKE, 383 - "smime" for S/MIME [5], and 384 - token for extensions 386 To use TLS, the client MUST contact the server side on 387 port 5061. If this connection attempt fails, the 388 security agreement procedure MUST be considered to have 389 failed, and MUST be terminated. 391 To use HTTP Digest, it alone does not fulfill the 392 minimum security requirements of this specification. In 393 order to use HTTP Digest securely, some variant of MIME 394 tunneling SHOULD be used to force the Security-Mechanism 395 header to be integrity protected in the MIME body. Also, 396 if the server decides that the first matching mechanism 397 is HTTP digest in Step 2 of Section 6.3, the server 398 SHOULD include a HTTP authentication challenge in its 399 response. However, HTTP Digest need not to be negotiated 400 if some underlying security is used (e.g. TLS or 401 IPsec). The proxy/server can always challenge the client 402 after some security mechanism is already in place. 404 To use either "ipsec-ike" or "ipsec-man", the client and 405 the server MUST request their IPsec implementations to 406 protect all further communications between the same IP 407 addresses and ports which where used in in the first 408 request from the client and first response from the 409 server. If the IKE connection attempt fails, the 410 agreement procedure MUST be considered to have failed, 411 and MUST be terminated. Clients and servers SHOULD 412 terminate the IPsec protection when it is no longer 413 used. 415 Note also that "ipsec-man" will only work if the 416 communicating SIP entities know which keys and other 417 parameters to use. It is outside the scope of this 418 specification to describe how this information can be 419 made known to the peers. 421 To use S/MIME, the client MUST construct its request in 422 Step 4 (see 6.3) using S/MIME. If the server sees that 423 S/MIME is the selected mechanism in Step 2, it MAY send 424 its own certificate within an S/MIME body in the 425 response of Step 2. 427 preference A positive integer identifying the preferred order of 428 the mechanisms. Servers MUST use preference numbers in 429 their lists to identify the preferred order of the 430 security mechanisms. Clients MUST NOT use preference 431 numbers in their lists. 433 algorithm An optional algorithm field for those security 434 mechanisms which are not self-describing or which are 435 vulnerable for bidding-down attacks (e.g. HTTP Digest). 436 In the case of HTTP Digest, the same rules apply as 437 defined in [4] for the "algorithm" field in HTTP 438 Digest. 440 params An optional field that allows future extensions. Any 441 unrecognized directive MUST be ignored. 443 Multiple instances of the same header field can appear 444 in SIP messages. Typically, the client inserts its own 445 Security-Mechanism header when it sends a request, and 446 the server/proxy adds its own to the response. The 447 parameters are in all cases set in an appropriate manner 448 to indicate in the "to-uri" paremeter the party who 449 inserted the header. Or rather -- since the client is 450 copying some of the server's responses -- whose security 451 capabilities the header applies to. 453 7. Summary of header usage 455 The Security-Mechanism header may be used to negotiate the security 456 mechanisms between various SIP entities including UAC, UAS, proxy, and 457 registrar. Information about the use of Security-Mechanism header in 458 relation to SIP methods and proxy processing is summarized in Table 1. 460 Header field where proxy ACK BYE CAN INV OPT REG 461 _________________________________________________________________ 462 Security-Mechanism R ar - - - c c c 463 Security-Mechanism 2xx a - - - c c c 464 Security-Mechanism 401,407,421,494 a - - - c c c 466 Table 1: Summary of header usage. 468 The "where" column describes the request and response types in which 469 the header field may be used. The header may not appear in other types 470 of SIP messages. Values in the where column are: 472 - R: Header field may appear in requests. 474 - 2xx, 401, etc.: A numerical value or range indicates response codes 475 with which the header field can be used. 477 The "proxy" column describes the operations a proxy may perform on a 478 header field: 480 - a: A proxy can add or concatenate the header field if not present. 482 - r: A proxy must be able to read the header field, and thus this 483 header field cannot be encrypted. 485 The next six columns relate to the presence of a header field in a 486 method: 488 - c: Conditional; requirements on the header field depend on the con� 489 text of the message. 491 8. Backwards Compatibility 493 SIP entities which support this specification but whose policy does 494 not require its use, SHOULD only start using it if so required by the 495 peer. Such SIP entities can thus communicate with other SIP entities 496 even if they do not support this specification. 498 SIP entities that support this specification and have a policy which 499 requires its use MUST insert the Supported and Require headers as 500 described in this specification. This makes communications possible 501 only with nodes that support this specification. The OPTIONS method 502 can still be used with any node. 504 Note that the use of this specification together with the Proxy- 505 Require header demands the support of this specification from all SIP 506 entities along the path. 508 9. Examples 510 9.1. Selecting Between New and Old Mechanisms 512 In this example we demonstrate the use of the framework for securing a 513 hop using some security mechanism, without knowing beforehand which 514 methods the server supports. We assume that the client is not willing 515 to reveal any information on what it intends to do, so it uses OPTIONS 516 in the first message that is sent in the clear. The example starts by 517 a client sending a message to the server, indicating that it is of the 518 new variant that supports TLS in Step 1. In Step 2, the server 519 responds that with it own list of security mechanisms -- S/MIME or TLS 520 in this case -- and the peers start only common security service i.e. 521 TLS at Step 3. In Step 4, the client resends the server's Security- 522 Mechanism header, which the server verifies, and responds with 200 OK. 524 1. Client -> Server: 526 OPTIONS server SIP/2.0 527 Security-Mechanism: to=sip:server.example.com, 528 from=sip:client.example.com, 529 mech=tls 531 2. Server -> Client: 533 200 OK 534 Security-Mechanism: to=sip:client.example.com, 535 from=sip:server.example.com, 536 mech=smime;pref=1, mech=tls;pref=2 538 3. Security handshake at a lower layer i.e. TLS 540 4. Client -> Server: 542 INVITE server SIP/2.0 543 Security-Mechanism: to=sip:client.example.com, 544 from=sip:server.example.com, 545 mech=smime;pref=1, mech=tls;pref=2 547 5. Server -> Client: 549 200 OK 551 In the example we have omitted the returned values of Security-Mecha� 552 nism in replies for clarity. Typically in SIP the servers do not 553 remove header fields as they answer, they only add new headers. 555 If this example was run without Security-Mechanism in Step 2, the 556 client would not know what kind of security the other one supports, 557 and would be forced to error-prone trials. 559 More seriously, if the Security-Mechanism was omitted in Step 4, the 560 whole process would be prone for MITM attacks. An attacker could spoof 561 "ICMP Port Unreachable" message on the trials, or remove the stronger 562 security option from the header in Step 1, therefore substantially 563 reducing the security. 565 9.2. Selections Along the Path 567 This example attempts to show how selections can be made between a 568 client and the first-hop proxy while the actual SIP messages are still 569 destinated to a server further on in the network. This example demon� 570 strates how we can securely agree on the security mechanism between 571 the client and its first hop proxy, without adding roundtrips. 573 In this example, the client sends a REGISTER request to its registrar. 574 At the same time, the client negotiates the security with a different 575 first hop proxy. There are three alternative security solutions: a) 576 TLS, b) IPsec/IKE, and c) HTTP Digest. 578 The example starts by a client coming to a new network and learning 579 the address of the local proxy. The proxy is of an upgraded version, 580 so it supports all security mechanisms. The client supports alterna� 581 tives b) and c). The client also knows the address of the registrar. 582 We assume that some trust has already been established between the 583 client and the home, and between the client and the proxy. Perhaps 584 this trust is in the form of the nodes belonging under the same PKI, 585 or having distributed shared secrets beforehand. 587 In Step 1 the client contacts the proxy using a REGISTER message. We 588 omit the details of the communications with the home server in this 589 discussion, but the proxy forwards the messages onwards in Step 2. In 590 Step 3, the registrar responds with an end-to-end HTTP Digest authen� 591 tication challenge. Using the same response, the proxy adds an indica� 592 tion that it supports TLS with HTTP Digest, IPsec/IKE, and plain HTTP 593 Digest. In Step 4, the client selects the first method it supports 594 (IPsec/IKE in this case), the protection is turned on. In Step 5, the 595 client sends the next round of REGISTER messages to the registrar. 596 This message includes the repetition of the original security capabil� 597 ities of the proxy. The proxy verifies this list, and forwards the 598 request to the registrar. In Step 7, the registrar responds with a 200 599 OK. 601 1. Client -> Proxy: 603 REGISTER server SIP/2.0 604 Security-Mechanism: to=sip:proxy.example.com, 605 from=sip:client.example.com, 606 mech=ipsec-ike, mech=digest;alg=MD5 608 2. Proxy communicates with the Server. 610 3. Proxy -> Client: 612 401 Authentication Required 613 (HTTP Digest challenge from the registrar to the client) 614 Security-Mechanism: to=sip:client.example.com, 615 from=sip:proxy.example.com, 616 mech=tls;pref=1, mech=ipsec-ike;pref=2, 617 mech=digest;pref=3;alg=MD5 619 4. Security handshake at a lower layer i.e. IPsec/IKE 621 5. Client -> Proxy: 623 REGISTER server SIP/2.0 624 Security-Mechanism: to=sip:client.example.com, 625 from=sip:proxy.example.com, 626 mech=tls;pref=1, mech=ipsec-ike;pref=2, 627 mech=digest;pref=3;alg=MD5 629 6. Proxy communicates with the Server. 631 7. Proxy -> Client: 633 200 OK 635 As in the previous example, if this was run without Security-Mechanism 636 in Step 3, the client would not know what kind of algorithms the 637 server supports. In this example we demonstrate also the need for the 638 client to send its own mechanism list in Step 1. If this wasn't known 639 to the proxy when it responds in Step 3, it could not have provided a 640 suitable HTTP Digest challenge because at that point the proxy would 641 not have known if the client supports that. 643 As in the previous example, removing the repetition of the Security- 644 Mechanism header in Step 5 would open the system to MITM attacks. 646 10. Security Considerations 648 This specification is about making it possible to select between vari� 649 ous SIP security mechanisms in a secure manner. In particular, the 650 method presented here allow current networks using e.g. Digest later 651 securely upgrade to e.g. S/MIME without requiring a simultaneous modi� 652 fication in all equipment. The method presented in this specification 653 is secure only if the weakest proposed mechanism offers at least 654 integrity protection. 656 Attackers could try to modify the server's list of security mechanisms 657 in the first response. This would be revealed to the server when the 658 client returns the received list using the security. 660 Attackers could also try to modify the repeated list in the second 661 request from the client. However, if the selected security mechanism 662 uses encryption this may not be possible, and if it uses integrity 663 protection any modifications will be detected by the server. 665 Finally, attackers could try to modify the client's list of security 666 mechanisms in the first message. The client selects the security mech� 667 anism based on its own knowledge of its own capabilities and the 668 server's list, hence the client's choice would be unaffected by any 669 such modification. However, the server's choice could still be 670 affected as described below: 672 - If the modification affected the server's choice, the server and 673 client would end up choosing different security mechanisms in Step 3 674 or 4.) Since they would be unable to communicate to each other, this 675 would be detected as a potential attack. The client would either retry 676 or give up in this situation. 678 - If the modification did not affect the server's choice, there's no 679 effect. 681 All clients that implement this specification MUST select HTTP Digest, 682 S/MIME, TLS, IPsec, or any stronger method for the protection of the 683 second request. If HTTP Digest is used alone, the security agreement 684 headers MUST be protected. This can be done with HTTP Digest if com� 685 bined with MIME/SIP tunneling, for example. 687 11. IANA Considerations 689 This specification defines 'sec-agree' option tag which should be reg� 690 istered in IANA. The option-tag 'sec-agree' can be used in header 691 related to the SIP compatibility mechanisms for extensions (e.g. 692 Require and Supported). 694 This specification also defines a new error code, 494 (Security Agree� 695 ment Failed), which should be registered in IANA. 697 12. Modifications 699 The draft-sip-sec-agree-00.txt version of this specification intro� 700 duced the following modifications: 702 - Many editorial changes, restructuring and clarifications. 704 - Motivation section has been shortened since this is now a WG item. 706 - Clarified that the solution requires always some base level of secu� 707 rity (i.e. integrity) in order to work. Even 'the weak security' must 708 not be broken. 710 - Text related to alternative solutions shortened and moved to a new 711 place. 713 - New rules for possible error and special cases has been added, e.g. 714 for the case in which an non-adjacent SIP entities try to negotiate 715 hop-by-hop security mechanisms. 717 - Syntax of the header redesigned. Wanted to get rid of the semantics 718 related to the relative position of a header component in the header 719 (e.g. first parameters defines the 'from-uri', second the 'to-uri', 720 and third the first supported security mechanism). The option tags are 721 now used to identify the Security Agreement extension, not the indi� 722 vidual security mechanisms. 724 - The semantics of the header slightly changed: the AND operator 725 between the indivicual mechanisms is removed because it is really need 726 with HTTP Digest only. And even in this case, the negotiation is not 727 needed beforehand if some underlying security is used. 729 - Options for HTTP Digest algorithms and manually keyed IPsec added. 731 - Explicit rules were added to all mechanisms on how they should be 732 used, such as TLS to be run on port 5061 etc. 734 - References to Enhanced HTTP Digest removed. 736 - Example related to 3GPP generalized. 738 The draft-arkko-sip-sec-agree-01.txt version of this specification 739 introduced the following modifications: 741 - Reversed approach to make servers stateless 743 - Removed discussion of the use of this for Digest algorithm selec� 744 tion, since Enhanced Digest already has bidding-down protection 746 - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed the 747 parameters, as we can rely on Enhanced Digest to perform the algorithm 748 selection. 750 - Removed agreements for full paths. 752 - Simplified syntax 754 13. Acknowledgments 756 The authors wish to thank Rolf Blom, James Undery, Jonathan Rosenberg, 757 Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Aki 758 Niemi, Miguel Garcia, Valtteri Niemi, Martin Euchner, Eric Rescorla, 759 and members of the 3GPP SA3 group for interesting discussions in this 760 problem space. 762 14. Normative References 764 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peter� 765 son, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Pro� 766 tocol", Work In Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, 767 February 2002. 769 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro� 770 tocol", RFC 2401, IETF, November 1998. 772 [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 773 IETF January 1999. 775 [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access 776 Authentication", RFC 2617, IETF, June 1999. 778 [5] B. Ramsdell and Ed, "S/MIME version 3 message specification," RFC 779 2633, IETF, June 1999. 781 15. Non-Normative References 783 [6] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 784 Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", 785 draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, October 786 2001. 788 16. Author's Address 790 Jari Arkko, Vesa Torvinen 791 Ericsson 792 02420 Jorvas 793 Finland 794 EMail: Jari.Arkko@ericsson.com, Vesa.Torvinen@ericsson.fi 796 Tao Haukka 797 Nokia 798 Finland 799 EMail: Tao.Haukka@nokia.com 800 Sanjoy Sen 801 Nortel Networks 802 2735-B Glenville Drive 803 Richardson, TX 75082, USA 804 EMail: sanjoy@nortelnetworks.com 806 Lee Valerius 807 Nortel Networks 808 2201 Lakeside Blvd 809 Richards, TX 75082, USA 810 EMail: valerius@nortelnetworks.com