Internet Engineering Task Force P. Dawes Internet-Draft Vodafone Group Intended status: Informational June 21, 2013 Expires: December 23, 2013 Security Mechanism Names for Media draft-dawes-dispatch-mediasec-parameter-06.txt Abstract Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in RFC 3329 [4]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 23, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Dawes Expires December 23, 2013 [Page 1] Internet-Draft Security Mechanism Names for Media June 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Access Network Protection . . . . . . . . . . . . . . 3 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Header Fields Defined in RFC3329 . . . . . . . . . . . . 4 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Protocol Operation . . . . . . . . . . . . . . . . . . . 4 2.3.1. The "mediasec" Header Field Parameter . . . . . . . . 4 2.3.2. Client Initiated . . . . . . . . . . . . . . . . . . 5 2.4. Security Mechanism Initiation . . . . . . . . . . . . . . 6 2.5. Duration of Security Assocations . . . . . . . . . . . . 6 2.6. Summary of Header Field Use . . . . . . . . . . . . . . . 6 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Initial Registration 3GPP . . . . . . . . . . . . . . . . 8 4.2. Re-Registration 3GPP . . . . . . . . . . . . . . . . . . 13 4.3. Client Initiated as per RFC 3329 . . . . . . . . . . . . 15 4.4. Server Initiated as per RFC 3329 . . . . . . . . . . . . 16 4.5. Using Media Plane Security . . . . . . . . . . . . . . . 17 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.1. Registry for Media Plane Security Mechanisms . . . . . . 19 7.2. Registration Template . . . . . . . . . . . . . . . . . . 20 7.3. Header Field Names . . . . . . . . . . . . . . . . . . . 20 7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Additional stuff . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Dawes Expires December 23, 2013 [Page 2] Internet-Draft Security Mechanism Names for Media June 2013 1. Introduction RFC 3329 [4] describes negotiation of a security mechanism for SIP signalling between a UAC and its first hop proxy. This document describes exchange of security capability for the media plane. Similar to the signalling plane, the evolution of security mechanisms for media often introduces new algorithms, or uncovers problems in existing ones, making negotiation of mechanisms a necessity. The purpose of this specification is to describe a new header field parameter for the Session Initiation Protocol (SIP) [1] to distinguish security mechanisms that apply to the media plane. Such security mechanism names MUST be unique and therefore require an IANA registry. This header field parameter may be used with the Security- Client, Security-Server, and Security-Verify header fields defined by RFC 3329 [4]. 1.1. Motivations 1.1.1. Access Network Protection Some access technologies protect the data passed over them by default, for example many cellular wireless accesses, but some do not, for example WLAN. For accesses with no protection, it is useful for the media controlled by SIP signalling to be protected by default because of vulnerability to eavesdropping. It is currently possible for a UA to request protection of the media plane end-to-end by including the crypto attribute in SDP at session setup. This does not guarantee protection however, because it relies on support of encryption by the called UA, or by another entity in the path taken by the media. In some cases, the session will originate in an access that protects the media and terminate in one that does not, meaning that media is protected in all but some hops of its path. In cases where the same provider supplies the user equipment and provides the IP access, the IP access technology that the UA will use is predictable and the media is vulnerable only as far as the core network. In such cases, the user equipment it is possible to protect the media plane by encrypting at the UA and decrypting at the edge of the core network, and for the user agent that originates or terminates the session to expect the edge of the core network to be capable of encrypting and decrypting media. The header field parameter described in this document enables this case of first-hop protection, which is typically provided by default to a user agent. Both media and signalling must pass through the entity at the edge of the core network, which must therefore be a back-to-back user agent (B2BUA). Dawes Expires December 23, 2013 [Page 3] Internet-Draft Security Mechanism Names for Media June 2013 End to access edge media protection described in this document is not a substitute for end-to-end media protection. 2. Solution This document defines the "mediasec" header field parameter that labels any of the Security-Client:, Security-Server:, or Security- Verify: header fields as applicable to the media plane and not the signalling plane. 2.1. Header Fields Defined in RFC3329 The "mediasec" header field parameter defined in this document is used with procedures defined in RFC 3329 [4] to distinguish media plane security, with the difference that media plane security need not be started immediately and can be applied and removed on-the-fly as media are added and removed within a session. Media plane security can be supported independently of any signalling plane security defined in RFC 3329 [4], but in order to protect any cryptographic key carried in SDP signalling plane security as defined in RFC 3329 [4] SHOULD be used. This document requires the first reliable response to include the media plane security capabilities, and therefore adds the 2xx response to the SIP responses that can contain the Security-Client, Security-Server, and Security-Verfiy header fields. RFC 3329 [4] allows the Security-Server header field only in SIP responses 421 (Extension Required) and 494 (Security Agreement Required). 2.2. Syntax This document does not define any new SIP header fields, it defines a header field parameter for header fields Security-Client, Security- Server and Security-Verify defined in RFC 3329 [4]. 2.3. Protocol Operation 2.3.1. The "mediasec" Header Field Parameter The "mediasec" header field parameter may be used in the Security- Client, Security-Server, or Security-Verfiy header fields defined in RFC 3329 [4] to indicate that a header field applies to the media plane. Any one of the media plane security mechanisms supported by both client and server, if any, may be applied when a media stream is started. Or a media stream may be set up without security. Dawes Expires December 23, 2013 [Page 4] Internet-Draft Security Mechanism Names for Media June 2013 Values in the Security-Client, Security-Server, or Security-Verfiy header fields labelled with the "mediasec" header field parameter are specfic to the media plane and specific to the secure media transport protocol used on the media plane. 2.3.2. Client Initiated A client wishing to use the security capability exchange of this specification MUST add a Security-Client header field to a request addressed to its first-hop proxy (i.e., the destination of the request is the first-hop proxy). This header field contains a list of all the media plane security mechanisms that the client supports. The client SHOULD NOT add preference parameters to this list. The client MUST add a "mediasec" header field parameter to the Security- Client header field. The contents of the Security-Client header field may be used by the server to include any necessary information in its response. As described in RFC 3329 [4], the response will be 494 if the client includes "sec-agree" in the Require and Proxy-Require header fields, or a 2xx response if the Require and Proxy-Require header fields do not contain "sec-agree". The server MUST add its list to the response even if there are no common security mechanisms in the client's and server's lists. The server's list MUST NOT depend on the contents of the client's list. All the subsequent SIP requests sent by the client to that server MAY make use of the security mechanism initiated in the previous step by including media plane security parameters in SDP in the session or the media description. These requests MUST contain a Security-Verify header field that mirrors the server's list received previously in the Security-Server header field. The server MUST check that the security mechanisms listed in the Security-Verify header field of incoming requests correspond to its static list of supported security mechanisms. Note that, following the standard SIP header field comparison rules defined in RFC 3261 [7], both lists have to contain the same security mechanisms in the same order to be considered equivalent. In addition, for each particular security mechanism, its parameters in both lists need to have the same values. Dawes Expires December 23, 2013 [Page 5] Internet-Draft Security Mechanism Names for Media June 2013 The server can proceed processing a particular request if, and only if, the list was not modified. If modification of the list is detected, the server MUST respond to the client with a 494 (Security Agreement Required) response. This response MUST include the server's unmodified list of supported security mechanisms. Once security capabilities have been exchanged between two SIP entities, the same SIP entities MAY use the same security when communicating with each other in different SIP roles. For example, if a UAC and its outbound proxy exchange some media-plane security mechanisms, they may try to use the same security for incoming requests (i.e., the UA will be acting as a UAS). The user of a UA SHOULD be informed about the results of the security mechanism agreement. The user MAY decline to accept a particular security mechanism, and abort further SIP communications with the peer. 2.4. Security Mechanism Initiation Once the client chooses a security mechanism from the list received in the Security-Server header field from the server, it MAY initiate that mechanism on a session level, or on a media level when it initiates new media in an existing session. 2.5. Duration of Security Assocations Once media-plane security capabilities have been exchanged, both the server and the client need to know until when they can be used. The media plane security mechanism setup is valid for as long as the UA has a SIP signalling relationship with its first-hop proxy or until new keys are exchanged in SDP. In many cases, the SDP used to set up media plane security will be protected by a security association used to protect SIP signalling. If SIP signalling is protected by a security association, then the media plane security mechanism can be used until the signalling plane security association expires. 2.6. Summary of Header Field Use The header fields defined in this document may be used to exchange supported media plane security mechanisms between a UAC and other SIP entities including UAS, proxy, and registrar. Information about the use of headers in relation to SIP methods and proxy processing is summarized in Table 1. +-----------------+---------------+-------+-------------------------+ | Header field | where | proxy | ACK BYE CAN INV OPT REG | +-----------------+---------------+-------+-------------------------+ Dawes Expires December 23, 2013 [Page 6] Internet-Draft Security Mechanism Names for Media June 2013 | Security-Client | R | ard | - o - o o o | | Security-Server | 2xx, 421, 494 | ard | - o - o o o | | Security-Verify | R | ard | - o - o o o | | | | | | | | | | SUB NOT PRK IFO UPD MSG | | Security-Client | R | ard | o o - o o o | | Security-Server | 2xx, 421, 494 | ard | o o - o o o | | Security-Verify | R | ard | o o - o o o | +-----------------+---------------+-------+-------------------------+ Table 1: Summary of Header Field Usage The "where" column describes the request and response types in which the header field may be used. The header may not appear in other types of SIP messages. Values in the where column are: R: Header field may appear in requests. 2xx, 421, 494: A numerical value indicates response codes with which the header field can be used. a: A proxy can add or concatenate the header field if not present. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. d: A proxy can delete a header field value. The next six columns relate to the presence of a header field in a method: o: The header field is optional. 3. Backwards Compatibility Security mechanisms that apply to the media plane only MUST NOT have the same name as any signalling plane mechanism. If a signalling plane security mechanism name is re-used for the media plane and distinguished only by the "mediasec" parameter, then implementations that do not recognize the "mediasec" parameter may incorrectly use that security mechanism for the signalling plane. 4. Examples The following examples illustrate the use of the mediasec header field parameter defined above. Dawes Expires December 23, 2013 [Page 7] Internet-Draft Security Mechanism Names for Media June 2013 4.1. Initial Registration 3GPP At initial registration, the client includes its supported media plane security mechanisms in the SIP REGISTER request. The first-hop proxy returns its supported media plane security mechanisms in the SIP 401 (Unauthorized) response. As per RFC 3329 [4], a UA negotiates the security mechanism for the media plane to be used with its outbound proxy without knowing beforehand which mechanisms the proxy supports, as shown in Figure 1 below. Dawes Expires December 23, 2013 [Page 8] Internet-Draft Security Mechanism Names for Media June 2013 UAC Proxy Registrar user1_public1@home1.net pcscf1.home1.net registrar.home1.net | | | |------(1) REGISTER---->| | | Security-Client: mechanism-name; mediasec | | | | |---(2) REGISTER--->| | | | | |<----(3) 401-------| | | | |<-----(4) 401----------| | | Security-Server: mechanism-name; mediasec | | | |-----(5) REGISTER----->| | | Security-Client: mechanism-name; mediasec | Security-Verify: mechanism-name; mediasec | | | | |---(6) REGISTER--->| | | | | |<----(7) 200 OK----| | | | |<-----(8) 200 OK------ | | | | | |------(9) INVITE------>| | | Security-Verify: mechanism-name; mediasec | | | | Content-Type: application/sdp | | a=3ge2ae | | | a=crypto:1 AES_CM_128_HMAC_SHA1_80 | inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 | FEC_ORDER=FEC_SRTP | | | | Figure 1: Exchange of Media Security Mechanisms at Initial Registration The UAC sends a REGISTER request (1) to its outbound proxy indicating the security mechanisms for the media plane and that it supports in a Security-Client: header field. Indication of media security mechanisms is identified by the "mediasec" header field parameter. The outbound proxy forwards the REGISTER request (2) to the registrar with the Security-Client: header field removed as described in RFC 3329 [4]. The registrar responds with a 401 (Unauthorized) response (3) to the REGISTER request. Dawes Expires December 23, 2013 [Page 9] Internet-Draft Security Mechanism Names for Media June 2013 The outbound proxy responds forwards the 401 (Unauthorized) response (4) to the UAC with its own list of security mechanisms for the media plane in the Security-Server: header field. Security mechanisms for the media plane are distinguished by the "mediasec" header field parameter. The UAC sends a second REGISTER request (5) using the security credentials it received in the 401 (Unauthorized) response. The UAC includes the security mechanisms for the media plane and that it supports in a Security-Client: header field. The UAC also echos the list of security mechanisms it received from the outbound proxy in the Security-Server: header field. Media security mechanisms are distinguished by the "mediasec" header field parameter. The REGISTER request is forwarded to the registrar (6) and the registrar responds with 200 OK (7), which is forwarded to the UAC (8). When the connection is successfully established, the UAC sends an INVITE request(9) including an SDP description of the media plane security to be used (a="e2ae" and a crypto attribute). This INVITE contains a copy of the server's security list in a Security-Verify header field. The server verifies it, and since it matches its static list, it processes the INVITE and forwards it to the next hop. If this example was run without the Security-Server header field in Step (2), the UAC would not know what kind of security the other one supports, and would be forced to make error-prone trials. More seriously, if the Security-Verify header field was omitted in Step (3), the whole process would be prone to MitM attacks. An attacker could remove the media plane security description from the header in Step (1), therefore preventing protection of the media plane. (1) REGISTER sip:registrar.home1.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 From: ;tag=4fa3 To: Contact: ;expires=600000 Call-ID: apb03a0s09dkjdfglkj49111 Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:registrar.home1.net", response="" Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 Security-Client: mechanism-name; mediasec ***new*** Dawes Expires December 23, 2013 [Page 10] Internet-Draft Security Mechanism Names for Media June 2013 Require: sec-agree Proxy-Require: sec-agree CSeq: 1 REGISTER Supported: path Content-Length: 0 (2) REGISTER sip:registrar.home1.net SIP/2.0 Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 P-Access-Network-Info: Path: Require: P-Visited-Network-ID: P-Charging-Vector: From: To: Contact: Call-ID: Authorization: CSeq: Supported: Content-Length: (3) SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 From: ;tag=4fa3 To: ; tag=5ef4 Call-ID: apb03a0s09dkjdfglkj49111 WWW-Authenticate: Digest realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, ik="00112233445566778899aabbccddeeff", ck="ffeeddccbbaa11223344556677889900" CSeq: 1 REGISTER Content-Length: 0 (4) SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 From: To: Call-ID: WWW-Authenticate: Digest realm="registrar.home1.net", nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5 Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Security-Server: mechanism-name; mediasec ***new*** CSeq: Content-Length: (5) REGISTER sip:registrar.home1.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 From: ;tag=4fa3 Dawes Expires December 23, 2013 [Page 11] Internet-Draft Security Mechanism Names for Media June 2013 To: Contact: ;expires=600000 Call-ID: apb03a0s09dkjdfglkj49111 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" Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Security-Client: mechanism-name; mediasec ***new*** Security-Verify: mechanism-name; mediasec ***new*** Require: sec-agree Proxy-Require: sec-agree CSeq: 2 REGISTER Supported: path Content-Length: 0 (6) REGISTER sip:registrar.home1.net SIP/2.0 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 Max-Forwards: 69 P-Access-Network-Info: Path: Require: P-Visited-Network-ID: P-Charging-Vector: From: To: Contact: Call-ID: Authorization: CSeq: Supported: Content-Length: (7) SIP/2.0 200 OK 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 Path: From: To: Call-ID: Contact: ;expires=600000 CSeq: Date: Wed, 11 July 2001 08:49:37 GMT P-Associated-URI: , , Content-Length: (8) SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Path: From: To: Dawes Expires December 23, 2013 [Page 12] Internet-Draft Security Mechanism Names for Media June 2013 Call-ID: Contact: CSeq: Date: P-Associated-URI: Content-Length: Figure 2: Use of mediasec parameter 4.2. Re-Registration 3GPP Media plane security mechanisms are also exchanged when a registration is refreshed or a new public identity is registered. UAC Proxy Registrar user1_public1@home1.net pcscf1.home1.net registrar.home1.net | | | | | | |--------(1) REGISTER---->| | | Security-Client: mechanism-name; mediasec | Security-Verify: mechanism-name; mediasec | | | | |---(2) REGISTER--->| | | | | |<----(3) 200 OK----| | | | |<------(4) 200 OK------- | | | | | | | | Figure 3: Exchange of Media Security Mechanisms at Re-Registration The UAC sends a REGISTER request (1) and includes the security mechanisms for the media plane and that it supports in a Security- Client: header field. The UAC also echos the list of security mechanisms it received from the outbound proxy in the Security- Server: header field. Media security mechanisms are distinguished by the "mediasec" header field parameter. The REGISTER request is forwarded to the registrar (2) and the registrar responds with 200 OK (3), which is forwarded to the UAC (4). Dawes Expires December 23, 2013 [Page 13] Internet-Draft Security Mechanism Names for Media June 2013 (1) REGISTER sip:registrar.home1.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 From: ;tag=4fa3 To: Contact: ;expires=600000 Call-ID: apb03a0s09dkjdfglkj49111 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" Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 Security-Client: mechanism-name; mediasec ***new*** Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Security-Verify: mechanism-name; mediasec ***new*** Require: sec-agree Proxy-Require: sec-agree CSeq: 3 REGISTER Supported: path Content-Length: 0 (2) REGISTER sip:registrar.home1.net SIP/2.0 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 P-Access-Network-Info: Max-Forwards: 69 Path: Require: P-Visited-Network-ID: P-Charging-Vector: From: To: Contact: Call-ID: Authorization: CSeq: Supported: Content-Length: (3) SIP/2.0 200 OK 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 Path: From: To: Call-ID: Contact: ;expires=600000 CSeq: Date: Wed, 11 July 2001 08:49:37 GMT P-Associated-URI: , , Dawes Expires December 23, 2013 [Page 14] Internet-Draft Security Mechanism Names for Media June 2013 Content-Length: (4) SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Path: From: To: Call-ID: Contact: CSeq: Date: P-Associated-URI: Content-Length: Figure 4: Use of mediasec parameter 4.3. Client Initiated as per RFC 3329 Media plane security mechanisms are also exchanged at client initiated security negotiation described in RFC 3329 [4]. UAC Proxy UAS | | | |----(1) OPTIONS----->| | | | | |<-----(2) 494--------| | | | | |<=======TLS=========>| | | | | |----(3) INVITE------>| | | |----(4) INVITE--->| | | | | |<---(5) 200 OK----| |<----(6) 200 OK------| | | | | |------(7) ACK------->| | | |-----(8) ACK----->| | | | | | | | | | | | | |<-(Protected media)->|<---(Media)------>| | | | Dawes Expires December 23, 2013 [Page 15] Internet-Draft Security Mechanism Names for Media June 2013 Figure 5: Negotiation Initiated by the Client. After exchange of security capabilities, the UAC sends an INVITE request(3) including an SDP description of the media plane security to be used (a="e2ae" and a crypto attribute). This INVITE contains a copy of the server's security list in a Security-Verify header field. The server verifies it, and since it matches its static list, it processes the INVITE and forwards it to the next hop. (1) OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: digest Security-Client: mechanism-name; mediasec Require: sec-agree Proxy-Require: sec-agree (2) SIP/2.0 494 Security Agreement Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2 Security-Server: mechanism-name; mediasec (3) INVITE sip:proxy.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Security-Verify: mechanism-name; mediasec Route: sip:callee@domain.com Require: sec-agree Proxy-Require: sec-agree 4.4. Server Initiated as per RFC 3329 Media plane security mechanisms are also exchanged at server initiated security negotiation described in RFC 3329 [4]. UAC Proxy UAS | | | |-----(1) INVITE---->| | | | | |<-----(2) 421-------| | | | | |------(3) ACK------>| | | | | |<=======IKE========>| | | | | Dawes Expires December 23, 2013 [Page 16] Internet-Draft Security Mechanism Names for Media June 2013 |-----(4) INVITE---->| | | |----(5) INVITE--->| | | | | |<---(6) 200 OK----| |<----(7) 200 OK-----| | | | | |------(8) ACK------>| | | |-----(9) ACK----->| | | | | | | Figure 6: Negotiation Initiated by the Server. Media security mechanisms are included in Security-Server: and Security-Client: header fields in the same way as signalling security mechanisms. (1) INVITE sip:uas.example.com SIP/2.0 (2) SIP/2.0 421 Extension Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2 Security-Server: mechanism; mediasec (4) INVITE sip:uas.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Security-Verify: mechanism; mediasec Figure 7: Negotiation Initiated by the Server. 4.5. Using Media Plane Security To request end to access edge media security either on a session or media level the UE sends, for example, an SDP Offer for an SRTP stream containing one or more SDES crypto attributes, each with a key and other security context parameters required according to RFC 4568 [8], together with the attribute "a=3ge2ae". (3) INVITE sip:bob@ua2.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Security-Verify: mechanism-name;mediasec Dawes Expires December 23, 2013 [Page 17] Internet-Draft Security Mechanism Names for Media June 2013 Route: proxy.example.com Require: sec-agree, mediasec Proxy-Require: sec-agree, mediasec Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@ua1.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 285 v=0 o=alice 2890844526 2890844526 IN IP4 ua1.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/SAVP 0 a=3ge2ae a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 FEC_ORDER=FEC_SRTP a=rtpmap:0 PCMU/8000 (4) INVITE sip:bob@ua2.example.com SIP/2.0 Route: sip:proxy.example.com (5) SIP/2.0 200 OK (6) SIP/2.0 200 OK Security-Server: tls;q=0.2 Security-Server: mechanism-name;mediasec a=3ge2ae a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 Figure 8: Using media security 5. Formal Syntax Dawes Expires December 23, 2013 [Page 18] Internet-Draft Security Mechanism Names for Media June 2013 The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234]. "mediasec" is a "header field parameter", as defined by [RFC3968]. Header Field Name in which the parameter can appear. Security-Client Security-Server Security-Verify Header Fields Parameter Name Values Reference --------------- ---------------- -------- --------- Security-Client mediasec No [this document] Security-Server mediasec No [this document] Security-Verify mediasec No [this document] Name of the Header Field Parameter being registered. "mediasec" 6. Acknowledgements Remember, it's important to acknowledge people who have contributed to the work. This template was extended from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. 7. IANA Considerations This specification creates a new registry for media plane security mechanisms. 7.1. Registry for Media Plane Security Mechanisms The IANA has created a subregistry for media plane security mechanism token values to be used with the 'mediasec' header field parameter under the Session Initiation Protocol (SIP) Parameters registry. Security Mechanism Name for Media Reference --------------------------------- --------- Dawes Expires December 23, 2013 [Page 19] Internet-Draft Security Mechanism Names for Media June 2013 As per the terminology in [RFC5226], the registration policy for new media plane security mechanism token values shall be 'Specification Required'. 7.2. Registration Template To: ietf-sip-sec-agree-mechanism-name@iana.org Subject: Registration of a new SIP Security Agreement mechanism Mechanism Name: (Token value conforming to the syntax described in Section 2.2.) Published Specification(s): (Descriptions of new SIP media plane security agreement mechanisms require a published specification.) 7.3. Header Field Names This specification registers no new header fields. 7.4. Response Codes This specification registers no new response codes. 8. Security Considerations This specification is an extension of RFC 3329 [4] and as such shares the same security considerations. A further consideration of this specification is protection of the cryptographic key to be used for SRTP and carried in SDP. In order to protect this key, one of the security mechanisms defined in RFC 3329 [4] SHOULD be used in parallel with this specification. 9. References 9.1. Normative References [1] authSurName, authInitials., "example1", year. [2] authSurName, authInitials., "example2", year. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Dawes Expires December 23, 2013 [Page 20] Internet-Draft Security Mechanism Names for Media June 2013 [4] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003. [5] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [6] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [8] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [11] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010. [12] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010. 9.2. Informative References [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [14] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Dawes Expires December 23, 2013 [Page 21] Internet-Draft Security Mechanism Names for Media June 2013 Appendix A. Additional stuff You can add appendices just as regular sections, the only difference is that they go within the "back" element, and not within the "middle" element. And they follow the "reference" elements. Author's Address Peter Dawes Vodafone Group Services Ltd. Newbury UK Email: peter.dawes@vodafone.com Dawes Expires December 23, 2013 [Page 22]