idnits 2.17.1 draft-arkko-sip-sec-agree-01.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 -(43): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(48): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(81): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(82): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(88): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(90): 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 -(100): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(103): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(104): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(107): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(123): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(141): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(148): 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 -(153): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(155): 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 -(171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(183): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(185): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(200): 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 -(210): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(252): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(253): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(286): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(287): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(330): 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 -(341): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(358): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(363): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(382): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(435): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(443): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(448): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(461): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(510): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(515): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(523): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(524): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(533): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(557): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(566): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(574): 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 65 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 12 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 12 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 170 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 141: '...urity mechanisms MUST be secure. Trad...' RFC 2119 keyword, line 251: '...ld. The clients MUST announce a list ...' RFC 2119 keyword, line 252: '...est. The servers MUST use this informa...' RFC 2119 keyword, line 258: '... The servers MUST announce a list ...' RFC 2119 keyword, line 259: '...ponse. This list MUST NOT depend on th...' (7 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) == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-08 ** 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) -- No information found for draft-thomas-sip-sec-frame - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-03) exists of draft-garcia-sipping-3gpp-reqs-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-undery-sip-auth-00 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Vesa Torvinen 4 Ericsson 5 30 February 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 August 30, 2002. Please 34 send 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, HTTP authentication is known to be vulnerable to so called 43 Bidding-Down attacks where a Man-In-The-Middle attacker simply modi� 44 fies messages in a way that leads parties to believe the other side 45 only supports weaker algorithms than they actually do. Also, currently 46 it isn't possible to select which security mechanisms to use over a 47 connection. In particular, even if some mechanisms such as OPTIONS 48 were used to make this selection, the selection would be again vulner� 49 able against the Bidding-Down attack. On small networks configuration 50 and software update methods are sufficient to deal with this type of 51 attacks, but on large networks that evolve over time, the security 52 implications are serious: either you deny connections from large 53 amounts of older equipment, or risk losing all value of new algorithms 54 through attacks that are trivial to the attackers. 56 3. Contents 58 1. Status of this Memo..................................1 59 2. Abstract.............................................1 60 3. Contents.............................................2 61 4. Introduction.........................................2 62 5. The Problem..........................................3 63 6. Alternative Solutions................................4 64 7. Proposed Solution....................................5 65 7.1. Design...............................................5 66 7.2. Header descriptions..................................6 67 8. Examples.............................................7 68 8.1. Selecting Between New and Old Mechanisms.............7 69 8.2. Selections Along the Path............................8 70 9. Security Considerations..............................10 71 10. Conclusions..........................................10 72 11. Modifications........................................10 73 12. Acknowledgments......................................11 74 13. References...........................................11 76 4. Introduction 78 Traditionally, security protocols have included facilities to agree on 79 the used mechanisms, algorithms, and other security parameters. The 80 reason for this is that experience has shown algorithm development 81 uncovers problems in old algorithms and produces new ones. Further� 82 more, different algorithms are suitable for different situations. Typ� 83 ically, protocols also select other parameters beyond algorithms at 84 the same time. 86 The purpose of this paper is to study whether similar functionality is 87 necessary in SIP [1]. SIP has some security functionality built-in 88 such as different variants of HTTP authentication [4], secure attach� 89 ments such as S/MIME, and can also use underlying security protocols 90 such as IPSec/IKE [2], TLS [3]. Some of the built-in security func� 91 tionality has also alternative algorithms and other parameters. While 92 some work within the SIP Working Group has been looking towards reduc� 93 ing the number of recommended security solutions (e.g. recommend just 94 one lower layer security protocol), we can not expect to cut down the 95 number of items in the whole list to one. There will still be multiple 96 security solutions in SIP. Furthermore, given that security work 97 around SIP is in its early stages, it is likely that new methods will 98 appear in the future, to complete the methods that exist today. 100 Chapter 5 shows that without a secure method to choose between secu� 101 rity mechanisms and/or their parameters, SIP is vulnerable to certain 102 attacks. As the HTTP authentication RFC [4] points out, authentication 103 and integrity protection using multiple alternative methods and algo� 104 rithms is vulnerable to Man-in-the-Middle (MITM) attacks. More seri� 105 ously, it is hard to know if a SIP peer entity truly can't perform 106 e.g. auth-int QOP in Digest, TLS, or S/MIME, or if a MITM attack is in 107 progress. In small workstation networks these issues are not very rel� 108 evant, but the deployment of hundreds of millions of small devices 109 with little or no possibilities for coordinated security policies, let 110 alone software upgrades makes these issues much worse. This conclusion 111 is supported by the requirements from 3GPP [6]. 113 Chapter 6 outlines some possible solutions to these problems, and 114 Chapter 7 documents our proposed solution. 116 5. The Problem 118 SIP has alternative security mechanisms such as HTTP authentication / 119 integrity protection, lower layer security protocol(s), S/MIME. It is 120 likely that their use will continue in the future. SIP security is 121 developing, and is likely to see also new solutions in the future, for 122 example along the introduction of SIP for new network access technolo� 123 gies. Future services may also bring with themselves different secu� 124 rity requirements and methods. 126 Deployment of large number of SIP-based consumer devices such as 3GPP 127 terminals requires all network devices to be able to accommodate both 128 current and future mechanisms; there is no possiblity for instanta� 129 neous change since the new solutions are coming gradually in as new 130 standards and product releases occur. It isn't even possible to 131 upgrade some of the devices without getting completely new hardware. 133 So, the basic security problem that such a large SIP-based network 134 must consider, how do security mechanisms get selected? It would be 135 desirable to take advantage of new mechanisms as they become available 136 in products. 138 Firstly, we need to know somehow what security should be applied, and 139 preferably find this out without too many additional roundtrips. 141 Secondly, selection of security mechanisms MUST be secure. Tradition� 142 ally, all security protocols use a secure form of negotiation. For 143 instance, after establishing mutual keys through Diffie-Hellman, IKE 144 sends hashes of the previously sent data -- including the offered 145 crypto mechanisms. This allows the peers to detect if the initial, 146 unprotected offers were tampered with. 148 The security implications of this are subtle, but do have a fundamen� 149 tal importance in building large networks that change over time. Given 150 that the hashes are produced also using algorithms agreed in the first 151 unprotected messages, one could ask what the difference in security 152 really is. First, assuming hashing is mandatory and only secure algo� 153 rithms are used, we still need to prevent MITM attackers from modify� 154 ing other parameters, such as whether encryption is provided or not. 155 Secondly, it turns out, however, that there indeed is still a differ� 156 ence even for hashes. Let us first assume two peers capable of using 157 both strong and weak security. If the initial offers are not protected 158 in any way, *any* attacker can easily "downgrade" the offers by remov� 159 ing the strong options. This would force the two peers to use weak 160 security between them. But if the offers are protected in some way -- 161 such as by hashing, or repeating them later when the selected security 162 is really on -- the situation is different. It would not be sufficient 163 for the attacker to modify a single message. Instead, the attacker 164 would have to modify both the offer message, as well as the message 165 that contains the hash/repetition. More importantly, the attacker 166 would have to forge the weak hash / security that is present in the 167 second message, and would have to do so in real time between the sent 168 offers and the later messages. Otherwise, the peers would notice that 169 the hash is incorrect. 171 In conclusion, the security difference is making a trivial attack pos� 172 sible versus demanding the attacker to break algorithms. An example of 173 where this has a serious consequence is when a network is first 174 deployed with integrity protection (such as HTTP Digest [4, 7]), and 175 then later new devices are added that support also encryption (such as 176 S/MIME [1]). In this situation, an insecure negotiation procedure 177 allows attackers to trivially force even new devices to use only 178 integrity protection. 180 It can be asked why the devices would be allowing both weak and strong 181 security in the first place. The answer lies in understanding how net� 182 works are deployed, and in the logistical and economical problems in 183 upgrading global networks instantanously. These issues are of particu� 184 larly high relevance for networks with a large number of devices, such 185 as the third generation mobile networks. Once millions or even hun� 186 dreds of millions of devices have been sold to customers, it becomes 187 impossible to replace them with new devices. Therefore, network equip� 188 ment such as SIP proxies must continue to accept even the older 189 equipement that are less capable in terms of security. Similarly, 190 clients wishing to stay in contact regardless of who they call or 191 where they are, have a need to allow both weaker and stronger mecha� 192 nisms. 194 Therefore, we feel that in large networks it is necessary to include 195 some security agreement mechanisms in SIP. 197 6. Alternative Solutions 199 Basic SIP features such as OPTIONS and Require, Supported headers are 200 capable of informing peers about various capabilities including secu� 201 rity mechanisms. However, the straightforward use of these features 202 does not guarantee a secured agreement. (It might be possible to add 203 some new behaviour rules for these headers to allow their use also in 204 secure manner. However, it appears that in order to introduce secu� 205 rity, the headers must be repeated under the selected security protec� 206 tion. In order for the repetition to be useful, either the server 207 would have to be stateful, or the client must repeat the server's 208 list. Stateful servers are not desireable and neither to the Supported 209 or the Require header appears suitable for the client to describe 210 server's capabalities. Hence, the use of these headers is not desire� 211 able.) 213 HTTP Digest algorithm lists [4] are not secure for picking among the 214 digest integrity algorithms, as is described in the RFC itself. 215 Enhanced HTTP Digest [7] corrects this problem. More seriously, 216 neither the original or Enhanced Digest has no provisions for allowing 217 encryption to be negotiated. Hence, it would be hard to turn on possi� 218 ble future encryption schemes in a secure manner. 220 The SIP Security Framework [5] also allows for the agreement about the 221 used security mechanisms. However, it does not do this in a secure 222 manner. 224 7. Proposed Solution 226 In our opinion, the optimal solution to the SIP security negotiation 227 problem has the following properties: 229 (a) It allows the selection of security mechanisms, such as lower 230 layer security protocols or secure attachments. It also allows the 231 selection of individual algorithms and parameters where the security 232 functions are integrated in SIP (such as in the case of HTTP authenti� 233 cation or secure attachments). 235 (b) It allows both end-to-end and hop-by-hop negotiation. 237 (c) It is secure, i.e. prevents bidding down attacks. 239 (d) It is capable of running without additional roundtrips. This is 240 important in the cellular environment, where an additional roundtrip 241 could cost 1000 to 1500 ms for the call set up delay. 243 (e) It does not introduce any additional state to servers and proxies. 245 7.1. Design 247 We propose a scheme - a bit like the one in the framework draft [5] - 248 where security features are represented as regular option tags in SIP. 249 If there will ever be any features that require parameters such as key 250 lengths, the option tags can be associated with an optional value 251 field. The clients MUST announce a list of supported option tags in 252 their first request. The servers MUST use this information in prepar� 253 ing their response, such as including a challenge if the first com� 254 monly supported mechanism is Enhanced Digest. It isn't necessary, how� 255 ever, for the server to remember the clients preferences beyond the 256 response. 258 The servers MUST announce a list of supported option tags in their 259 first response. This list MUST NOT depend on the contents of the list 260 sent by the client in the first message. Typically, the server's list 261 of supported option tags is static. In the client's second request, 262 the client MUST return the server's list. 264 The client makes the selection of the used security mechanism based on 265 its own preferences and the server's list. The client MUST start to 266 use the selected security mechanism from the second request message. 268 The security of the agreement comes from the client's repetition of 269 the server's list of option tags in the second request message. The 270 server can then proceed to verify that the list has not been modified. 271 If a modification is detected, the server returns on error or discon� 272 nects. The server MUST send a positive answer if and only if the list 273 was not modified. The server does not need to memorize the lists it 274 has sent in earlier responses, provided that the set of security mech� 275 anisms supported by the server is constant, which seems like a reason� 276 able assumption. 278 Attackers could also try to modify the repeated list in the second 279 request from the client. However, if the selected security mechanism 280 uses encryption this may not be possible, and if it uses integrity 281 protection any modifications will be detected by the server. In order 282 to ensure this, all clients that implement this specification MUST 283 select Enhanced Digest [7], S/MIME, TLS, IPsec, or any stronger methed 284 for the protection of the second request. 286 Attackers could also try to modify the client's list of security mech� 287 anisms in the first message. This would either be revealed to the par� 288 ticipants, because of unexpected challenges in the server's first 289 response, or would have no effect because the client picks its own 290 security method only based on its local information and the server's 291 static list. 293 The client's first protected request can be a real request such as 294 INVITE, as the server MUST check the correctness of the lists before 295 it proceeds to execute the requested operation. 297 Our approch explicitly lists the recipients of the security method 298 agreement. This is intended to allow a negotiation of the first-hop 299 security mechanism while at the same time running e.g. a REGISTER with 300 Digest authentication to a server some hops further away. 302 This approach could also be trivially extended to support security 303 agremeent over a full path. However, since the sips: URI scheme 304 already solves the most pressing issue in that area we have chosen to 305 not support this. 307 7.2. Header descriptions 309 The Security-Method header indicates who wants security towards whom, 310 and what kind of security. The following ABNF describes the syntax of 311 this header and extends section 25.1 in [1]: 313 "Security-Method" HCOLON to-uri COMMA from-uri COMMA mechlist 315 Where 317 to-uri = addr-spec 318 from-uri = addr-spec 319 mechlist = mechopts *( COMMA mechopts ) 320 mechopts = mechtag *( SEMI mechtag ) 321 mechtag = option-tag [EQUAL token] 323 The meaning of these fields is as follows: 325 - The "to-uri" indicates the desired receiver of the information. The 326 value of this field should be a SIP URI. When sent by a client, the 327 value would typically (but not necessarily) contain just the host and 328 port number parts. 330 - The "from-uri" indicates the sender of the security agreement infor� 331 mation. The value of this is also a SIP URI. When sent by a client, 332 the value would typically (but not necessarily) include a username 333 part. 335 - The "mechlist" represents a list of security mechanisms, all of 336 which must be supported simultaneously on the same connection (such as 337 both Digest TLS). 339 - The "mechopts" represents a list of alternative security mechanisms. 340 Inside one "mechlist" entry we can have multiple alternative mecha� 341 nisms and algorithms. For instance, the the list "org.iana.sip.edi� 342 gest, org.iana.sip.smime; org.iana.sip.ike" would represent the 343 requirement that one must run simultaneously IPsec/IKE and either HTTP 344 Digest or S/MIME. 346 The "mechtag" represent one individual mechanism. The "option-tag" 347 syntax is used for these in order to facilitiate the easy addition of 348 new mechanisms. All option tags starting with "org.iana.sip." MUST be 349 documented in Internet Drafts or RFCs. The initial list of standard� 350 ized option-tags is presented below: 352 org.iana.sip.edigest: Extended HTTP Digest authentication 353 org.iana.sip.tls: TLS 354 org.iana.sip.smime: S/MIME 355 org.iana.sip.ike: IPsec/IKE 357 The optional "token" parameter associated with an "option-tag" can be 358 used to assign a parameter value to certain options. This may be use� 359 ful to select algorithms, key lengths, or other similar parameters in 360 mechanisms integrated to SIP. No such parameters are defined for the 361 four above mechanisms, however. 363 Multiple instances of the same header field can appear in SIP mes� 364 sages. Typically, the client inserts its own Security-Method header 365 when it sends a request, and the server/proxy adds its own response. 366 The parameters are in all cases set in an appropriate manner to indi� 367 cate in the "to-uri" paremeter the party who inserted the header. Or 368 rather -- since the client is copying some of the server's responses 369 -- whose security capabilities the header applies to. 371 8. Examples 373 8.1. Selecting Between New and Old Mechanisms 375 In this example we demonstrate the use of the framework for securing 376 the first hop using some security mechanism, without knowing 377 beforehand which methods the server supports. We assume that the 378 client is not willing to reveal any information on what it intends to 379 do, so it uses OPTIONS in the first message that is sent in the clear. 380 The example starts by a client sending a message to the server, indi� 381 cating that it is of the new variant that supports TLS in Step 1. In 382 Step 2, the server responds that with it own list of security mecha� 383 nisms -- Enhanced Digest and TLS in this case -- and the peers start 384 only common security service i.e. TLS at Step 3. In Step 4, the client 385 resends the server's Security-Method header, which the server veri� 386 fies, and responds with 200 OK. 388 1. Client -> Server: 390 OPTIONS server SIP/2.0 391 Security-Method: sip:client, sip:server, org.iana.sip.tls 393 2. Server -> Client: 395 200 OK 396 Security-Method: sip:server, sip:client, org.iana.sip.edigest, 397 org.iana.sip.tls 399 3. Security handshake at a lower layer i.e. TLS 401 4. Client -> Server: 403 INVITE server SIP/2.0 404 Security-Method: sip:server, sip:client, org.iana.sip.edigest, 405 org.iana.sip.tls 407 5. Server -> Client: 409 200 OK 411 In the example we have omitted the returned values of Security-Method 412 in replies for clarity. Typically in SIP the servers do not remove 413 header fields as they answer, they only add new headers. 415 If this example was run without Security-Method in Step 2, the client 416 would not know what kind of security the other one supports, and would 417 be forced to error-prone trials. 419 More seriously, if the Security-Method was omitted in Step 4, the 420 whole process would be prone for MITM attacks. An attacker could spoof 421 "ICMP Port Unreachable" message on the trials, or remove the stronger 422 security option from the header in Step 1, therefore substantially 423 reducing the security. 425 8.2. Selections Along the Path 427 This example attempts to show how selections can be made e.g. between 428 a client and the first-hop proxy while the actual SIP messages are 429 still destinated to a server further on in the network. This example 430 also demonstrates how we can fulfill the 3GPP requirements on being 431 able to securely agree on the security mechanism between the client 432 and its first hop proxy, without adding roundtrips. 434 In 3GPP networks, the clients make REGISTER operation in their first 435 message, in order to inform the home network that they are at a par� 436 ticular location. Due to the properties of 3GPP radio interfaces, it 437 is necessary to optimize the number of roundtrips needed in the whole 438 process. Therefore, we try to parallelize the tasks. It should be 439 noted that the same functionality could be achieved using additional 440 OPTIONS messages. We assume that 3GPP uses Enhanced HTTP Digest 441 authentication to protect signaling in the first hop. As Enhanced 442 Digest can securely negotiate the used algorithms it is not necessary 443 to use this method for that. However, as Enhanced Digest does not pro� 444 vide confidentiality, it may be necessary to upgrade to the use of TLS 445 or S/MIME in future terminals. 447 The example starts by an old version client coming to a new area and 448 learning the address of the local proxy. The proxy is of a newer ver� 449 sion, so it supports multiple security mechanisms. The client also 450 knows its home server address. We assume that some trust has already 451 been established between the client and the home, and between the 452 client and the proxy. Perhaps this trust is in the form of the nodes 453 belonging under the same PKI, or having distributed shared secrets 454 beforehand. 456 In Step 1 the client contacts the proxy using a REGISTER message. We 457 omit the details of the communications with the home server in this 458 discussion, but the proxy forwards the messages onwards in Step 2. In 459 Step 3, the proxy responds indicating that it is of the new variant 460 that supports Enhanced Digest, S/MIME, and TLS for the protection of 461 the first hop. In Step 4, the client selects the first method is sup� 462 ports (enhanced digest in this case), the protection is turned on and 463 the client sends the next round of REGISTER messages to the server. 464 This includes the repetition of the original security capabilities of 465 the server. The server verifies this list, and in Step 6 it responds 466 with a 200 OK. 468 1. Client -> Proxy: 470 REGISTER server SIP/2.0 471 Security-Method: sip:client, sip:proxy, org.iana.sip.edigest 473 2. Proxy communicates with the Server. 475 3. Proxy -> Client: 477 401 Authentication Required 478 (Enhanced digest challenge to the client from the proxy) 479 Security-Method: sip:proxy, sip:client, org.iana.sip.smime, 480 org.iana.sip.tls, org.iana.sip.edigest 482 4. Client -> Proxy: 484 REGISTER server SIP/2.0 485 (Enhanced digest response to the proxy) 486 Security-Method: sip:proxy, sip:client, org.iana.sip.smime, 487 org.iana.sip.tls, org.iana.sip.edigest 489 5. Proxy communicates with the Server. 491 6. Proxy -> Client: 493 200 OK 494 (Some enhanced digest headers from the proxy) 496 As in the previous example, if this was run without Security-Method in 497 Step 3, the client would not know what kind of algorithms the server 498 supports. In this example we demonstrate also the need for the client 499 to send its own mechanism list in Step 1. If this wasn't known to the 500 proxy when it responds in Step 3, it could not have provided a suit� 501 able Enhanced Digest challenge because at that point the proxy would 502 not have known if the client supports that. 504 As in the previous example, removing the repetition of the Security- 505 Method header in Step 4 would open the system to MITM attacks. 507 9. Security Considerations 509 This draft is about making it possible to select between various SIP 510 security mechanisms in a secure manner. In particular, the method pre� 511 sented here allow current networks using e.g. Digest later securely 512 upgrade to e.g. S/MIME without requiring a simultaneous modification 513 in all equipment. 515 The method presented in this draft is secure only if the weakest pro� 516 posed mechanism offers at least integrity protection. Therefore, we 517 recommend that at leat Enhanced HTTP authentication SHOULD be used in 518 conjunction with our approach. 520 10. Conclusions 522 The presented methods appear to secure the selection between different 523 security mechanisms. This is important for deployments in large net� 524 works. The authors seek comments on the proposed approach, and encour� 525 age security analysis of both current SIP and the proposal. 527 11. Modifications 529 The -01 version of this draft introduced the following modifications: 531 - Reversed approach to make servers stateless 533 - Removed discussion of the use of this for Digest algorithm selec� 534 tion, since Enhanced Digest already has bidding-down protection 536 - Renamed org.iana.sip.digest to org.iana.sip.edigest and removed the 537 parameters, as we can rely on Enhanced Digest to perform the algorithm 538 selection. 540 - Removed agreements for full paths. 542 - Simplified syntax 544 12. Acknowledgments 546 The authors wish to thank Rolf Blom, James Undery, Jonathan Rosenberg, 547 Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Aki 548 Niemi, Miguel Garcia, Valtteri Niemi, and members of the 3GPP SA3 549 group for interesting discussions in this problem space. 551 13. References 553 [1] Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J., "SIP: 554 Session Initiation Protocol", Work In Progress, draft-ietf-sip- 555 rfc2543bis-08.txt, IETF, February 2002. 557 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro� 558 tocol", RFC 2401, November 1998. 560 [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 561 January 1999. 563 [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access 564 Authentication", RFC 2617, June 1999. 566 [5] M. Thomas, "SIP Security Framework", draft-thomas-sip-sec-frame� 567 work-00.txt. Work In Progress, IETF, July 2001. 569 [6] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. 570 Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", 571 draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, October 572 2001. 574 [7] J. Undery, S. Sen, V. Torvinen, "SIP Digest Authentication: Exten� 575 sions to HTTP Digest Authentication", draft-undery-sip-auth-00.txt. 576 Work In Progress, IETF, January 2002. 578 14. Author's Address 580 Jari Arkko, Vesa Torvinen 581 Ericsson 582 02420 Jorvas 583 Finland 584 EMail: Jari.Arkko@ericsson.com, Vesa.Torvinen@ericsson.fi 586 Tao Haukka 587 Nokia 588 Finland 589 EMail: Tao.Haukka@nokia.com 591 Sanjoy Sen 592 Nortel Networks 593 2735-B Glenville Drive 594 Richardson, TX 75082, USA 595 EMail: sanjoy@nortelnetworks.com 597 Lee Valerius 598 Nortel Networks 599 2201 Lakeside Blvd 600 Richards, TX 75082, USA 601 EMail: valerius@nortelnetworks.com