RTCWEB Working Group D. Wing Internet-Draft Cisco Intended status: Standards Track December 18, 2012 Expires: June 21, 2013 Problems with Security Descriptions in RTCWEB Architecture draft-wing-rtcweb-sdes-problems-00 Abstract This document analyzes the problems of deploying Security Descriptions on the RTCWEB architecture. This document contributes to the discussion and analysis of Security Descriptions, and is not intended to become an RFC. 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 June 21, 2013. Copyright Notice Copyright (c) 2012 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 (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. Wing Expires June 21, 2013 [Page 1] Internet-Draft Security Descriptions in RTCWEB December 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems with Security Descriptions in RTCWEB . . . . . . . . . 3 2.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . . 3 2.2. Impossible to Provide Strong Identity . . . . . . . . . . . 4 2.3. Mixing Weakens Security for Conference Calls . . . . . . . 4 2.4. Vulnerable to Passive Attack . . . . . . . . . . . . . . . 5 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Wing Expires June 21, 2013 [Page 2] Internet-Draft Security Descriptions in RTCWEB December 2012 1. Introduction Over the years, there have been almost 20 different mechanisms for establishing SRTP [RFC3711] keys. Several years ago, two RTPSEC BoFs (IETF66, IETF68) concluded that DTLS-SRTP was the preferred keying mechanism [RFC5479]. The RTCWEB working group has concluded that DTLS-SRTP [RFC5763] will be used for browser-to-browser calls. However, the RTCWEB working group has also been considering supporting Security Descriptions [RFC4568] as another keying mechanism. The primary reason for allowing Security Descriptions is to allow easy interworking with existing SRTP endpoints that support Security Descriptions, that is, for calls from a browser to a non- browser and vise versa. Other reasons are summarized in [I-D.ohlsson-rtcweb-sdes-support]. 2. Problems with Security Descriptions in RTCWEB This section describes the problems that occur by supporting Security Descriptions in the RTCWEB architecture. 2.1. Downgrade Attacks At IETF83, RTCWEB reached consensus that (unencrypted) RTP would not be supported by RTCWEB endpoints. While RTCWEB has agreed DTLS-SRTP will be used for keying "between web browsers", there exists no cryptographically strong mechanism to enforce this restriction. That is, there is no way to determine the remote peer supports DTLS-SRTP, because the signaling (indicating support of DTLS-SRTP) may have been manipulated on the path; the signaling is not integrity protected end to end. This means all RTCWEB hosts are vulnerable to a downgrade attack to Security Descriptions (by merely removing the associated SDP lines). One mitigation is for the RTCWEB endpoint to integrity protect its signaling message and for the remote endpoint to validate the integrity of the received signaling message. However, there is no existing mechanism to protect the message integrity in that manner. The existing SIP Identity [RFC4474] provides integrity protection of the entire SDP, including the IP addresses in the SDP, which does not survive SDP changes SBCs or by NATs doing SIP ALG rewriting. That is, ICE would work alright with SIP Identity, but Trickle ICE is not described for SIP Identity. Another mitigation is to create a cryptographically strong mechanism to determine the SRTP keying supported by a remote endpoint, such as Wing Expires June 21, 2013 [Page 3] Internet-Draft Security Descriptions in RTCWEB December 2012 publishing into a directory (e.g., DNS protected by DNSSEC similar to how email's DKIM or SPF). This is considered as an Identity Provider in [I-D.ietf-rtcweb-security-arch]. However, this can be problematic in practice, as a SIP user can have multiple endpoints with the same identity (e.g., dwing@example.com) with different SRTP keying capabilities, such as a WEBRTC endpoint and a non-WEBRTC voicemail system. +------------+ +------------+ | web server +-----?----+ web server + +-----+-+----+ +------+-----+ / \ | DTLS-SRTP / \ DTLS-SRTP | / \ | +-------+ +-------+ +---+---+ | Alice +-------| Bob +-------+ Carol | +-------+ media +-------+ media +-------+ Figure 1: RTCWEB trapezoid 2.2. Impossible to Provide Strong Identity Security Descriptions cannot provide proof of identity. It is often useful to know you are speaking to a bank, a merchant, a travel agency, or a specific person. With Security Descriptions, this can never be achieved. With DTLS-SRTP, a strong identity could be assured, because each endpoint possesses a private key, and the DTLS-SRTP handshake proves the endpoint possesses that private key. Their public key can be signed by an Identity Provider [I-D.ietf-rtcweb-security-arch], and correlated with the encrypted media stream [I-D.wing-sip-identity-media]. There is no way for Security Descriptions to provide this functionality. 2.3. Mixing Weakens Security for Conference Calls If a call starts as a browser-to-browser call, it will be keyed using DTLS-SRTP. If another party is added to the call (becoming a 3-way call), and that new party is on an IP PBX using Security Descriptions, the new party will be keyed using Security Descriptions. Wing Expires June 21, 2013 [Page 4] Internet-Draft Security Descriptions in RTCWEB December 2012 This is shown in the diagram below, where Alice and Bob are both using web browsers and key using DTLS-SRTP, and then Carol joins the call and is keyed using Security Descriptions: +-------+ | Alice | +---|---+ /\ DTLS-SRTP / \ SDES / \ +-------+ +-------+ | Bob |------| Carol | +-------+ SDES +-------+ Figure 2: Mixed DTLS-SRTP and SDES When this occurs, the creation of the Security Descriptions leg exposes all parties (Alice, Bob, and Carol) to the weaknesses of Security Descriptions. The alternative, which maintains security of Alice and Bob's communications on their networks, is to interwork with Carol using DTLS-SRTP. 2.4. Vulnerable to Passive Attack The session key that encrypts the SRTP stream is sent within SIP signaling, and is seen by all SIP signaling entities along the signaling path (SIP proxies, B2BUAs, SBCs). Any of those SIP signaling entities can use the session key to decyrpt the SRTP- encrypted media, passively, without modifying any aspect of the signaling. As shown in the figure below, an RTCWEB call can be between web servers in different administrative domains, and can traverse SIP proxies. With Security Descriptions, an attacker can record the encrypted SRTP media and obtain the Security Description keys any time later and decrypt the media. The Security Description keys can be obtained by compromising any of the signaling elements on the path, obtaining log files from any of the signaling elements on the path (e.g., such as from backup tapes). As this attack is passive, the victims have no way to determine such an attack occurred. +------------+ +-------------+ +------------+ | web server +--+ SIP proxies +--+ web server + +-----+------+ +-------------+ +------+-----+ | | | | | | +----+--+ +---+---+ | Alice +--------------------------+ Carol | Wing Expires June 21, 2013 [Page 5] Internet-Draft Security Descriptions in RTCWEB December 2012 +-------+ SRTP media +-------+ There is no defense from this attack. 2.5. Forking With Security Descriptions, the sender's key is included in the INVITE. When SIP forks an INVITE to multiple user agents (such as with multiple telephone extensions) all of those user agents receive the key and could decrypt one direction of the SRTP flow if the SRTP is captured. It is possible to correct this problem by issuing a re- INVITE (with a new key) after every initial INVITE, but that prevents a re-INVITE from being sent for other reasons (because only one INVITE can be processed at a time), and increases the number of call signaling messages. Other approaches have been discussed, such as splitting the Security Descriptions key in half, and more recently [I-D.zhou-mmusic-sdes-keymod]. It is possible to extend Security Descriptions to defend against this attack. 3. Security Considerations This entire document describes security considerations. 4. IANA Considerations None. 5. References 5.1. Normative References [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009. Wing Expires June 21, 2013 [Page 6] Internet-Draft Security Descriptions in RTCWEB December 2012 [RFC5763] 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. 5.2. Informative References [I-D.ietf-rtcweb-security-arch] Rescorla, E., "RTCWEB Security Architecture", draft-ietf-rtcweb-security-arch-05 (work in progress), October 2012. [I-D.ohlsson-rtcweb-sdes-support] Ohlsson, O., "Support of SDES in WebRTC", draft-ohlsson-rtcweb-sdes-support-01 (work in progress), August 2012. [I-D.wing-sip-identity-media] Wing, D. and H. Kaplan, "SIP Identity using Media Path", draft-wing-sip-identity-media-02 (work in progress), February 2008. [I-D.zhou-mmusic-sdes-keymod] Zhou, S. and T. Tian, "Security Descriptions Extension for Media Streams", draft-zhou-mmusic-sdes-keymod-01 (work in progress), March 2012. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. Author's Address Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA Email: dwing@cisco.com Wing Expires June 21, 2013 [Page 7]