idnits 2.17.1 draft-dawes-sipcore-mediasec-parameter-05.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 32 instances of too long lines in the document, the longest one being 197 characters in excess of 72. ** The abstract seems to contain references ([2]), 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 337 has weird spacing: '...me1.net pcscf...' == Line 541 has weird spacing: '...me1.net pcsc...' == Line 807 has weird spacing: '...-Client media...' == Line 808 has weird spacing: '...-Server media...' == Line 809 has weird spacing: '...-Verify media...' -- The document date (November 16, 2016) is 2715 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC5234' on line 793 -- Looks like a reference, but probably isn't: 'RFC3968' on line 795 -- Looks like a reference, but probably isn't: 'RFC5226' on line 837 == Unused Reference: '6' is defined on line 905, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 November 16, 2016 5 Expires: May 20, 2017 7 Security Mechanism Names for Media 8 draft-dawes-sipcore-mediasec-parameter-05.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 [2]. This document adds the capability to distinguish security 15 mechanisms that apply to the media plane by defining a new Session 16 Initiation Protocol (SIP) header field parameter to label such 17 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 [1]. 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 May 20, 2017. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Access Network Protection . . . . . . . . . . . . . . . . . . 4 62 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Signaling security negotiation . . . . . . . . . . . . . 4 64 4.2. Header fields for signaling security negotiation . . . . 5 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 . . . . . . . . . . . . . . 7 70 4.6. Duration of Security Assocations . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 16 78 6.5. Using Media Plane Security . . . . . . . . . . . . . . . 18 79 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 9.1. Registry for Media Plane Security Mechanisms . . . . . . 20 83 9.2. Registration Template . . . . . . . . . . . . . . . . . . 21 84 9.3. Header Field Names . . . . . . . . . . . . . . . . . . . 21 85 9.4. Response Codes . . . . . . . . . . . . . . . . . . . . . 21 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 11.2. Informative References . . . . . . . . . . . . . . . . . 22 90 Appendix A. Additional stuff . . . . . . . . . . . . . . . . . . 22 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Problem Statement 95 In the 3GPP defined architecture and SIP profile for packet-domain 96 communication, SIP signaling 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 signaling 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 [2]. 101 Because the 3GPP architecture also allows access technologies that do 102 not protect media, e.g. WiFi, this document extends the negotiation 103 of security mechanism to the media plane. During previous discussion 104 of the topic of media plane security it was suggested that DTLS-SRTP 105 should be used, but 3GPP considered this impractical to implement in 106 the 3GPP-defined architecture and also limited in terms of meeting 107 all 3GPP requirements which include protection of non-RTP media such 108 as MSRP. 110 The purpose of this specification is to define a new header field 111 parameter for the Session Initiation Protocol (SIP) 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 [2]. 117 The header field parameter introduced by this draft originates from 118 3GPP specifications and related procedures and header field values 119 are also described in 3GPP specifications, primarily in 3GPP TS 120 33.328 [2]. The purpose of this draft is to name the header field 121 parameter, give several illustrative examples to make it clear how it 122 is used, and set up an IANA registry for existing and future values. 123 The draft does not propose that IETF defines any new security setup 124 procedures, ciphering, integrity protection etc. 126 2. Introduction 128 [2] describes negotiation of a security mechanism for SIP signaling 129 between a UAC and its first hop proxy and allows a client or network 130 to ensure that protection of SIP signaling is turned on when the 131 client registers with the network. SIP signaling is then protected 132 as it traverses the access network. To enable similar protection for 133 media, this document enables client and network to exchange their 134 security capabilities for the media plane combined with the 135 negotiation described in [2]. Similar to the signaling plane, the 136 evolution of security mechanisms for media often introduces new 137 algorithms, or uncovers problems in existing ones, making capability 138 exchange of such mechanisms a necessity. 140 3. Access Network Protection 142 Some access technologies, such as many cellular wireless accesses, 143 protect the data passed over them by default but some, such as WLAN, 144 do not. For accesses with no inherent protection, it is useful for 145 the media controlled by SIP signaling to be protected by default 146 because of vulnerability to eavesdropping. It is currently possible 147 for a UA to request protection of the media plane end-to-end by 148 including the crypto attribute in SDP at session setup. This does 149 not guarantee protection however, because it relies on support of 150 encryption by the called UA, or by another entity in the path taken 151 by the media. In some cases, the session will originate in an access 152 that protects the media and terminate in one that does not, meaning 153 that media is protected in all but some hops of its path. In cases 154 where the same provider supplies the user equipment and provides the 155 IP access, the IP access technology that the UA will use is 156 predictable and the media is vulnerable only as far as the core 157 network. In such cases, the user equipment it is possible to protect 158 the media plane by encrypting at the UA and decrypting at the edge of 159 the core network, and for the user agent that originates or 160 terminates the session to expect the edge of the core network to be 161 capable of encrypting and decrypting media. The header field 162 parameter described in this document enables this case of first-hop 163 protection, which is typically provided by default to a user agent. 165 4. Solution 167 4.1. Signaling security negotiation 169 A specification already exists for setting up security for SIP 170 signaling between a client and its first-hop proxy, as defined in [2] 171 which gives an overview of the mechanism as follows: 173 1. Client ----------client list---------> Server 174 2. Client <---------server list---------- Server 175 3. Client ------(turn on security)------- Server 176 4. Client ----------server list---------> Server 177 5. Client <---------ok or error---------- Server 179 Figure 1: Security agreement message flow from RFC 3329 181 The security mechanism above ensures that SIP signaling is protected 182 between a client and its first hop entity but the media plane is 183 still unprotected. This document proposes that client and server 184 additionally exchange their media plane security capabilities at 185 steps 1 and 2. Media plane security needs to be applied on a per- 186 media basis at the time that media is initiated. Therefore the 187 client and server need not turn on media plane security immediately. 189 This document defines the "mediasec" header field parameter that 190 labels any of the Security-Client:, Security-Server:, or Security- 191 Verify: header fields as applicable to the media plane and not the 192 signaling plane. 194 4.2. Header fields for signaling security negotiation 196 The "mediasec" header field parameter defined in this document is 197 used with procedures defined in [2] to distinguish media plane 198 security, with the difference that media plane security need not be 199 started immediately and can be applied and removed on-the-fly as 200 media are added and removed within a session. The SIP responses that 201 can contain the Security-Client, Security-Server, and Security-Verfiy 202 header fields are SIP responses 421 (Extension Required) and 494 203 (Security Agreement Required) as defined in [2]. 205 4.3. Syntax 207 This document does not define any new SIP header fields, it defines a 208 header field parameter for header fields Security-Client, Security- 209 Server and Security-Verify defined in [2]. 211 4.4. Protocol Operation 213 4.4.1. The "mediasec" Header Field Parameter 215 The "mediasec" header field parameter may be used in the Security- 216 Client, Security-Server, or Security-Verfiy header fields defined in 217 [2] to indicate that a header field applies to the media plane. Any 218 one of the media plane security mechanisms supported by both client 219 and server, if any, may be applied when a media stream is started. 220 Or a media stream may be set up without security. 222 Values in the Security-Client, Security-Server, or Security-Verfiy 223 header fields labelled with the "mediasec" header field parameter are 224 specfic to the media plane and specific to the secure media transport 225 protocol used on the media plane. 227 4.4.2. Client Initiated 229 A client wishing to use the security capability exchange of this 230 specification MUST add a Security-Client header field to a request 231 addressed to its first-hop proxy (i.e., the destination of the 232 request is the first-hop proxy). This header field contains a list 233 of all the media plane security mechanisms that the client supports. 235 The client SHOULD NOT add preference parameters to this list. The 236 client MUST add a "mediasec" header field parameter to the Security- 237 Client header field. 239 The contents of the Security-Client header field may be used by the 240 server to include any necessary information in its response. 242 As described in [2], the response will be 494 if the client includes 243 "sec-agree" in the Require and Proxy-Require header fields, or a 2xx 244 response if the Require and Proxy-Require header fields do not 245 contain "sec-agree". The server MUST add its list to the response 246 even if there are no common security mechanisms in the client's and 247 server's lists. The server's list MUST NOT depend on the contents of 248 the client's list. 250 Any subsequent SIP requests sent by the client to that server MAY 251 make use of the media security capabilities exchanged in the previous 252 step by including media plane security parameters in SDP in the 253 session or the media description. These requests MUST contain a 254 Security-Verify header field that mirrors the server's list received 255 previously in the Security-Server header field. 257 The server MUST check that the security mechanisms listed in the 258 Security-Verify header field of incoming requests correspond to its 259 static list of supported security mechanisms. 261 Note that, following the standard SIP header field comparison rules 262 defined in [3], both lists have to contain the same security 263 mechanisms in the same order to be considered equivalent. In 264 addition, for each particular security mechanism, its parameters in 265 both lists need to have the same values. 267 The server can proceed processing a particular request if, and only 268 if, the list was not modified. If modification of the list is 269 detected, the server MUST respond to the client with a 494 (Security 270 Agreement Required) response. This response MUST include the 271 server's unmodified list of supported security mechanisms. 273 Once security capabilities have been exchanged between two SIP 274 entities, the same SIP entities MAY use the same security when 275 communicating with each other in different SIP roles. For example, 276 if a UAC and its outbound proxy exchange some media-plane security 277 mechanisms, they may try to use the same security for incoming 278 requests (i.e., the UA will be acting as a UAS). 280 The user of a UA SHOULD be informed about the results of the security 281 mechanism agreement. The user MAY decline to accept a particular 282 security mechanism, and abort further SIP communications with the 283 peer. 285 4.5. Security Mechanism Initiation 287 Once the client chooses a security mechanism from the list received 288 in the Security-Server header field from the server, it MAY initiate 289 that mechanism on a session level, or on a media level when it 290 initiates new media in an existing session. 292 4.6. Duration of Security Assocations 294 Once media-plane security capabilities have been exchanged, both the 295 server and the client need to know until when they can be used. The 296 media plane security mechanism setup is valid for as long as the UA 297 has a SIP signaling relationship with its first-hop proxy or until 298 new keys are exchanged in SDP. The SDP used to set up media plane 299 security will be protected by a security association used to protect 300 SIP signaling and the media plane security mechanism can be used 301 until the signaling plane security association expires. 303 4.7. Summary of Header Field Use 305 The header fields defined in this document may be used to exchange 306 supported media plane security mechanisms between a UAC and other SIP 307 entities including UAS, proxy, and registrar. Information about the 308 use of headers in relation to SIP methods and proxy processing is 309 given in [2] Table 1. 311 5. Backwards Compatibility 313 Security mechanisms that apply to the media plane only MUST NOT have 314 the same name as any signaling plane mechanism. If a signaling plane 315 security mechanism name is re-used for the media plane and 316 distinguished only by the "mediasec" parameter, then implementations 317 that do not recognize the "mediasec" parameter may incorrectly use 318 that security mechanism for the signaling plane. 320 6. Examples 322 The following examples illustrate the use of the mediasec header 323 field parameter defined above. 325 6.1. Initial Registration 3GPP 327 At initial registration, the client includes its supported media 328 plane security mechanisms in the SIP REGISTER request. The first-hop 329 proxy returns its supported media plane security mechanisms in the 330 SIP 401 (Unauthorized) response. 332 As per [2], a UA negotiates the security mechanism for the media 333 plane to be used with its outbound proxy without knowing beforehand 334 which mechanisms the proxy supports, as shown in Figure 2 below. 336 UAC Proxy Registrar 337 user1_public1@home1.net pcscf1.home1.net registrar.home1.net 338 | | | 339 |------(1) REGISTER---->| | 340 | Security-Client: sdes-srtp; mediasec 341 | | | 342 | |---(2) REGISTER--->| 343 | | | 344 | |<----(3) 401-------| 345 | | | 346 |<-----(4) 401----------| | 347 | Security-Server: sdes-srtp; mediasec 348 | | | 349 |-----(5) REGISTER----->| | 350 | Security-Client: sdes-srtp; mediasec 351 | Security-Verify: sdes-srtp; mediasec 352 | | | 353 | |---(6) REGISTER--->| 354 | | | 355 | |<----(7) 200 OK----| 356 | | | 357 |<-----(8) 200 OK------ | | 358 | | | 359 |------(9) INVITE------>| | 360 | Security-Verify: sdes-srtp; mediasec 361 | | | 362 | Content-Type: application/sdp | 363 | a=3ge2ae | | 364 | a=crypto:1 AES_CM_128_HMAC_SHA1_80 365 | inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 366 | FEC_ORDER=FEC_SRTP | 367 | | | 369 Figure 2: Exchange of Media Security Mechanisms at Initial 370 Registration 372 The UAC sends a REGISTER request (1) to its outbound proxy indicating 373 the security mechanisms for the media plane and that it supports in a 374 Security-Client: header field. Indication of media security 375 mechanisms is identified by the "mediasec" header field parameter. 377 The outbound proxy forwards the REGISTER request (2) to the registrar 378 with the Security-Client: header field removed as described in [2]. 380 The registrar responds with a 401 (Unauthorized) response (3) to the 381 REGISTER request. 383 The outbound proxy responds forwards the 401 (Unauthorized) response 384 (4) to the UAC with its own list of security mechanisms for the media 385 plane in the Security-Server: header field. Security mechanisms for 386 the media plane are distinguished by the "mediasec" header field 387 parameter. 389 The UAC sends a second REGISTER request (5) using the security 390 credentials it received in the 401 (Unauthorized) response. The UAC 391 includes the security mechanisms for the media plane and that it 392 supports in a Security-Client: header field. The UAC also echos the 393 list of security mechanisms it received from the outbound proxy in 394 the Security-Server: header field. Media security mechanisms are 395 distinguished by the "mediasec" header field parameter. 397 The REGISTER request is forwarded to the registrar (6) and the 398 registrar responds with 200 OK (7), which is forwarded to the UAC 399 (8). 401 When the connection is successfully established, the UAC sends an 402 INVITE request(9) including an SDP description of the media plane 403 security to be used (a="e2ae" and a crypto attribute). This INVITE 404 contains a copy of the server's security list in a Security-Verify 405 header field. The server verifies it, and since it matches its 406 static list, it processes the INVITE and forwards it to the next hop. 408 If this example was run without the Security-Server header field in 409 Step (2), the UAC would not know what kind of security the other one 410 supports, and would be forced to make error-prone trials. 412 More seriously, if the Security-Verify header field was omitted in 413 Step (3), the whole process would be prone to MitM attacks. An 414 attacker could remove the media plane security description from the 415 header in Step (1), therefore preventing protection of the media 416 plane. 418 (1) REGISTER sip:registrar.home1.net SIP/2.0 419 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 420 Max-Forwards: 70 421 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 422 From: ;tag=4fa3 423 To: 424 Contact: ;expires=600000 425 Call-ID: apb03a0s09dkjdfglkj49111 426 Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:registrar.home1.net", response="" 427 Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 428 Security-Client: sdes-srtp; mediasec ***new*** 429 Require: sec-agree 430 Proxy-Require: sec-agree 431 CSeq: 1 REGISTER 432 Supported: path 433 Content-Length: 0 435 (2) REGISTER sip:registrar.home1.net SIP/2.0 436 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 437 Max-Forwards: 69 438 P-Access-Network-Info: 439 Path: 440 Require: 441 P-Visited-Network-ID: 442 P-Charging-Vector: 443 From: 444 To: 445 Contact: 446 Call-ID: 447 Authorization: 448 CSeq: 449 Supported: 450 Content-Length: 452 (3) SIP/2.0 401 Unauthorized 453 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 454 From: ;tag=4fa3 455 To: ; tag=5ef4 456 Call-ID: apb03a0s09dkjdfglkj49111 457 WWW-Authenticate: Digest realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, ik="00112233445566778899aabbccddeeff", ck="ffeeddccbbaa11223344556677889900" 458 CSeq: 1 REGISTER 459 Content-Length: 0 461 (4) SIP/2.0 401 Unauthorized 462 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 463 From: 464 To: 465 Call-ID: 466 WWW-Authenticate: Digest realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5 467 Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 468 Security-Server: sdes-srtp; mediasec ***new*** 469 CSeq: 470 Content-Length: 472 (5) REGISTER sip:registrar.home1.net SIP/2.0 473 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 474 Max-Forwards: 70 475 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 476 From: ;tag=4fa3 477 To: 478 Contact: ;expires=600000 479 Call-ID: apb03a0s09dkjdfglkj49111 480 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" 481 Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 482 Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 483 Security-Client: sdes-srtp; mediasec ***new*** 484 Security-Verify: sdes-srtp; mediasec ***new*** 485 Require: sec-agree 486 Proxy-Require: sec-agree 487 CSeq: 2 REGISTER 488 Supported: path 489 Content-Length: 0 491 (6) REGISTER sip:registrar.home1.net SIP/2.0 492 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 493 Max-Forwards: 69 494 P-Access-Network-Info: 495 Path: 496 Require: 497 P-Visited-Network-ID: 498 P-Charging-Vector: 499 From: 500 To: 501 Contact: 502 Call-ID: 503 Authorization: 504 CSeq: 505 Supported: 506 Content-Length: 508 (7) SIP/2.0 200 OK 509 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 510 Path: 511 From: 512 To: 513 Call-ID: 514 Contact: ;expires=600000 515 CSeq: 517 Date: Wed, 11 July 2001 08:49:37 GMT 518 P-Associated-URI: , , 519 Content-Length: 521 (8) SIP/2.0 200 OK 522 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 523 Path: 524 From: 525 To: 526 Call-ID: 527 Contact: 528 CSeq: 529 Date: 530 P-Associated-URI: 531 Content-Length: 533 Figure 3: Use of mediasec parameter 535 6.2. Re-Registration 3GPP 537 Media plane security mechanisms are also exchanged when a 538 registration is refreshed or a new public identity is registered. 540 UAC Proxy Registrar 541 user1_public1@home1.net pcscf1.home1.net registrar.home1.net 542 | | | 543 | | | 544 |--------(1) REGISTER---->| | 545 | Security-Client: sdes-srtp; mediasec 546 | Security-Verify: sdes-srtp; mediasec 547 | | | 548 | |---(2) REGISTER--->| 549 | | | 550 | |<----(3) 200 OK----| 551 | | | 552 |<------(4) 200 OK------- | | 553 | | | 554 | | | 556 Figure 4: Exchange of Media Security Mechanisms at Re-Registration 558 The UAC sends a REGISTER request (1) and includes the security 559 mechanisms for the media plane and that it supports in a Security- 560 Client: header field. The UAC also echos the list of security 561 mechanisms it received from the outbound proxy in the Security- 562 Server: header field. Media security mechanisms are distinguished by 563 the "mediasec" header field parameter. In the example below, the 564 Security-Verify: header field is included as required by [5] clause 565 5.1.1.4.2 when setting up ipsec-3gpp signaling plane security. 567 The REGISTER request is forwarded to the registrar (2) and the 568 registrar responds with 200 OK (3), which is forwarded to the UAC 569 (4). 571 (1) REGISTER sip:registrar.home1.net SIP/2.0 572 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 573 Max-Forwards: 70 574 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 575 From: ;tag=4fa3 576 To: 577 Contact: ;expires=600000 578 Call-ID: apb03a0s09dkjdfglkj49111 579 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" 580 Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 581 Security-Client: sdes-srtp; mediasec ***new*** 582 Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 583 Security-Verify: sdes-srtp; mediasec ***new*** 584 Require: sec-agree 585 Proxy-Require: sec-agree 586 CSeq: 3 REGISTER 587 Supported: path 588 Content-Length: 0 590 (2) REGISTER sip:registrar.home1.net SIP/2.0 591 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 592 P-Access-Network-Info: 593 Max-Forwards: 69 594 Path: 595 Require: 596 P-Visited-Network-ID: 597 P-Charging-Vector: 598 From: 599 To: 600 Contact: 601 Call-ID: 602 Authorization: 603 CSeq: 604 Supported: 605 Content-Length: 607 (3) SIP/2.0 200 OK 608 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 609 Path: 610 From: 611 To: 612 Call-ID: 613 Contact: ;expires=600000 614 CSeq: 615 Date: Wed, 11 July 2001 08:49:37 GMT 616 P-Associated-URI: , , 617 Content-Length: 619 (4) SIP/2.0 200 OK 620 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 621 Path: 622 From: 623 To: 624 Call-ID: 625 Contact: 626 CSeq: 627 Date: 628 P-Associated-URI: 629 Content-Length: 631 Figure 5: Use of mediasec parameter 633 6.3. Client Initiated as per RFC 3329 635 Media plane security mechanisms are also exchanged at client 636 initiated security negotiation described in [2]. 638 UAC Proxy UAS 639 | | | 640 |----(1) OPTIONS----->| | 641 | | | 642 |<-----(2) 494--------| | 643 | | | 644 |<=======TLS=========>| | 645 | | | 646 |----(3) INVITE------>| | 647 | |----(4) INVITE--->| 648 | | | 649 | |<---(5) 200 OK----| 650 |<----(6) 200 OK------| | 651 | | | 652 |------(7) ACK------->| | 653 | |-----(8) ACK----->| 654 | | | 655 | | | 656 | | | 657 | | | 658 |<-(Protected media)->|<---(Media)------>| 659 | | | 661 Figure 6: Negotiation Initiated by the Client. 663 After exchange of security capabilities, the UAC sends an INVITE 664 request(3) including an SDP description of the media plane security 665 to be used (a="e2ae" and a crypto attribute). This INVITE contains a 666 copy of the server's security list in a Security-Verify header field. 667 The server verifies it, and since it matches its static list, it 668 processes the INVITE and forwards it to the next hop. 670 (1) OPTIONS sip:proxy.example.com SIP/2.0 671 Security-Client: tls 672 Security-Client: digest 673 Security-Client: sdes-srtp; mediasec 674 Require: sec-agree 675 Proxy-Require: sec-agree 677 (2) SIP/2.0 494 Security Agreement Required 678 Security-Server: ipsec-ike;q=0.1 679 Security-Server: tls;q=0.2 680 Security-Server: sdes-srtp; mediasec 682 (3) INVITE sip:proxy.example.com SIP/2.0 683 Security-Verify: ipsec-ike;q=0.1 684 Security-Verify: tls;q=0.2 685 Security-Verify: sdes-srtp; mediasec 686 Route: sip:callee@domain.com 687 Require: sec-agree 688 Proxy-Require: sec-agree 690 6.4. Server Initiated as per RFC 3329 692 Media plane security mechanisms are also exchanged at server 693 initiated security negotiation described in [2]. 695 UAC Proxy UAS 696 | | | 697 |-----(1) INVITE---->| | 698 | | | 699 |<-----(2) 421-------| | 700 | | | 701 |------(3) ACK------>| | 702 | | | 703 |<=======IKE========>| | 704 | | | 705 |-----(4) INVITE---->| | 706 | |----(5) INVITE--->| 707 | | | 708 | |<---(6) 200 OK----| 709 |<----(7) 200 OK-----| | 710 | | | 711 |------(8) ACK------>| | 712 | |-----(9) ACK----->| 713 | | | 714 | | | 716 Figure 7: Negotiation Initiated by the Server. 718 Media security mechanisms are included in Security-Server: and 719 Security-Client: header fields in the same way as signaling security 720 mechanisms. 722 (1) INVITE sip:uas.example.com SIP/2.0 724 (2) SIP/2.0 421 Extension Required 725 Security-Server: ipsec-ike;q=0.1 726 Security-Server: tls;q=0.2 727 Security-Server: mechanism; mediasec 729 (4) INVITE sip:uas.example.com SIP/2.0 730 Security-Verify: ipsec-ike;q=0.1 731 Security-Verify: tls;q=0.2 732 Security-Verify: mechanism; mediasec 734 Figure 8: Negotiation Initiated by the Server. 736 6.5. Using Media Plane Security 738 To request end to access edge media security either on a session or 739 media level the UE sends, for example, an SDP Offer for an SRTP 740 stream containing one or more SDES crypto attributes, each with a key 741 and other security context parameters required according to [4], 742 together with the attribute "a=3ge2ae". 744 (3) INVITE sip:bob@ua2.example.com SIP/2.0 745 Security-Verify: ipsec-ike;q=0.1 746 Security-Verify: tls;q=0.2 747 Security-Verify: sdes-srtp;mediasec 748 Route: proxy.example.com 749 Require: sec-agree 750 Proxy-Require: sec-agree 752 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK74bf9 753 Max-Forwards: 70 754 From: Alice ;tag=9fxced76sl 755 To: Bob 757 Call-ID: 3848276298220188511@ua1.example.com 758 CSeq: 1 INVITE 759 Contact: 760 Content-Type: application/sdp 761 Content-Length: 285 763 v=0 764 o=alice 2890844526 2890844526 IN IP4 ua1.example.com 765 s=- 766 c=IN IP4 192.0.2.101 767 t=0 0 768 m=audio 49172 RTP/SAVP 0 769 a=3ge2ae 770 a=crypto:1 AES_CM_128_HMAC_SHA1_80 771 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 772 FEC_ORDER=FEC_SRTP 773 a=rtpmap:0 PCMU/8000 775 (4) INVITE sip:bob@ua2.example.com SIP/2.0 776 Route: sip:proxy.example.com 778 (5) SIP/2.0 200 OK 780 (6) SIP/2.0 200 OK 781 Security-Server: tls;q=0.2 782 Security-Server: sdes-srtp;mediasec 783 a=3ge2ae 784 a=crypto:1 AES_CM_128_HMAC_SHA1_80 785 a=crypto:1 AES_CM_128_HMAC_SHA1_80 786 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 788 Figure 9: Using media security 790 7. Formal Syntax 792 The following syntax specification uses the augmented Backus-Naur 793 Form (BNF) as described in RFC 5234 [RFC5234]. 795 "mediasec" is a "header field parameter", as defined by [RFC3968]. 797 Header Field Name in which the parameter can appear. 799 Security-Client 801 Security-Server 803 Security-Verify 805 Header Fields Parameter Name Values Reference 806 --------------- ---------------- -------- --------- 807 Security-Client mediasec No [this document] 808 Security-Server mediasec No [this document] 809 Security-Verify mediasec No [this document] 811 Name of the Header Field Parameter being registered. 813 "mediasec" 815 8. Acknowledgements 817 Remember, it's important to acknowledge people who have contributed 818 to the work. 820 This template was extended from an initial version written by Pekka 821 Savola and contributed by him to the xml2rfc project. 823 9. IANA Considerations 825 This specification creates a new registry for media plane security 826 mechanisms. 828 9.1. Registry for Media Plane Security Mechanisms 830 The IANA has created a subregistry for media plane security mechanism 831 token values to be used with the 'mediasec' header field parameter 832 under the Session Initiation Protocol (SIP) Parameters registry. 834 Security Mechanism Name for Media Reference 835 --------------------------------- --------- 837 As per the terminology in [RFC5226], the registration policy for new 838 media plane security mechanism token values shall be 'Specification 839 Required'. 841 9.2. Registration Template 843 To: ietf-sip-sec-agree-mechanism-name@iana.org Subject: Registration 844 of a new SIP Security Agreement mechanism 846 Mechanism Name: 848 (Token value conforming to the syntax described in Section 4.3.) 850 Published Specification(s): 852 (Descriptions of new SIP media plane security agreement mechanisms 853 require a published specification.) 855 9.3. Header Field Names 857 This specification registers no new header fields. 859 9.4. Response Codes 861 This specification registers no new response codes. 863 10. Security Considerations 865 This specification is an extension of [2] and as such shares the same 866 security considerations. 868 A further consideration of this specification is protection of the 869 cryptographic key to be used for SRTP and carried in SDP. In order 870 to protect this key, one of the security mechanisms defined in [2] 871 SHOULD be used in parallel with this specification. 873 11. References 875 11.1. Normative References 877 [1] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997, 879 . 881 [2] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 882 Haukka, "Security Mechanism Agreement for the Session 883 Initiation Protocol (SIP)", RFC 3329, 884 DOI 10.17487/RFC3329, January 2003, 885 . 887 [3] 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 DOI 10.17487/RFC3261, June 2002, 891 . 893 [4] Andreasen, F., Baugher, M., and D. Wing, "Session 894 Description Protocol (SDP) Security Descriptions for Media 895 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 896 . 898 11.2. Informative References 900 [5] 3GPP, "IP multimedia call control protocol based on 901 Session Initiation Protocol (SIP) and Session Description 902 Protocol (SDP); Stage 3", 3GPP TS 24.229 10.13.0, 903 September 2013. 905 [6] 3GPP, "IP Multimedia Subsystem (IMS) media plane 906 security", 3GPP TS 33.328, September 2014. 908 Appendix A. Additional stuff 910 You can add appendices just as regular sections, the only difference 911 is that they go within the "back" element, and not within the 912 "middle" element. And they follow the "reference" elements. 914 Author's Address 916 Peter Dawes 917 Vodafone Group Services Ltd. 918 Newbury 919 UK 921 Email: peter.dawes@vodafone.com