Network Working Group D. Wing Internet-Draft Cisco Intended status: Informational S. Fries Expires: April 19, 2007 Siemens AG H. Tschofenig Siemens Networks GmbH & Co KG October 16, 2006 Media Security Requirements draft-wing-media-security-requirements-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Wing, et al. Expires April 19, 2007 [Page 1] Internet-Draft Media Security Requirements October 2006 Abstract A number of proposals have been published to address the need of securing media traffic. Different assumptions, requirements, and usage environments justify every one of them. This document aims to summarize the discussed media security requirements in order progress the work on identifying a small subset applicable to a large range of deployment environments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Discussion of Call Scenarios . . . . . . . . . . . . . . . . . 5 3.1. Clipping Media before answer . . . . . . . . . . . . . . . 5 3.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 5 3.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Out-of-Scope and Discussion Items . . . . . . . . . . . . . . 11 6. Clustering Requirements according to Environments . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Wing, et al. Expires April 19, 2007 [Page 2] Internet-Draft Media Security Requirements October 2006 1. Introduction The work on media security started a long time ago where the capability of the Session Initiation Protocol (SIP) was still at its infancy. With the larger deployment and the available SIP extensions and related protocols the need for end-to-end security was re- evaluated. The procedure of re-evaluating prior protocol work and design decisions is not an uncommon behavior and, to some extend, considered necessary protocol work to ensure that the developed protocols indeed meet the previously envisioned needs in the global Internet. This document aims to summarize the discussed media security requirements. Once a the list of requirements and architectural aspects have been investigated the work on the protocol proposals can be progressed by identifying a small number of soltuions and to complete the protocol work. This document is organized as follows. Section 2 introduces terminology, Section 3 provides an overview about possible call scenarios, Section 4 lists requirements, Section 6 will provide a clustering of requirements to certain deployment environments to adress the problem that there might not be a single solution with universal applicability and Section 5 provides out-of-scope items and aspects for further discussion. The document concludes with a security considerations Section 7, IANA considerations Section 8 and an acknowledgement section in Section 9. Wing, et al. Expires April 19, 2007 [Page 3] Internet-Draft Media Security Requirements October 2006 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Wing, et al. Expires April 19, 2007 [Page 4] Internet-Draft Media Security Requirements October 2006 3. Discussion of Call Scenarios The following subsections describe call scenarios, which have been discussed elaborately. These call scenarios pose the most challenge to the key management for media data in cooperation with SIP signaling. The scenarios have already been described as part of the key management evaluation draft [I-D.wing-rtpsec-keying-eval], and are stated here to give a better insight in these discussion. 3.1. Clipping Media before answer Per the SDP Offer/Answer Model [RFC3264], "Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information)." To meet this requirement with SRTP, the offerer needs to know the SRTP key for arriving media. If encrypted SRTP media arrives before the associated SRTP key, the offerer cannot play the media -- causing clipping. For key exchange mechanisms which send the answerer's key in SDP, a SIP provisional response [RFC3261] such as 183 (session progress) is useful. However the 183 messages aren't reliable unless both the calling and called endpoint support PRACK [RFC3262], use TCP across all SIP proxies, implement Security Preconditions [I-D.ietf-mmusic-securityprecondition], or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer implements the reliable provisional response mechanism described in ICE. However, there is not wide deployment of any of these techniques and there is industry reluctance to requiring these techniques as solutions to avoid the problem described in this section. Furthermore, the problem gets compounded when forking is used. For example, if using a Diffie-Hellman keying technique with security preconditions that forks to 20 endpoints, the call initiator would get 20 provisional responses containing 20 signed Diffie-Hellman half keys. Calculating 20 DH secrets and validating signatures can be a difficult task depending on the device capabilities. 3.2. Retargeting and Forking In SIP, a request sent to a specific AOR but delivered to a different AOR is called a "retarget". A typical scenario is a "call Wing, et al. Expires April 19, 2007 [Page 5] Internet-Draft Media Security Requirements October 2006 forwarding" feature. In the figure below, Alice sends an Invite in step 1 which is sent to Bob in step 2. Bob responds with a redirect (SIP response code 3xx) pointing to Carol in step 3. This redirect typically does not propagate back to Alice but only goes to a proxy (i.e., the retargeting proxy) which sends the original Invite to Carol in step 4. +-----+ |Alice| +--+--+ | | Invite (1) V +----+----+ | proxy | ++-+-----++ | ^ | Invite (2) | | | Invite (4) & redirect (3) | | | V | V ++-++ ++----+ |Bob| |Carol| +---+ +-----+ Figure 1: Retargeting Successful use of SRTP requires strongly identifying both calling party and the called party. The mechanism used by SIP for identifying the calling party is SIP Identity [RFC3261]. However, due to SIP retargeting issues [I-D.peterson-sipping-retarget], SIP Identity can only identify the calling party (that is, the party that initiated the SIP request). Some key exchange mechanisms predate SIP Identity and include their own identity mechanism. However, those built-in identity mechanism suffer from the same SIP retargeting problem described in the above draft. Going forward, it is anticipated that Connected Identity [I-D.ietf-sip-connected-identity] may allow identifying the called party. This is also described as the 'retargeting identity' problem. In SIP, 'forking' is the delivery of a request to multiple locations. This happens when a single AOR is registered more than once. An example of forking is when a user has a desk phone, PC client, and mobile handset all registered with the same AOR. Wing, et al. Expires April 19, 2007 [Page 6] Internet-Draft Media Security Requirements October 2006 +-----+ |Alice| +--+--+ | | Invite V +-----+-----+ | proxy | ++---------++ | | Invite | | Invite V V +--+--+ +--+--+ |Bob-1| |Bob-2| +-----+ +-----+ Figure 2: Forking With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP responses. Alice will see those intermediate (18x) and final (200) responses. It is useful for Alice to be able to associate the SIP response with the incoming media stream. Although this association can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make this association with RTP, it isn't desirable to require ICE to accomplish this association. The table below analyzes if it is possible for an offerer to associate the media stream with each SDP answer, without using ICE. Forking and retargeting are often used together. For example, a boss and secretary might have both phones ring and rollover to voice mail if neither phone is answered. To maintain media security, only the endpoint that answers the call should know the SRTP keys for the session. For key exchange mechanisms that don't provide secure forking or secure retargeting, one workaround is to rekey immediately after forking or retargeting. However, because the originator may not be aware that the call forked this mechanism requires rekeying immediately after every session is established which causes additional signaling messages. Retargeting securely introduces a more significant problem. With retargeting, the actual recipient of the request is not the original recipient. This means that if the offerer encrypted material (such as the session key or the SDP) using the original recipient's public key, the actual recipient will not be able to decrypt that material because the recipient won't have the original recipient's private key. In some cases, this is the intended behavior, i.e., you wanted to establish a secure connection with a specific individual. In Wing, et al. Expires April 19, 2007 [Page 7] Internet-Draft Media Security Requirements October 2006 other cases, it is not intended behavior (you want all voice media to be encrypted, regardless of who answers). For some forms of key management the calling party needs to know in advance the certificate or shared secret of the called party, and retargeting can interfere with this. Further compounding this problem is a particularity of SIP that when forking is used, there is always only one final error response delivered to the sender of the request: the forking proxy is responsible for choosing which final response to choose in the event where forking results in multiple final error responses being received by the forking proxy. This means that if a request is rejected, say with information that the keying information was rejected and providing the far end-end's credentials, it is very possible that the rejection will never reach the sender. This problem, called the Heterogeneous Error Response Forking Problem (HERFP) [draft-mahy-sipping-herfp-fix] is a complicated problem to solve in SIP. 3.3. Shared Key Conferencing For efficient scaling, large audio and video conference bridges operate most efficiently by encrypting the current speaker once and distributing that stream to the conference attendees. Typically, inactive participants receive the same streams -- they hear (or see) the active speaker(s), and the active speakers receive distinct streams that don't include themselves. In order to maintain confidentiality of such conferences where listeners share a common key, all listeners must rekeyed when a listener joins or leaves a conference. An important use case for mixers/translators is a conference bridge: +----+ A --- 1 --->| | <-- 2 ----| M | | I | B --- 3 --->| X | <-- 4 ----| E | | R | C --- 5 --->| | <-- 6 ----| | +----+ Figure 3: Centralized Keying In the figure above, 1, 3, and 5 are RTP media contributions from Wing, et al. Expires April 19, 2007 [Page 8] Internet-Draft Media Security Requirements October 2006 Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those devices carrying the 'mixed' media. Several scenarios are possible: a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions, b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP sessions, c. Single inbound session: 1, 3, and 5 are just different sources within the same RTP session, d. Single outbound session: 2, 4, and 6 are different flows of the same (multi-unicast) RTP session If there are multiple inbound sessions and multiple outbound sessions (scenarios a and b), then every keying mechanism behaves as if the mixer were an endpoint and can set up a point-to-point secure session between the participant and the mixer. This is the simplest situation, but is computationally wasteful, since SRTP processing has to be done independently for each participant. The use of multiple inbound sessions (scenario a) doesn't waste computational resources, though it does consume additional cryptographic context on the mixer for each participant and has the advantage of non-repudiation of the originator of the incoming stream. To support a single outbound session (scenario d), the mixer has to dictate its encryption key to the participants. Some keying mechanisms allow the transmitter to determine its own key, and others allow the offerer to determine the key for the offerer and answerer. Depending on how the call is established, the offerer might be a participant (such as a participant dialing into a conference bridge) or the offerer might be the mixer (such as a conference bridge calling a participant). The use of offerless Invites may help some keying mechanisms reverse the role of offerer/answerer. A difficulty, however, is knowing a priori if the role should be reversed for a particular call. Wing, et al. Expires April 19, 2007 [Page 9] Internet-Draft Media Security Requirements October 2006 4. Requirements R1: Forking and retargeting MUST work with all end-points being SRTP. R2: Forking and retargeting MUST allow establishing SRTP or RTP with a mixture of SRTP- and RTP-capable targets. R3: With forking, only the entity to which the call is finally established, MUST get hold of the media encryption keys. R5: A solution SHOULD avoid clipping media before SDP answer without additional signalling. R6: A solution MUST provide protection against passive attacks. R7: A solution MUST be able to support Perfect Forward Secrecy. R8: A solution MUST support algorithm negotiation without incurring per-algorithm computational expense. R9: A solution MUST support multiple cipher suites without additional computational expense. R10: Endpoint identification when forking. The Offerer must be able to associate answer with the appropriate flow endpoint. In case of forking one might not want to perform a DH with every party but instead to associate the SDP response with the right end point. This is a performance related requirement. R11: A solution MUST NOT require 3rd-party certs. If two parties share an auth infrastructure they should be able to use it. Wing, et al. Expires April 19, 2007 [Page 10] Internet-Draft Media Security Requirements October 2006 5. Out-of-Scope and Discussion Items The following aspects have been voted out-of-scope: o Shared-key encryption for conferencing (Note: it may be matter of discussion, if shared key conferencing stays as out-of-scope.) The following items are subject for further study: o A solution SHOULD allow to start with RTP and then upgrade to SRTP. o A solution SHOULD consider active attacks. o From an architectural point of view solutions can exchange key exchange messages along the media path, along the signaling path or on both paths. A solution SHOULD operate along the media path and the signaling path. o A solution SHOULD support the possibility to protect non-RTP-based data traffic. o A solution MUST protect cipher suite negotiation against downgrading attacks. o A solution MUST allow a SIP UE to negotiate media security parameters for each individual session. The following two requirements are typically raised by other SDOs and might be relevant in this context: o A solution SHOULD support media recording. o A solution SHOULD NOT allow end users to determine whether their end-to-end interaction is subject to lawful interception. Wing, et al. Expires April 19, 2007 [Page 11] Internet-Draft Media Security Requirements October 2006 6. Clustering Requirements according to Environments It is not possible to fulfill all requirements presented in Section 4 to be useful in all environments. This section aims to describe the usage environments and to cluster solutions with respect to these environments to distil a small set of solutions fulfilling these requirements. [Editor's Note: Text will be provided in a future version of this document.] Wing, et al. Expires April 19, 2007 [Page 12] Internet-Draft Media Security Requirements October 2006 7. Security Considerations This document lists requirements for securing media traffic. As such, it addresses security throughout the document. Wing, et al. Expires April 19, 2007 [Page 13] Internet-Draft Media Security Requirements October 2006 8. IANA Considerations This document does not require actions by IANA. Wing, et al. Expires April 19, 2007 [Page 14] Internet-Draft Media Security Requirements October 2006 9. Acknowledgements The authors would like to thank the active participants of the RTPSEC BOF and Wolfgang Buecker, Guenther Horn, Peter Howard, Hans-Heinrich Grusdt, Srinath Thiruvengadam and Martin Euchner for their feedback to this document.Especially thank to Francois Audet for the work on the key management evaluation. Wing, et al. Expires April 19, 2007 [Page 15] Internet-Draft Media Security Requirements October 2006 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 10.2. Informative References [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in progress), October 2006. [I-D.ietf-mmusic-securityprecondition] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", draft-ietf-mmusic-securityprecondition-02 (work in progress), June 2006. [I-D.ietf-sip-connected-identity] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", draft-ietf-sip-connected-identity-02 (work in progress), October 2006. [I-D.peterson-sipping-retarget] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", draft-peterson-sipping-retarget-00 (work in progress), February 2005. [I-D.wing-rtpsec-keying-eval] Audet, F. and D. Wing, "Evaluation of SRTP Keying with SIP", draft-wing-rtpsec-keying-eval-01 (work in progress), Wing, et al. Expires April 19, 2007 [Page 16] Internet-Draft Media Security Requirements October 2006 June 2006. Wing, et al. Expires April 19, 2007 [Page 17] Internet-Draft Media Security Requirements October 2006 Authors' Addresses Dan Wing Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Steffen Fries Siemens AG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: steffen.fries@siemens.com Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Wing, et al. Expires April 19, 2007 [Page 18] Internet-Draft Media Security Requirements October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wing, et al. Expires April 19, 2007 [Page 19]