idnits 2.17.1 draft-niemi-rfc3329bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1095. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 505 has weird spacing: '... ard o ...' == Line 507 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.) -- The document date (February 27, 2006) is 6633 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 297 -- Looks like a reference, but probably isn't: '1' on line 808 == Missing Reference: 'RFCNNNN' is mentioned on line 816, but not defined == Unused Reference: 'I-D.ietf-sipping-3gpp-r5-requirements' is defined on line 939, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft V. Torvinen 4 Expires: August 31, 2006 G. Camarillo 5 Ericsson 6 A. Niemi 7 Nokia Research Center 8 T. Haukka 9 Nokia 10 February 27, 2006 12 Security Mechanism Agreement for the Session Initiation Protocol (SIP) 13 draft-niemi-rfc3329bis-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 31, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document defines new functionality for negotiating the security 47 mechanisms used between a Session Initiation Protocol (SIP) user 48 agent and its next-hop SIP entity. This new functionality 49 supplements the existing methods of choosing security mechanisms 50 between SIP entities. 52 Note that this internet-draft is simply a clean RFC 3329 in I-D 53 format, and doesn't yet contain any changes compared to the original. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Overview of Operation . . . . . . . . . . . . . . . . . . 4 63 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Protocol Operation . . . . . . . . . . . . . . . . . . . . 7 65 2.3.1. Client Initiated . . . . . . . . . . . . . . . . . . . 8 66 2.3.2. Server Initiated . . . . . . . . . . . . . . . . . . . 9 67 2.4. Security Mechanism Initiation . . . . . . . . . . . . . . 10 68 2.5. Duration of Security Associations . . . . . . . . . . . . 11 69 2.6. Summary of Header Field Use . . . . . . . . . . . . . . . 11 70 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 71 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. Client Initiated . . . . . . . . . . . . . . . . . . . . . 13 73 4.2. Server Initiated . . . . . . . . . . . . . . . . . . . . . 14 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 6.1. Registration Information . . . . . . . . . . . . . . . . . 18 77 6.2. Registration Template . . . . . . . . . . . . . . . . . . 19 78 6.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 19 79 6.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 19 80 6.5. Option Tags . . . . . . . . . . . . . . . . . . . . . . . 19 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 86 Appendix A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 Intellectual Property and Copyright Statements . . . . . . . . . . 26 90 1. Introduction 92 Note that this internet-draft is simply a clean RFC 3329 in I-D 93 format, and doesn't yet contain any changes compared to the 94 original. 96 Traditionally, security protocols have included facilities to agree 97 on the used mechanisms, algorithms, and other security parameters. 98 This is to add flexibility, since different mechanisms are usually 99 suitable to different scenarios. Also, the evolution of security 100 mechanisms often introduces new algorithms, or uncovers problems in 101 existing ones, making negotiation of mechanisms a necessity. 103 The purpose of this specification is to define negotiation 104 functionality for the Session Initiation Protocol (SIP) [RFC3261]. 105 This negotiation is intended to work only between a UA and its first- 106 hop SIP entity. 108 1.1. Motivations 110 Without a secured method to choose between security mechanisms and/or 111 their parameters, SIP is vulnerable to certain attacks. 112 Authentication and integrity protection using multiple alternative 113 methods and algorithms is vulnerable to Man-in-the-Middle (MitM) 114 attacks (e.g., see [RFC2617]). 116 It is also hard or sometimes even impossible to know whether a 117 specific security mechanism is truly unavailable to a SIP peer 118 entity, or if in fact a MitM attack is in action. 120 In certain small networks these issues are not very relevant, as the 121 administrators of such networks can deploy appropriate software 122 versions and set up policies for using exactly the right type of 123 security. However, SIP is also expected to be deployed to hundreds 124 of millions of small devices with little or no possibilities for 125 coordinated security policies, let alone software upgrades, which 126 necessitates the need for the negotiation functionality to be 127 available from the very beginning of deployment (e.g., see [I-D.ietf- 128 sipping-3gpp-r5-requirements]). 130 1.2. Design Goals 132 1. The entities involved in the security agreement process need to 133 find out exactly which security mechanisms to apply, preferably 134 without excessive additional roundtrips. 136 2. The selection of security mechanisms itself needs to be secure. 137 Traditionally, all security protocols use a secure form of 138 negotiation. For instance, after establishing mutual keys 139 through Diffie-Hellman, IKE sends hashes of the previously sent 140 data including the offered crypto mechanisms [RFC2409]. This 141 allows the peers to detect if the initial, unprotected offers 142 were tampered with. 144 3. The entities involved in the security agreement process need to 145 be able to indicate success or failure of the security agreement 146 process. 148 4. The security agreement process should not introduce any 149 additional state to be maintained by the involved entities. 151 1.3. Conventions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in BCP 14, RFC 2119 156 [RFC2119]. 158 2. Solution 160 2.1. Overview of Operation 162 The message flow below illustrates how the mechanism defined in this 163 document works: 165 1. Client ----------client list---------> Server 166 2. Client <---------server list---------- Server 167 3. Client ------(turn on security)------- Server 168 4. Client ----------server list---------> Server 169 5. Client <---------ok or error---------- Server 171 Figure 1: Security agreement message flow. 173 Step 1: Clients wishing to use this specification can send a list of 174 their supported security mechanisms along the first request to the 175 server. 177 Step 2: Servers wishing to use this specification can challenge the 178 client to perform the security agreement procedure. The security 179 mechanisms and parameters supported by the server are sent along 180 in this challenge. 182 Step 3: The client then proceeds to select the highest-preference 183 security mechanism they have in common and to turn on the selected 184 security. 186 Step 4: The client contacts the server again, now using the selected 187 security mechanism. The server's list of supported security 188 mechanisms is returned as a response to the challenge. 190 Step 5: The server verifies its own list of security mechanisms in 191 order to ensure that the original list had not been modified. 193 This procedure is stateless for servers (unless the used security 194 mechanisms require the server to keep some state). 196 The client and the server lists are both static (i.e., they do not 197 and cannot change based on the input from the other side). Nodes 198 may, however, maintain several static lists, one for each interface, 199 for example. 201 Between Steps 1 and 2, the server may set up a non-self-describing 202 security mechanism if necessary. Note that with this type of 203 security mechanisms, the server is necessarily stateful. The client 204 would set up the non-self-describing security mechanism between Steps 205 2 and 4. 207 2.2. Syntax 209 We define three new SIP header fields, namely Security-Client, 210 Security-Server and Security-Verify. The notation used in the 211 Augmented BNF definitions for the syntax elements in this section is 212 as used in SIP [RFC3261], and any elements not defined in this 213 section are as defined in SIP and the documents to which it refers: 215 security-client = "Security-Client" HCOLON 216 sec-mechanism *(COMMA sec-mechanism) 217 security-server = "Security-Server" HCOLON 218 sec-mechanism *(COMMA sec-mechanism) 219 security-verify = "Security-Verify" HCOLON 220 sec-mechanism *(COMMA sec-mechanism) 221 sec-mechanism = mechanism-name *(SEMI mech-parameters) 222 mechanism-name = ( "digest" / "tls" / "ipsec-ike" / 223 "ipsec-man" / token ) 224 mech-parameters = ( preference / digest-algorithm / 225 digest-qop / digest-verify / extension ) 226 preference = "q" EQUAL qvalue 227 qvalue = ( "0" [ "." 0*3DIGIT ] ) 228 / ( "1" [ "." 0*3("0") ] ) 229 digest-algorithm = "d-alg" EQUAL token 230 digest-qop = "d-qop" EQUAL token 231 digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT 232 extension = generic-param 234 Note that qvalue is already defined in the SIP BNF [RFC3261]. We 235 have copied its definitions here for completeness. 237 The parameters described by the BNF above have the following 238 semantics: 240 Mechanism-name 241 This token identifies the security mechanism supported by the 242 client, when it appears in a Security-Client header field; or by 243 the server, when it appears in a Security-Server or in a Security- 244 Verify header field. The mechanism-name tokens are registered 245 with the IANA. This specification defines four values: 247 * "tls" for TLS [RFC2246]. 249 * "digest" for HTTP Digest [RFC2617]. 251 * "ipsec-ike" for IPsec with IKE [RFC2401]. 253 * "ipsec-man" for manually keyed IPsec without IKE. 255 Preference 256 The "q" value indicates a relative preference for the particular 257 mechanism. The higher the value the more preferred the mechanism 258 is. All the security mechanisms MUST have different "q" values. 259 It is an error to provide two mechanisms with the same "q" value. 261 Digest-algorithm 262 This optional parameter is defined here only for HTTP Digest 263 [RFC2617] in order to prevent the bidding-down attack for the HTTP 264 Digest algorithm parameter. The content of the field may have 265 same values as defined in [RFC2617] for the "algorithm" field. 267 Digest-qop 268 This optional parameter is defined here only for HTTP Digest 269 [RFC2617] in order to prevent the bidding-down attack for the HTTP 270 Digest qop parameter. The content of the field may have same 271 values as defined in [RFC2617] for the "qop" field. 273 Digest-verify 274 This optional parameter is defined here only for HTTP Digest 275 [RFC2617] in order to prevent the bidding-down attack for the SIP 276 security mechanism agreement (this document). The content of the 277 field is counted exactly the same way as "request-digest" in 278 [RFC2617] except that the Security-Server header field is included 279 in the A2 parameter. If the "qop" directive's value is "auth" or 280 is unspecified, then A2 is: 282 A2 = Method ":" digest-uri-value ":" security-server 284 If the "qop" value is "auth-int", then A2 is: 286 A2 = Method ":" digest-uri-value ":" H(entity-body) ":" 287 security-server 289 All linear white spaces in the Security-Server header field MUST 290 be replaced by a single SP before calculating or interpreting the 291 digest-verify parameter. Method, digest-uri-value, entity-body, 292 and any other HTTP Digest parameter are as specified in [RFC2617]. 294 OPEN ISSUE: This calculation is error prone, and should be fixed. 296 Note that this specification does not introduce any extension or 297 change to HTTP Digest [4]. This specification only re-uses the 298 existing HTTP Digest mechanisms to protect the negotiation of 299 security mechanisms between SIP entities. 301 2.3. Protocol Operation 303 This section deals with the protocol details involved in the 304 negotiation between a SIP UA and its next-hop SIP entity. Throughout 305 the text the next-hop SIP entity is referred to as the first-hop 306 proxy or outbound proxy. However, the reader should bear in mind 307 that a user agent server can also be the next-hop for a user agent 308 client. 310 2.3.1. Client Initiated 312 If a client ends up using TLS to contact the server because it has 313 followed the rules specified in [RFC3263], the client MUST NOT use 314 the security agreement procedure of this specification. If a client 315 ends up using non-TLS connections because of the rules in [RFC3263], 316 the client MAY use the security agreement of this specification to 317 detect DNS spoofing, or to negotiate some other security than TLS. 319 A client wishing to use the security agreement of this specification 320 MUST add a Security-Client header field to a request addressed to its 321 first-hop proxy (i.e., the destination of the request is the first- 322 hop proxy). This header field contains a list of all the security 323 mechanisms that the client supports. The client SHOULD NOT add 324 preference parameters to this list. The client MUST add both a 325 Require and Proxy-Require header field with the value "sec-agree" to 326 its request. 328 The contents of the Security-Client header field may be used by the 329 server to include any necessary information in its response. 331 A server receiving an unprotected request that contains a Require or 332 Proxy-Require header field with the value "sec-agree" MUST respond to 333 the client with a 494 (Security Agreement Required) response. The 334 server MUST add a Security-Server header field to this response 335 listing the security mechanisms that the server supports. The server 336 MUST add its list to the response even if there are no common 337 security mechanisms in the client's and server's lists. The server's 338 list MUST NOT depend on the contents of the client's list. 340 The server MUST compare the list received in the Security-Client 341 header field with the list to be sent in the Security-Server header 342 field. When the client receives this response, it will choose the 343 common security mechanism with the highest "q" value. Therefore, the 344 server MUST add the necessary information so that the client can 345 initiate that mechanism (e.g., a Proxy-Authenticate header field for 346 HTTP Digest). 348 When the client receives a response with a Security-Server header 349 field, it MUST choose the security mechanism in the server's list 350 with the highest "q" value among all the mechanisms that are known to 351 the client. Then, it MUST initiate that particular security 352 mechanism as described in Section 3.5. This initiation may be 353 carried out without involving any SIP message exchange (e.g., 354 establishing a TLS connection). 356 If an attacker modified the Security-Client header field in the 357 request, the server may not include in its response the information 358 needed to establish the common security mechanism with the highest 359 preference value (e.g., the Proxy-Authenticate header field is 360 missing). A client detecting such a lack of information in the 361 response MUST consider the current security agreement process 362 aborted, and MAY try to start it again by sending a new request with 363 a Security-Client header field as described above. 365 All the subsequent SIP requests sent by the client to that server 366 SHOULD make use of the security mechanism initiated in the previous 367 step. These requests MUST contain a Security-Verify header field 368 that mirrors the server's list received previously in the Security- 369 Server header field. These requests MUST also have both a Require 370 and Proxy- Require header fields with the value "sec-agree". 372 The server MUST check that the security mechanisms listed in the 373 Security-Verify header field of incoming requests correspond to its 374 static list of supported security mechanisms. 376 Note that, following the standard SIP header field comparison 377 rules defined in [RFC3261], both lists have to contain the same 378 security mechanisms in the same order to be considered equivalent. 379 In addition, for each particular security mechanism, its 380 parameters in both lists need to have the same values. 382 The server can proceed processing a particular request if, and only 383 if, the list was not modified. If modification of the list is 384 detected, the server MUST respond to the client with a 494 (Security 385 Agreement Required) response. This response MUST include the 386 server's unmodified list of supported security mechanisms. If the 387 list was not modified, and the server is a proxy, it MUST remove the 388 "sec-agree" value from both the Require and Proxy-Require header 389 fields, and then remove the header fields if no values remain. 391 Once the security has been negotiated between two SIP entities, the 392 same SIP entities MAY use the same security when communicating with 393 each other in different SIP roles. For example, if a UAC and its 394 outbound proxy negotiate some security, they may try to use the same 395 security for incoming requests (i.e., the UA will be acting as a 396 UAS). 398 The user of a UA SHOULD be informed about the results of the security 399 mechanism agreement. The user MAY decline to accept a particular 400 security mechanism, and abort further SIP communications with the 401 peer. 403 2.3.2. Server Initiated 405 A server decides to use the security agreement described in this 406 document based on local policy. If a server receives a request from 407 the network interface that is configured to use this mechanism, it 408 must check that the request has only one Via entry. If there are 409 several Via entries, the server is not the first-hop SIP entity, and 410 it MUST NOT use this mechanism. For such a request, the server must 411 return a 502 (Bad Gateway) response. 413 A server that decides to use this agreement mechanism MUST challenge 414 unprotected requests with one Via entry regardless of the presence or 415 the absence of any Require, Proxy-Require or Supported header fields 416 in incoming requests. 418 A server that by policy requires the use of this specification and 419 receives a request that does not have the sec-agree option tag in a 420 Require, Proxy-Require or Supported header field MUST return a 421 421 (Extension Required) response. If the request had the sec-agree 422 option tag in a Supported header field, it MUST return a 494 423 (Security Agreement Required) response. In both situation the server 424 MUST also include in the response a Security-Server header field 425 listing its capabilities and a Require header field with an option- 426 tag "sec-agree" in it. The server MUST also add necessary 427 information so that the client can initiate the preferred security 428 mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest). 430 Clients that support the extension defined in this document SHOULD 431 add a Supported header field with a value of "sec-agree". 433 2.4. Security Mechanism Initiation 435 Once the client chooses a security mechanism from the list received 436 in the Security-Server header field from the server, it initiates 437 that mechanism. Different mechanisms require different initiation 438 procedures. 440 If "tls" is chosen, the client uses the procedures of Section 8.1.2 441 of [RFC3261]to determine the URI to be used as an input to the DNS 442 procedures of [RFC3263]. However, if the URI is a SIP URI, it MUST 443 treat the scheme as if it were sips, not sip. If the URI scheme is 444 not sip, the request MUST be sent using TLS. 446 If "digest" is chosen, the 494 (Security Agreement Required) response 447 will contain an HTTP Digest authentication challenge. The client 448 MUST use the algorithm and qop parameters in the Security-Server 449 header field to replace the same parameters in the HTTP Digest 450 challenge. The client MUST also use the digest-verify parameter in 451 the Security-Verify header field to protect the Security-Server 452 header field as specified in 2.2. 454 To use "ipsec-ike", the client attempts to establish an IKE 455 connection to the host part of the Request-URI in the first request 456 to the server. If the IKE connection attempt fails, the agreement 457 procedure MUST be considered to have failed, and MUST be terminated. 459 Note that "ipsec-man" will only work if the communicating SIP 460 entities know which keys and other parameters to use. It is outside 461 the scope of this specification to describe how this information can 462 be made known to the peers. All rules for minimum implementations, 463 such as mandatory-to-implement algorithms, apply as defined in 464 [RFC2401], [RFC2402], and [RFC2406]. 466 In both IPsec-based mechanisms, it is expected that appropriate 467 policy entries for protecting SIP have been configured or will be 468 created before attempting to use the security agreement procedure, 469 and that SIP communications use port numbers and addresses according 470 to these policy entries. It is outside the scope of this 471 specification to describe how this information can be made known to 472 the peers, but it would typically be configured at the same time as 473 the IKE credentials or manual SAs have been entered. 475 2.5. Duration of Security Associations 477 Once a security mechanism has been negotiated, both the server and 478 the client need to know until when it can be used. All the 479 mechanisms described in this document have a different way of 480 signaling the end of a security association. When TLS is used, the 481 termination of the connection indicates that a new negotiation is 482 needed. IKE negotiates the duration of a security association. If 483 the credentials provided by a client using digest are no longer 484 valid, the server will re-challenge the client. It is assumed that 485 when IPsec-man is used, the same out-of-band mechanism used to 486 distribute keys is used to define the duration of the security 487 association. 489 2.6. Summary of Header Field Use 491 The header fields defined in this document may be used to negotiate 492 the security mechanisms between a UAC and other SIP entities 493 including UAS, proxy, and registrar. Information about the use of 494 headers in relation to SIP methods and proxy processing is summarized 495 in Table 1. 497 Header field where proxy ACK BYE CAN INV OPT REG 498 _________________________________________________________________ 499 Security-Client R ard - o - o o o 500 Security-Server 421,494 - o - o o o 501 Security-Verify R ard - o - o o o 503 Header field where proxy SUB NOT PRK IFO UPD MSG 504 _________________________________________________________________ 505 Security-Client R ard o o - o o o 506 Security-Server 421,494 o o - o o o 507 Security-Verify R ard o o - o o o 509 Table 1: Summary of Header Usage. 511 The "where" column describes the request and response types in which 512 the header field may be used. The header may not appear in other 513 types of SIP messages. Values in the where column are: 515 o R: Header field may appear in requests. 517 o 421, 494: A numerical value indicates response codes with which 518 the header field can be used. 520 The "proxy" column describes the operations a proxy may perform on a 521 header field: 523 o a: A proxy can add or concatenate the header field if not present. 525 o r: A proxy must be able to read the header field, and thus this 526 header field cannot be encrypted. 528 o d: A proxy can delete a header field value. 530 The next six columns relate to the presence of a header field in a 531 method: 533 o o: The header field is optional. 535 3. Backwards Compatibility 537 The use of this extension in a network interface is a matter of local 538 policy. Different network interfaces may follow different policies, 539 and consequently the use of this extension may be situational by 540 nature. UA and server implementations MUST be configurable to 541 operate with or without this extension. 543 A server that is configured to use this mechanism, may also accept 544 requests from clients that use TLS based on the rules defined in 545 [RFC3263]. Requests from clients that do not support this extension, 546 and do not support TLS, can not be accepted. This obviously breaks 547 interoperability with some SIP clients. Therefore, this extension 548 should be used in environments where it is somehow ensured that every 549 client implements this extension or is able to use TLS. This 550 extension may also be used in environments where insecure 551 communication is not acceptable if the option of not being able to 552 communicate is also accepted. 554 4. Examples 556 The following examples illustrate the use of the mechanism defined 557 above. 559 4.1. Client Initiated 561 A UA negotiates the security mechanism to be used with its outbound 562 proxy without knowing beforehand which mechanisms the proxy supports. 563 The OPTIONS method can be used here to request the security 564 capabilities of the proxy. In this way, the security can be 565 initiated even before the first INVITE is sent via the proxy. 567 UAC Proxy UAS 568 | | | 569 |----(1) OPTIONS---->| | 570 | | | 571 |<-----(2) 494-------| | 572 | | | 573 |<=======TLS========>| | 574 | | | 575 |----(3) INVITE----->| | 576 | |----(4) INVITE--->| 577 | | | 578 | |<---(5) 200 OK----| 579 |<---(6) 200 OK------| | 580 | | | 581 |------(7) ACK------>| | 582 | |-----(8) ACK----->| 583 | | | 584 | | | 585 | | | 586 | | | 588 Figure 2: Negotiation Initiated by the Client. 590 The UAC sends an OPTIONS request to its outbound proxy, indicating at 591 the same time that it is able to negotiate security mechanisms and 592 that it supports TLS and HTTP Digest (1). 594 The outbound proxy responds to the UAC with its own list of security 595 mechanisms - IPsec and TLS (2). The only common security mechanism 596 is TLS, so they establish a TLS connection between them. When the 597 connection is successfully established, the UAC sends an INVITE 598 request over the TLS connection just established (3). This INVITE 599 contains the server's security list. The server verifies it, and 600 since it matches its static list, it processes the INVITE and 601 forwards it to the next hop. 603 If this example was run without Security-Server header in Step 2, the 604 UAC would not know what kind of security the other one supports, and 605 would be forced to error-prone trials. 607 More seriously, if the Security-Verify was omitted in Step 3, the 608 whole process would be prone for MitM attacks. An attacker could 609 spoof "ICMP Port Unreachable" message on the trials, or remove the 610 stronger security option from the header in Step 1, therefore 611 substantially reducing the security. 613 (1) OPTIONS sip:proxy.example.com SIP/2.0 614 Security-Client: tls 615 Security-Client: digest 616 Require: sec-agree 617 Proxy-Require: sec-agree 619 (2) SIP/2.0 494 Security Agreement Required 620 Security-Server: ipsec-ike;q=0.1 621 Security-Server: tls;q=0.2 623 (3) INVITE sip:proxy.example.com SIP/2.0 624 Security-Verify: ipsec-ike;q=0.1 625 Security-Verify: tls;q=0.2 626 Route: sip:callee@domain.com 627 Require: sec-agree 628 Proxy-Require: sec-agree 630 The 200 OK response (6) for the INVITE and the ACK (7) are also sent 631 over the TLS connection. The ACK will contain the same Security- 632 Verify header field as the INVITE (3). 634 4.2. Server Initiated 636 In this example of Figure 3 the client sends an INVITE towards the 637 callee using an outbound proxy. This INVITE does not contain any 638 Require header field. 640 UAC Proxy UAS 641 | | | 642 |-----(1) INVITE---->| | 643 | | | 644 |<-----(2) 421-------| | 645 | | | 646 |------(3) ACK------>| | 647 | | | 648 |<=======IKE========>| | 649 | | | 650 |-----(4) INVITE---->| | 651 | |----(5) INVITE--->| 652 | | | 653 | |<---(6) 200 OK----| 654 |<----(7) 200 OK-----| | 655 | | | 656 |------(8) ACK------>| | 657 | |-----(9) ACK----->| 658 | | | 659 | | | 661 Figure 3: Server Initiated Security Negotiation. 663 The proxy, following its local policy, does not accept the INVITE. 664 It returns a 421 (Extension Required) with a Security-Server header 665 field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE 666 it performs the key exchange and establishes a security association 667 with the proxy. 669 The second INVITE (4) and the ACK (8) contain a Security-Verify 670 header field that mirrors the Security-Server header field received 671 in the 421. The INVITE (4), the 200 OK (7) and the ACK (8) are sent 672 using the security association that has been established. 674 (1) INVITE sip:uas.example.com SIP/2.0 676 (2) SIP/2.0 421 Extension Required 677 Security-Server: ipsec-ike;q=0.1 678 Security-Server: tls;q=0.2 680 (4) INVITE sip:uas.example.com SIP/2.0 681 Security-Verify: ipsec-ike;q=0.1 682 Security-Verify: tls;q=0.2 684 5. Security Considerations 686 This specification is about making it possible to select between 687 various SIP security mechanisms in a secure manner. In particular, 688 the method presented herein allow current networks using, for 689 instance, HTTP Digest, to be securely upgraded to, for instance, 690 IPsec without requiring a simultaneous modification in all equipment. 691 The method presented in this specification is secure only if the 692 weakest proposed mechanism offers at least integrity and replay 693 protection for the Security-Verify header field. 695 The security implications of this are subtle, but do have a 696 fundamental importance in building large networks that change over 697 time. Given that the hashes are produced also using algorithms 698 agreed in the first unprotected messages, one could ask what the 699 difference in security really is. Assuming integrity protection is 700 mandatory and only secure algorithms are used, we still need to 701 prevent MitM attackers from modifying other parameters, such as 702 whether encryption is provided or not. Let us first assume two peers 703 capable of using both strong and weak security. If the initial 704 offers are not protected in any way, any attacker can easily 705 "downgrade" the offers by removing the strong options. This would 706 force the two peers to use weak security between them. But if the 707 offers are protected in some way -- such as by hashing, or repeating 708 them later when the selected security is really on -- the situation 709 is different. It would not be sufficient for the attacker to modify 710 a single message. Instead, the attacker would have to modify both 711 the offer message, as well as the message that contains the hash/ 712 repetition. More importantly, the attacker would have to forge the 713 weak security that is present in the second message, and would have 714 to do so in real time between the sent offers and the later messages. 715 Otherwise, the peers would notice that the hash is incorrect. If the 716 attacker is able to break the weak security, the security method 717 and/or the algorithm should not be used. 719 In conclusion, the security difference is making a trivial attack 720 possible versus demanding the attacker to break algorithms. An 721 example of where this has a serious consequence is when a network is 722 first deployed with integrity protection (such as HTTP Digest 723 [RFC2617]), and then later new devices are added that support also 724 encryption (such as TLS [RFC2246]). In this situation, an insecure 725 negotiation procedure allows attackers to trivially force even new 726 devices to use only integrity protection. 728 Possible attacks against the security agreement include: 730 1. Attackers could try to modify the server's list of security 731 mechanisms in the first response. This would be revealed to the 732 server when the client returns the received list using the 733 security. 735 2. Attackers could also try to modify the repeated list in the 736 second request from the client. However, if the selected 737 security mechanism uses encryption this may not be possible, and 738 if it uses integrity protection any modifications will be 739 detected by the server. 741 3. Attackers could try to modify the client's list of security 742 mechanisms in the first message. The client selects the security 743 mechanism based on its own knowledge of its own capabilities and 744 the server's list, hence the client's choice would be unaffected 745 by any such modification. However, the server's choice could 746 still be affected as described below: 748 * If the modification affected the server's choice, the server 749 and client would end up choosing different security mechanisms 750 in Step 3 or 4 of Figure 1. Since they would be unable to 751 communicate to each other, this would be detected as a 752 potential attack. The client would either retry or give up in 753 this situation. 755 * If the modification did not affect the server's choice, 756 there's no effect. 758 4. Finally, attackers may also try to reply old security agreement 759 messages. Each security mechanism must provide replay 760 protection. In particular, HTTP Digest implementations should 761 carefully utilize existing reply protection options such as 762 including a time-stamp to the nonce parameter, and using nonce 763 counters [RFC2617]. 765 All clients that implement this specification MUST select HTTP 766 Digest, TLS, IPsec, or any stronger method for the protection of the 767 second request. 769 6. IANA Considerations 771 This specification defines a new mechanism-name namespace in Section 772 2.2 which requires a central coordinating body. The body responsible 773 for this coordination is the Internet Assigned Numbers Authority 774 (IANA). 776 This document defines four mechanism-names to be initially 777 registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man". In 778 addition to these mechanism-names, "ipsec-3gpp" mechanism-name is 779 also registered (see Appendix A). Following the policies outlined in 780 [RFC2434], further mechanism-names are allocated based on IETF 781 Consensus. 783 Registrations with the IANA MUST include the mechanism-name token 784 being registered, and a pointer to a published RFC describing the 785 details of the corresponding security mechanism. Further, the 786 registration MUST include contact information for the party 787 responsible for the registration. 789 6.1. Registration Information 791 IANA registers new mechanism-names at 792 http://www.iana.org/assignments/sip-parameters under "Security 793 Mechanism Names". As this document specifies five mechanism-names, 794 the initial IANA registration for mechanism-names will contain the 795 information shown in Table 2. It also demonstrates the type of 796 information maintained by the IANA. 798 Mechanism Name Contact Reference 799 -------------- ------- --------- 800 digest [1] [RFCNNNN] 801 tls [1] [RFCNNNN] 802 ipsec-ike [1] [RFCNNNN] 803 ipsec-man [1] [RFCNNNN] 804 ipsec-3gpp [1] [RFCNNNN] 806 People 807 ------ 808 [1] Jari Arkko 809 Vesa Torvinen 810 Gonzalo Camarillo 811 Aki Niemi 812 Tao Haukka 814 References 815 ---------- 816 [RFCNNNN] Arkko, et. al., "Security Mechanism Agreement for the 817 Session Initiation Protocol", RFC NNNN, October 2002. 819 Table2: Initial IANA registration. 821 6.2. Registration Template 823 To: ietf-sip-sec-agree-mechanism-name@iana.org 824 Subject: Registration of a new SIP Security Agreement mechanism 826 Mechanism Name: 828 (Token value conforming to the syntax described in 829 Section 2.2.) 831 Published Specification(s): 833 (Descriptions of new SIP Security Agreement mechanisms 834 require a published RFC.) 836 6.3. Header Field Names 838 This specification registers three new header fields, namely 839 Security-Client, Security-Server and Security-Verify. These headers 840 are defined by the following information, which has been included in 841 the sub-registry for SIP headers under 842 http://www.iana.org/assignments/sip-parameters. 844 Header Name: Security-Client 845 Compact Form: (none) 847 Header Name: Security-Server 848 Compact Form: (none) 850 Header Name: Security-Verify 851 Compact Form: (none) 853 6.4. Response Codes 855 This specification registers a new response code, namely 494 856 (Security Agreement Required). The response code is defined by the 857 following information, which has been included to the sub-registry 858 for SIP methods and response-codes under 859 http://www.iana.org/assignments/sip-parameters. 861 Response Code Number: 494 862 Default Reason Phrase: Security Agreement Required 864 6.5. Option Tags 866 This specification defines a new option tag, namely sec-agree. The 867 option tag is defined by the following information, which has been 868 included in the sub-registry for option tags under 869 http://www.iana.org/assignments/sip-parameters. 871 Name: sec-agree 872 Description: This option tag indicates support for the Security 873 Agreement mechanism. When used in the Require, or 874 Proxy-Require headers, it indicates that proxy 875 servers are required to use the Security Agreement 876 mechanism. When used in the Supported header, it 877 indicates that the User Agent Client supports the 878 Security Agreement mechanism. When used in the 879 Require header in the 494 (Security Agreement 880 Required) or 421 (Extension Required) responses, it 881 indicates that the User Agent Client must use the 882 Security Agreement Mechanism. 884 7. Contributors 886 Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to 887 the document. 889 8. Acknowledgements 891 In addition to the contributors, the authors wish to thank Allison 892 Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, 893 Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia, 894 Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP 895 SA3 group for interesting discussions in this problem space. 897 9. References 899 9.1. Normative References 901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, March 1997. 904 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 905 RFC 2246, January 1999. 907 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 908 Internet Protocol", RFC 2401, November 1998. 910 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 911 RFC 2402, November 1998. 913 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 914 Payload (ESP)", RFC 2406, November 1998. 916 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 917 (IKE)", RFC 2409, November 1998. 919 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 920 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 921 October 1998. 923 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 924 Leach, P., Luotonen, A., and L. Stewart, "HTTP 925 Authentication: Basic and Digest Access Authentication", 926 RFC 2617, June 1999. 928 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 929 A., Peterson, J., Sparks, R., Handley, M., and E. 930 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 931 June 2002. 933 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 934 Protocol (SIP): Locating SIP Servers", RFC 3263, 935 June 2002. 937 9.2. Informative References 939 [I-D.ietf-sipping-3gpp-r5-requirements] 940 Garcia-Martin, M., "3rd-Generation Partnership Project 941 (3GPP) Release 5 requirements on the Session Initiation 942 Protocol (SIP)", 943 draft-ietf-sipping-3gpp-r5-requirements-00 (work in 944 progress), October 2002. 946 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 947 ESP and AH", RFC 2403, November 1998. 949 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 950 ESP and AH", RFC 2404, November 1998. 952 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 953 Algorithms", RFC 2451, November 1998. 955 [TS33.203] 956 3rd Generation Partnership Project, "Access security for 957 IP-based services, Release 5", TS 33.203 v5.3.0, 958 September 2002. 960 Appendix A. Syntax of ipsec-3gpp 962 This appendix extends the security agreement framework described in 963 this document with a new security mechanism: "ipsec-3gpp". This 964 security mechanism and its associated parameters are used in the 3GPP 965 IP Multimedia Subsystem [TS33.203]. The Augmented BNF definitions 966 below follow the syntax of SIP [RFC3261]. 968 mechanism-name = ( "ipsec-3gpp" ) 969 mech-parameters = ( algorithm / protocol /mode / 970 encrypt-algorithm / spi / 971 port1 / port2 ) 972 algorithm = "alg" EQUAL ( "hmac-md5-96" / 973 "hmac-sha-1-96" ) 974 protocol = "prot" EQUAL ( "ah" / "esp" ) 975 mode = "mod" EQUAL ( "trans" / "tun" ) 976 encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" ) 977 spi = "spi" EQUAL spivalue 978 spivalue = 10DIGIT; 0 to 4294967295 979 port1 = "port1" EQUAL port 980 port2 = "port2" EQUAL port 981 port = 1*DIGIT 983 The parameters described by the BNF above have the following 984 semantics: 986 Algorithm 987 This parameter defines the used authentication algorithm. It may 988 have a value of "hmac-md5-96" for HMAC-MD5-96 [RFC2403], or "hmac- 989 sha-1-96" for HMAC-SHA-1-96 [RFC2404]. The algorithm parameter is 990 mandatory. 992 Protocol 993 This parameter defines the IPsec protocol. It may have a value of 994 "ah" for AH [RFC2402], or "esp" for ESP [RFC2406]. If no Protocol 995 parameter is present, the protocol will be ESP by default. 997 Mode 998 This parameter defines the mode in which the IPsec protocol is 999 used. It may have a value of "trans" for transport mode, or a 1000 value of "tun" for tunneling mode. If no Mode parameter is 1001 present the IPsec protocol is used in transport mode. 1003 Encrypt-algorithm 1004 This parameter defines the used encryption algorithm. It may have 1005 a value of "des-ede3-cbc" for 3DES [RFC2451], or "null" for no 1006 encryption. If no Encrypt-algorithm parameter is present, 1007 encryption is not used. 1009 Spi 1010 Defines the SPI number used for inbound messages. 1012 Port1 1013 Defines the destination port number for inbound messages that are 1014 protected. 1016 Port2 1017 Defines the source port number for outbound messages that are 1018 protected. Port 2 is optional. 1020 The communicating SIP entities need to know beforehand which keys to 1021 use. It is also assumed that the underlying IPsec implementation 1022 supports selectors that allow all transport protocols supported by 1023 SIP to be protected with a single SA. The duration of security 1024 association is the same as in the expiration interval of the 1025 corresponding registration binding. 1027 Authors' Addresses 1029 Jari Arkko 1030 Ericsson 1031 Hirsalantie 1 1032 Jorvas, FIN 02420 1033 Finland 1035 Phone: +358 40 507 9256 1036 Email: jari.arkko@ericsson.com 1038 Vesa Torvinen 1039 Ericsson 1040 Hirsalantie 1 1041 Jorvas, FIN 02420 1042 Finland 1044 Phone: +358 40 723 0822 1045 Email: vesa.torvinen@ericsson.fi 1047 Gonzalo Camarillo 1048 Ericsson 1049 Hirsalantie 1 1050 Jorvas, FIN 02420 1051 Finland 1053 Phone: +358 aa bbb cccc 1054 Email: gonzalo.camarillo@ericsson.com 1056 Aki Niemi 1057 Nokia Research Center 1058 P.O. Box 407 1059 NOKIA GROUP, FIN 00045 1060 Finland 1062 Phone: +358 50 389 1644 1063 Email: aki.niemi@nokia.com 1064 Tao Haukka 1065 Nokia 1066 P.O. Box aaa 1067 NOKIA GROUP, FIN 00045 1068 Finland 1070 Phone: +358 40 517 0079 1071 Email: tao.haukka@nokia.com 1073 Intellectual Property Statement 1075 The IETF takes no position regarding the validity or scope of any 1076 Intellectual Property Rights or other rights that might be claimed to 1077 pertain to the implementation or use of the technology described in 1078 this document or the extent to which any license under such rights 1079 might or might not be available; nor does it represent that it has 1080 made any independent effort to identify any such rights. Information 1081 on the procedures with respect to rights in RFC documents can be 1082 found in BCP 78 and BCP 79. 1084 Copies of IPR disclosures made to the IETF Secretariat and any 1085 assurances of licenses to be made available, or the result of an 1086 attempt made to obtain a general license or permission for the use of 1087 such proprietary rights by implementers or users of this 1088 specification can be obtained from the IETF on-line IPR repository at 1089 http://www.ietf.org/ipr. 1091 The IETF invites any interested party to bring to its attention any 1092 copyrights, patents or patent applications, or other proprietary 1093 rights that may cover technology that may be required to implement 1094 this standard. Please address the information to the IETF at 1095 ietf-ipr@ietf.org. 1097 Disclaimer of Validity 1099 This document and the information contained herein are provided on an 1100 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1101 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1102 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1103 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1104 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1105 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1107 Copyright Statement 1109 Copyright (C) The Internet Society (2006). This document is subject 1110 to the rights, licenses and restrictions contained in BCP 78, and 1111 except as set forth therein, the authors retain all their rights. 1113 Acknowledgment 1115 Funding for the RFC Editor function is currently provided by the 1116 Internet Society.