idnits 2.17.1 draft-dawes-dispatch-mediasec-parameter-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 39 instances of too long lines in the document, the longest one being 200 characters in excess of 72. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 328 has weird spacing: '...me1.net pcscf...' == Line 532 has weird spacing: '...me1.net pcsc...' == Line 798 has weird spacing: '...-Client media...' == Line 799 has weird spacing: '...-Server media...' == Line 800 has weird spacing: '...-Verify media...' -- The document date (October 01, 2013) is 3853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC5234' on line 784 -- Looks like a reference, but probably isn't: 'RFC3968' on line 786 -- Looks like a reference, but probably isn't: 'RFC5226' on line 828 == Unused Reference: '2' is defined on line 870, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 880, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 884, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 896, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 903, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 908, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 913, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 916, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (ref. '6') (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 2409 (ref. '9') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 5226 (ref. '10') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4234 (ref. '13') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2234 (ref. '14') (Obsoleted by RFC 4234) Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Dawes 3 Internet-Draft Vodafone Group 4 Intended status: Informational October 01, 2013 5 Expires: April 04, 2014 7 Security Mechanism Names for Media 8 draft-dawes-dispatch-mediasec-parameter-07.txt 10 Abstract 12 Negotiating the security mechanisms used between a Session Initiation 13 Protocol (SIP) user agent and its next-hop SIP entity is described in 14 RFC 3329 [4]. This document adds the capability to distinguish 15 security mechanisms that apply to the media plane by defining a new 16 Session Initiation Protocol (SIP) header field parameter to label 17 such security mechanisms. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [3]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 04, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Access Network Protection . . . . . . . . . . . . . . . . . . 3 62 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Signalling security negotiation . . . . . . . . . . . . . 4 64 4.2. Header fields for signalling security negotiation . . . . 4 65 4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 5 67 4.4.1. The "mediasec" Header Field Parameter . . . . . . . . 5 68 4.4.2. Client Initiated . . . . . . . . . . . . . . . . . . 5 69 4.5. Security Mechanism Initiation . . . . . . . . . . . . . . 6 70 4.6. Duration of Security Assocations . . . . . . . . . . . . 6 71 4.7. Summary of Header Field Use . . . . . . . . . . . . . . . 7 72 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 73 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6.1. Initial Registration 3GPP . . . . . . . . . . . . . . . . 7 75 6.2. Re-Registration 3GPP . . . . . . . . . . . . . . . . . . 12 76 6.3. Client Initiated as per RFC 3329 . . . . . . . . . . . . 14 77 6.4. Server Initiated as per RFC 3329 . . . . . . . . . . . . 15 78 6.5. Using Media Plane Security . . . . . . . . . . . . . . . 16 79 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 9.1. Registry for Media Plane Security Mechanisms . . . . . . 18 83 9.2. Registration Template . . . . . . . . . . . . . . . . . . 19 84 9.3. Header Field Names . . . . . . . . . . . . . . . . . . . 19 85 9.4. Response Codes . . . . . . . . . . . . . . . . . . . . . 19 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 11.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Appendix A. Additional stuff . . . . . . . . . . . . . . . . . . 20 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Problem Statement 95 In the 3GPP defined architecture and SIP profile for packet-domain 96 communication, SIP signalling is security protected at the network 97 layer but media-plane traffic is not (it is protected by the cellular 98 wireless access). The SIP signalling security used by 3GPP runs from 99 the user device to the first hop proxy and negotiation of security 100 mechanism and the start of security protection is described in RFC 101 3329 [4]. Because the 3GPP architecture also allows access 102 technologies that do not protect media, e.g. WiFi, this document 103 extends the negotiation of security mechanism to the media plane. 104 During previous discussion of the topic of media plane security it 105 was suggested that DTLS-SRTP should be used, but 3GPP considered this 106 impractical to implement in the 3GPP-defined architecture and also 107 limited in terms of meeting all 3GPP requirements which include 108 protection of non-RTP media such as MSRP. 110 The purpose of this specification is to define a new header field 111 parameter for the Session Initiation Protocol (SIP) [1] that 112 distinguishes security mechanisms that apply to the media plane and 113 to create an IANA registry for these mechanisms. This header field 114 parameter may be used with the Security-Client, Security-Server, and 115 Security-Verify header fields defined by RFC 3329 [4]. 117 2. Introduction 119 RFC 3329 [4] describes negotiation of a security mechanism for SIP 120 signalling between a UAC and its first hop proxy and allows a client 121 or network to ensure that protection of SIP signalling is is turned 122 on when the client registers with the network. SIP signalling is 123 then protected as it traverses the access network. To enable similar 124 protection for media, this document enables client and network to 125 exchange their security capabilities for the media plane combined 126 with the negotiation described in RFC 3329 [4]. Similar to the 127 signalling plane, the evolution of security mechanisms for media 128 often introduces new algorithms, or uncovers problems in existing 129 ones, making capability exchange of such mechanisms a necessity. 131 3. Access Network Protection 133 Some access technologies, such as many cellular wireless accesses, 134 protect the data passed over them by default but some, such as WLAN, 135 do not. For accesses with no inherent protection, it is useful for 136 the media controlled by SIP signalling to be protected by default 137 because of vulnerability to eavesdropping. It is currently possible 138 for a UA to request protection of the media plane end-to-end by 139 including the crypto attribute in SDP at session setup. This does 140 not guarantee protection however, because it relies on support of 141 encryption by the called UA, or by another entity in the path taken 142 by the media. In some cases, the session will originate in an access 143 that protects the media and terminate in one that does not, meaning 144 that media is protected in all but some hops of its path. In cases 145 where the same provider supplies the user equipment and provides the 146 IP access, the IP access technology that the UA will use is 147 predictable and the media is vulnerable only as far as the core 148 network. In such cases, the user equipment it is possible to protect 149 the media plane by encrypting at the UA and decrypting at the edge of 150 the core network, and for the user agent that originates or 151 terminates the session to expect the edge of the core network to be 152 capable of encrypting and decrypting media. The header field 153 parameter described in this document enables this case of first-hop 154 protection, which is typically provided by default to a user agent. 156 4. Solution 158 4.1. Signalling security negotiation 160 A specification already exists for setting up security for SIP 161 signaling between a client and its first-hop proxy, as defined in RFC 162 3329 [4] which gives an overview of the mechanism as follows: 164 1. Client ----------client list---------> Server 165 2. Client <---------server list---------- Server 166 3. Client ------(turn on security)------- Server 167 4. Client ----------server list---------> Server 168 5. Client <---------ok or error---------- Server 170 Figure 1: Security agreement message flow from RFC 3329 172 The security mechanism above ensures that SIP signalling is protected 173 between a client and its first hop entity but the media plane is 174 still unprotected. This document proposes that client and server 175 additionally exchange their media plane security capabilities at step 176 1 and 2. Media plane security needs to be applied on a per-media 177 basis at the time that media is initiated. Therefore the client and 178 server need not turn on media plane security immediately. 180 This document defines the "mediasec" header field parameter that 181 labels any of the Security-Client:, Security-Server:, or Security- 182 Verify: header fields as applicable to the media plane and not the 183 signalling plane. 185 4.2. Header fields for signalling security negotiation 187 The "mediasec" header field parameter defined in this document is 188 used with procedures defined in RFC 3329 [4] to distinguish media 189 plane security, with the difference that media plane security need 190 not be started immediately and can be applied and removed on-the-fly 191 as media are added and removed within a session. The SIP responses 192 that can contain the Security-Client, Security-Server, and Security- 193 Verfiy header fields are SIP responses 421 (Extension Required) and 194 494 (Security Agreement Required) as defined in RFC 3329 [4]. 196 4.3. Syntax 198 This document does not define any new SIP header fields, it defines a 199 header field parameter for header fields Security-Client, Security- 200 Server and Security-Verify defined in RFC 3329 [4]. 202 4.4. Protocol Operation 204 4.4.1. The "mediasec" Header Field Parameter 206 The "mediasec" header field parameter may be used in the Security- 207 Client, Security-Server, or Security-Verfiy header fields defined in 208 RFC 3329 [4] to indicate that a header field applies to the media 209 plane. Any one of the media plane security mechanisms supported by 210 both client and server, if any, may be applied when a media stream is 211 started. Or a media stream may be set up without security. 213 Values in the Security-Client, Security-Server, or Security-Verfiy 214 header fields labelled with the "mediasec" header field parameter are 215 specfic to the media plane and specific to the secure media transport 216 protocol used on the media plane. 218 4.4.2. Client Initiated 220 A client wishing to use the security capability exchange of this 221 specification MUST add a Security-Client header field to a request 222 addressed to its first-hop proxy (i.e., the destination of the 223 request is the first-hop proxy). This header field contains a list 224 of all the media plane security mechanisms that the client supports. 225 The client SHOULD NOT add preference parameters to this list. The 226 client MUST add a "mediasec" header field parameter to the Security- 227 Client header field. 229 The contents of the Security-Client header field may be used by the 230 server to include any necessary information in its response. 232 As described in RFC 3329 [4], the response will be 494 if the client 233 includes "sec-agree" in the Require and Proxy-Require header fields, 234 or a 2xx response if the Require and Proxy-Require header fields do 235 not contain "sec-agree". The server MUST add its list to the 236 response even if there are no common security mechanisms in the 237 client's and server's lists. The server's list MUST NOT depend on 238 the contents of the client's list. 240 Any subsequent SIP requests sent by the client to that server MAY 241 make use of the media security capabilities exchanged in the previous 242 step by including media plane security parameters in SDP in the 243 session or the media description. These requests MUST contain a 244 Security-Verify header field that mirrors the server's list received 245 previously in the Security-Server header field. 247 The server MUST check that the security mechanisms listed in the 248 Security-Verify header field of incoming requests correspond to its 249 static list of supported security mechanisms. 251 Note that, following the standard SIP header field comparison rules 252 defined in RFC 3261 [7], both lists have to contain the same security 253 mechanisms in the same order to be considered equivalent. In 254 addition, for each particular security mechanism, its parameters in 255 both lists need to have the same values. 257 The server can proceed processing a particular request if, and only 258 if, the list was not modified. If modification of the list is 259 detected, the server MUST respond to the client with a 494 (Security 260 Agreement Required) response. This response MUST include the 261 server's unmodified list of supported security mechanisms. 263 Once security capabilities have been exchanged between two SIP 264 entities, the same SIP entities MAY use the same security when 265 communicating with each other in different SIP roles. For example, 266 if a UAC and its outbound proxy exchange some media-plane security 267 mechanisms, they may try to use the same security for incoming 268 requests (i.e., the UA will be acting as a UAS). 270 The user of a UA SHOULD be informed about the results of the security 271 mechanism agreement. The user MAY decline to accept a particular 272 security mechanism, and abort further SIP communications with the 273 peer. 275 4.5. Security Mechanism Initiation 277 Once the client chooses a security mechanism from the list received 278 in the Security-Server header field from the server, it MAY initiate 279 that mechanism on a session level, or on a media level when it 280 initiates new media in an existing session. 282 4.6. Duration of Security Assocations 284 Once media-plane security capabilities have been exchanged, both the 285 server and the client need to know until when they can be used. The 286 media plane security mechanism setup is valid for as long as the UA 287 has a SIP signalling relationship with its first-hop proxy or until 288 new keys are exchanged in SDP. The SDP used to set up media plane 289 security will be protected by a security association used to protect 290 SIP signalling and the media plane security mechanism can be used 291 until the signalling plane security association expires. 293 4.7. Summary of Header Field Use 295 The header fields defined in this document may be used to exchange 296 supported media plane security mechanisms between a UAC and other SIP 297 entities including UAS, proxy, and registrar. Information about the 298 use of headers in relation to SIP methods and proxy processing is 299 given in RFC 3329 [4] Table 1. 301 5. Backwards Compatibility 303 Security mechanisms that apply to the media plane only MUST NOT have 304 the same name as any signalling plane mechanism. If a signalling 305 plane security mechanism name is re-used for the media plane and 306 distinguished only by the "mediasec" parameter, then implementations 307 that do not recognize the "mediasec" parameter may incorrectly use 308 that security mechanism for the signalling plane. 310 6. Examples 312 The following examples illustrate the use of the mediasec header 313 field parameter defined above. 315 6.1. Initial Registration 3GPP 317 At initial registration, the client includes its supported media 318 plane security mechanisms in the SIP REGISTER request. The first-hop 319 proxy returns its supported media plane security mechanisms in the 320 SIP 401 (Unauthorized) response. 322 As per RFC 3329 [4], a UA negotiates the security mechanism for the 323 media plane to be used with its outbound proxy without knowing 324 beforehand which mechanisms the proxy supports, as shown in Figure 2 325 below. 327 UAC Proxy Registrar 328 user1_public1@home1.net pcscf1.home1.net registrar.home1.net 329 | | | 330 |------(1) REGISTER---->| | 331 | Security-Client: sdes-srtp; mediasec 332 | | | 333 | |---(2) REGISTER--->| 334 | | | 335 | |<----(3) 401-------| 336 | | | 337 |<-----(4) 401----------| | 338 | Security-Server: sdes-srtp; mediasec 339 | | | 340 |-----(5) REGISTER----->| | 341 | Security-Client: sdes-srtp; mediasec 342 | Security-Verify: sdes-srtp; mediasec 343 | | | 344 | |---(6) REGISTER--->| 345 | | | 346 | |<----(7) 200 OK----| 347 | | | 348 |<-----(8) 200 OK------ | | 349 | | | 350 |------(9) INVITE------>| | 351 | Security-Verify: sdes-srtp; mediasec 352 | | | 353 | Content-Type: application/sdp | 354 | a=3ge2ae | | 355 | a=crypto:1 AES_CM_128_HMAC_SHA1_80 356 | inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 357 | FEC_ORDER=FEC_SRTP | 358 | | | 360 Figure 2: Exchange of Media Security Mechanisms at Initial 361 Registration 363 The UAC sends a REGISTER request (1) to its outbound proxy indicating 364 the security mechanisms for the media plane and that it supports in a 365 Security-Client: header field. Indication of media security 366 mechanisms is identified by the "mediasec" header field parameter. 368 The outbound proxy forwards the REGISTER request (2) to the registrar 369 with the Security-Client: header field removed as described in RFC 370 3329 [4]. 372 The registrar responds with a 401 (Unauthorized) response (3) to the 373 REGISTER request. 375 The outbound proxy responds forwards the 401 (Unauthorized) response 376 (4) to the UAC with its own list of security mechanisms for the media 377 plane in the Security-Server: header field. Security mechanisms for 378 the media plane are distinguished by the "mediasec" header field 379 parameter. 381 The UAC sends a second REGISTER request (5) using the security 382 credentials it received in the 401 (Unauthorized) response. The UAC 383 includes the security mechanisms for the media plane and that it 384 supports in a Security-Client: header field. The UAC also echos the 385 list of security mechanisms it received from the outbound proxy in 386 the Security-Server: header field. Media security mechanisms are 387 distinguished by the "mediasec" header field parameter. 389 The REGISTER request is forwarded to the registrar (6) and the 390 registrar responds with 200 OK (7), which is forwarded to the UAC 391 (8). 393 When the connection is successfully established, the UAC sends an 394 INVITE request(9) including an SDP description of the media plane 395 security to be used (a="e2ae" and a crypto attribute). This INVITE 396 contains a copy of the server's security list in a Security-Verify 397 header field. The server verifies it, and since it matches its 398 static list, it processes the INVITE and forwards it to the next hop. 400 If this example was run without the Security-Server header field in 401 Step (2), the UAC would not know what kind of security the other one 402 supports, and would be forced to make error-prone trials. 404 More seriously, if the Security-Verify header field was omitted in 405 Step (3), the whole process would be prone to MitM attacks. An 406 attacker could remove the media plane security description from the 407 header in Step (1), therefore preventing protection of the media 408 plane. 410 (1) REGISTER sip:registrar.home1.net SIP/2.0 411 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 412 Max-Forwards: 70 413 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 414 From: ;tag=4fa3 415 To: 416 Contact: ;expires=600000 417 Call-ID: apb03a0s09dkjdfglkj49111 418 Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:registrar.home1.net", response="" 419 Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 420 Security-Client: sdes-srtp; mediasec ***new*** 421 Require: sec-agree 422 Proxy-Require: sec-agree 423 CSeq: 1 REGISTER 424 Supported: path 425 Content-Length: 0 427 (2) REGISTER sip:registrar.home1.net SIP/2.0 428 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 429 Max-Forwards: 69 430 P-Access-Network-Info: 431 Path: 432 Require: 433 P-Visited-Network-ID: 434 P-Charging-Vector: 435 From: 436 To: 437 Contact: 438 Call-ID: 439 Authorization: 440 CSeq: 441 Supported: 442 Content-Length: 444 (3) SIP/2.0 401 Unauthorized 445 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 446 From: ;tag=4fa3 447 To: ; tag=5ef4 448 Call-ID: apb03a0s09dkjdfglkj49111 449 WWW-Authenticate: Digest realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, ik="00112233445566778899aabbccddeeff", ck="ffeeddccbbaa11223344556677889900" 450 CSeq: 1 REGISTER 451 Content-Length: 0 453 (4) SIP/2.0 401 Unauthorized 454 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 455 From: 456 To: 457 Call-ID: 458 WWW-Authenticate: Digest realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5 459 Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 460 Security-Server: sdes-srtp; mediasec ***new*** 461 CSeq: 462 Content-Length: 464 (5) REGISTER sip:registrar.home1.net SIP/2.0 465 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 466 Max-Forwards: 70 467 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 468 From: ;tag=4fa3 469 To: 470 Contact: ;expires=600000 471 Call-ID: apb03a0s09dkjdfglkj49111 472 Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri="sip:registrar.home1.net", response="6629fae49393a05397450978507c4ef1" 473 Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 474 Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 475 Security-Client: sdes-srtp; mediasec ***new*** 476 Security-Verify: sdes-srtp; mediasec ***new*** 477 Require: sec-agree 478 Proxy-Require: sec-agree 479 CSeq: 2 REGISTER 480 Supported: path 481 Content-Length: 0 483 (6) REGISTER sip:registrar.home1.net SIP/2.0 484 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 485 Max-Forwards: 69 486 P-Access-Network-Info: 487 Path: 488 Require: 489 P-Visited-Network-ID: 490 P-Charging-Vector: 491 From: 492 To: 493 Contact: 494 Call-ID: 495 Authorization: 496 CSeq: 497 Supported: 498 Content-Length: 500 (7) SIP/2.0 200 OK 501 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 502 Path: 503 From: 504 To: 505 Call-ID: 506 Contact: ;expires=600000 507 CSeq: 508 Date: Wed, 11 July 2001 08:49:37 GMT 509 P-Associated-URI: , , 510 Content-Length: 512 (8) SIP/2.0 200 OK 513 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 514 Path: 515 From: 516 To: 517 Call-ID: 518 Contact: 519 CSeq: 520 Date: 521 P-Associated-URI: 522 Content-Length: 524 Figure 3: Use of mediasec parameter 526 6.2. Re-Registration 3GPP 528 Media plane security mechanisms are also exchanged when a 529 registration is refreshed or a new public identity is registered. 531 UAC Proxy Registrar 532 user1_public1@home1.net pcscf1.home1.net registrar.home1.net 533 | | | 534 | | | 535 |--------(1) REGISTER---->| | 536 | Security-Client: sdes-srtp; mediasec 537 | Security-Verify: sdes-srtp; mediasec 538 | | | 539 | |---(2) REGISTER--->| 540 | | | 541 | |<----(3) 200 OK----| 542 | | | 543 |<------(4) 200 OK------- | | 544 | | | 545 | | | 547 Figure 4: Exchange of Media Security Mechanisms at Re-Registration 549 The UAC sends a REGISTER request (1) and includes the security 550 mechanisms for the media plane and that it supports in a Security- 551 Client: header field. The UAC also echos the list of security 552 mechanisms it received from the outbound proxy in the Security- 553 Server: header field. Media security mechanisms are distinguished by 554 the "mediasec" header field parameter. 556 The REGISTER request is forwarded to the registrar (2) and the 557 registrar responds with 200 OK (3), which is forwarded to the UAC 558 (4). 560 (1) REGISTER sip:registrar.home1.net SIP/2.0 561 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 562 Max-Forwards: 70 563 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 564 From: ;tag=4fa3 565 To: 566 Contact: ;expires=600000 567 Call-ID: apb03a0s09dkjdfglkj49111 568 Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri="sip:registrar.home1.net", response="6629fae49393a05397450978507c4ef1", integrity-protected="yes" 569 Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 570 Security-Client: sdes-srtp; mediasec ***new*** 571 Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 572 Security-Verify: sdes-srtp; mediasec ***new*** 573 Require: sec-agree 574 Proxy-Require: sec-agree 575 CSeq: 3 REGISTER 576 Supported: path 577 Content-Length: 0 579 (2) REGISTER sip:registrar.home1.net SIP/2.0 580 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 581 P-Access-Network-Info: 582 Max-Forwards: 69 583 Path: 584 Require: 585 P-Visited-Network-ID: 586 P-Charging-Vector: 587 From: 588 To: 589 Contact: 590 Call-ID: 591 Authorization: 592 CSeq: 593 Supported: 594 Content-Length: 596 (3) SIP/2.0 200 OK 597 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 598 Path: 599 From: 600 To: 601 Call-ID: 602 Contact: ;expires=600000 603 CSeq: 604 Date: Wed, 11 July 2001 08:49:37 GMT 605 P-Associated-URI: , , 606 Content-Length: 608 (4) SIP/2.0 200 OK 609 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 610 Path: 611 From: 613 To: 614 Call-ID: 615 Contact: 616 CSeq: 617 Date: 618 P-Associated-URI: 619 Content-Length: 621 Figure 5: Use of mediasec parameter 623 6.3. Client Initiated as per RFC 3329 625 Media plane security mechanisms are also exchanged at client 626 initiated security negotiation described in RFC 3329 [4]. 628 UAC Proxy UAS 629 | | | 630 |----(1) OPTIONS----->| | 631 | | | 632 |<-----(2) 494--------| | 633 | | | 634 |<=======TLS=========>| | 635 | | | 636 |----(3) INVITE------>| | 637 | |----(4) INVITE--->| 638 | | | 639 | |<---(5) 200 OK----| 640 |<----(6) 200 OK------| | 641 | | | 642 |------(7) ACK------->| | 643 | |-----(8) ACK----->| 644 | | | 645 | | | 646 | | | 647 | | | 648 |<-(Protected media)->|<---(Media)------>| 649 | | | 651 Figure 6: Negotiation Initiated by the Client. 653 After exchange of security capabilities, the UAC sends an INVITE 654 request(3) including an SDP description of the media plane security 655 to be used (a="e2ae" and a crypto attribute). This INVITE contains a 656 copy of the server's security list in a Security-Verify header field. 658 The server verifies it, and since it matches its static list, it 659 processes the INVITE and forwards it to the next hop. 661 (1) OPTIONS sip:proxy.example.com SIP/2.0 662 Security-Client: tls 663 Security-Client: digest 664 Security-Client: sdes-srtp; mediasec 665 Require: sec-agree 666 Proxy-Require: sec-agree 668 (2) SIP/2.0 494 Security Agreement Required 669 Security-Server: ipsec-ike;q=0.1 670 Security-Server: tls;q=0.2 671 Security-Server: sdes-srtp; mediasec 673 (3) INVITE sip:proxy.example.com SIP/2.0 674 Security-Verify: ipsec-ike;q=0.1 675 Security-Verify: tls;q=0.2 676 Security-Verify: sdes-srtp; mediasec 677 Route: sip:callee@domain.com 678 Require: sec-agree 679 Proxy-Require: sec-agree 681 6.4. Server Initiated as per RFC 3329 683 Media plane security mechanisms are also exchanged at server 684 initiated security negotiation described in RFC 3329 [4]. 686 UAC Proxy UAS 687 | | | 688 |-----(1) INVITE---->| | 689 | | | 690 |<-----(2) 421-------| | 691 | | | 692 |------(3) ACK------>| | 693 | | | 694 |<=======IKE========>| | 695 | | | 696 |-----(4) INVITE---->| | 697 | |----(5) INVITE--->| 698 | | | 699 | |<---(6) 200 OK----| 700 |<----(7) 200 OK-----| | 701 | | | 702 |------(8) ACK------>| | 703 | |-----(9) ACK----->| 704 | | | 705 | | | 707 Figure 7: Negotiation Initiated by the Server. 709 Media security mechanisms are included in Security-Server: and 710 Security-Client: header fields in the same way as signalling security 711 mechanisms. 713 (1) INVITE sip:uas.example.com SIP/2.0 715 (2) SIP/2.0 421 Extension Required 716 Security-Server: ipsec-ike;q=0.1 717 Security-Server: tls;q=0.2 718 Security-Server: mechanism; mediasec 720 (4) INVITE sip:uas.example.com SIP/2.0 721 Security-Verify: ipsec-ike;q=0.1 722 Security-Verify: tls;q=0.2 723 Security-Verify: mechanism; mediasec 725 Figure 8: Negotiation Initiated by the Server. 727 6.5. Using Media Plane Security 729 To request end to access edge media security either on a session or 730 media level the UE sends, for example, an SDP Offer for an SRTP 731 stream containing one or more SDES crypto attributes, each with a key 732 and other security context parameters required according to RFC 4568 733 [8], together with the attribute "a=3ge2ae". 735 (3) INVITE sip:bob@ua2.example.com SIP/2.0 736 Security-Verify: ipsec-ike;q=0.1 737 Security-Verify: tls;q=0.2 738 Security-Verify: sdes-srtp;mediasec 739 Route: proxy.example.com 740 Require: sec-agree, mediasec 741 Proxy-Require: sec-agree, mediasec 743 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK74bf9 744 Max-Forwards: 70 745 From: Alice ;tag=9fxced76sl 746 To: Bob 748 Call-ID: 3848276298220188511@ua1.example.com 749 CSeq: 1 INVITE 750 Contact: 751 Content-Type: application/sdp 752 Content-Length: 285 754 v=0 755 o=alice 2890844526 2890844526 IN IP4 ua1.example.com 756 s=- 757 c=IN IP4 192.0.2.101 758 t=0 0 759 m=audio 49172 RTP/SAVP 0 760 a=3ge2ae 761 a=crypto:1 AES_CM_128_HMAC_SHA1_80 762 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 763 FEC_ORDER=FEC_SRTP 764 a=rtpmap:0 PCMU/8000 766 (4) INVITE sip:bob@ua2.example.com SIP/2.0 767 Route: sip:proxy.example.com 769 (5) SIP/2.0 200 OK 771 (6) SIP/2.0 200 OK 772 Security-Server: tls;q=0.2 773 Security-Server: sdes-srtp;mediasec 774 a=3ge2ae 775 a=crypto:1 AES_CM_128_HMAC_SHA1_80 776 a=crypto:1 AES_CM_128_HMAC_SHA1_80 777 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 779 Figure 9: Using media security 781 7. Formal Syntax 783 The following syntax specification uses the augmented Backus-Naur 784 Form (BNF) as described in RFC 5234 [RFC5234]. 786 "mediasec" is a "header field parameter", as defined by [RFC3968]. 788 Header Field Name in which the parameter can appear. 790 Security-Client 792 Security-Server 794 Security-Verify 796 Header Fields Parameter Name Values Reference 797 --------------- ---------------- -------- --------- 798 Security-Client mediasec No [this document] 799 Security-Server mediasec No [this document] 800 Security-Verify mediasec No [this document] 802 Name of the Header Field Parameter being registered. 804 "mediasec" 806 8. Acknowledgements 808 Remember, it's important to acknowledge people who have contributed 809 to the work. 811 This template was extended from an initial version written by Pekka 812 Savola and contributed by him to the xml2rfc project. 814 9. IANA Considerations 816 This specification creates a new registry for media plane security 817 mechanisms. 819 9.1. Registry for Media Plane Security Mechanisms 821 The IANA has created a subregistry for media plane security mechanism 822 token values to be used with the 'mediasec' header field parameter 823 under the Session Initiation Protocol (SIP) Parameters registry. 825 Security Mechanism Name for Media Reference 826 --------------------------------- --------- 828 As per the terminology in [RFC5226], the registration policy for new 829 media plane security mechanism token values shall be 'Specification 830 Required'. 832 9.2. Registration Template 834 To: ietf-sip-sec-agree-mechanism-name@iana.org Subject: Registration 835 of a new SIP Security Agreement mechanism 837 Mechanism Name: 839 (Token value conforming to the syntax described in Section 4.3.) 841 Published Specification(s): 843 (Descriptions of new SIP media plane security agreement mechanisms 844 require a published specification.) 846 9.3. Header Field Names 848 This specification registers no new header fields. 850 9.4. Response Codes 852 This specification registers no new response codes. 854 10. Security Considerations 856 This specification is an extension of RFC 3329 [4] and as such shares 857 the same security considerations. 859 A further consideration of this specification is protection of the 860 cryptographic key to be used for SRTP and carried in SDP. In order 861 to protect this key, one of the security mechanisms defined in RFC 862 3329 [4] SHOULD be used in parallel with this specification. 864 11. References 866 11.1. Normative References 868 [1] authSurName, authInitials., "example1", year. 870 [2] authSurName, authInitials., "example2", year. 872 [3] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997, 874 . 876 [4] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 877 Haukka, "Security Mechanism Agreement for the Session 878 Initiation Protocol (SIP)", RFC 3329, January 2003. 880 [5] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 881 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 882 RFC 2661, August 1999. 884 [6] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 885 June 1999. 887 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 888 A., Peterson, J., Sparks, R., Handley, M., and E. 889 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 890 June 2002. 892 [8] Andreasen, F., Baugher, M., and D. Wing, "Session 893 Description Protocol (SDP) Security Descriptions for Media 894 Streams", RFC 4568, July 2006. 896 [9] Harkins, D. and D. Carrel, "The Internet Key Exchange 897 (IKE)", RFC 2409, November 1998. 899 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an 900 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 901 May 2008. 903 [11] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 904 for Establishing a Secure Real-time Transport Protocol 905 (SRTP) Security Context Using Datagram Transport Layer 906 Security (DTLS)", RFC 5763, May 2010. 908 [12] Andreasen, F., "Session Description Protocol (SDP) 909 Capability Negotiation", RFC 5939, September 2010. 911 11.2. Informative References 913 [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 914 Specifications: ABNF", RFC 4234, October 2005. 916 [14] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 917 Specifications: ABNF", RFC 2234, November 1997. 919 Appendix A. Additional stuff 921 You can add appendices just as regular sections, the only difference 922 is that they go within the "back" element, and not within the 923 "middle" element. And they follow the "reference" elements. 925 Author's Address 926 Peter Dawes 927 Vodafone Group Services Ltd. 928 Newbury 929 UK 931 Email: peter.dawes@vodafone.com 933 CallSend SMSAdd to SkypeYou'll need Skype Credit 934 Free via Skype