idnits 2.17.1 draft-wing-rtcweb-sdes-problems-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2012) is 4145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5479 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-05 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Standards Track December 18, 2012 5 Expires: June 21, 2013 7 Problems with Security Descriptions in RTCWEB Architecture 8 draft-wing-rtcweb-sdes-problems-00 10 Abstract 12 This document analyzes the problems of deploying Security 13 Descriptions on the RTCWEB architecture. This document contributes 14 to the discussion and analysis of Security Descriptions, and is not 15 intended to become an RFC. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 21, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problems with Security Descriptions in RTCWEB . . . . . . . . . 3 53 2.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Impossible to Provide Strong Identity . . . . . . . . . . . 4 55 2.3. Mixing Weakens Security for Conference Calls . . . . . . . 4 56 2.4. Vulnerable to Passive Attack . . . . . . . . . . . . . . . 5 57 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 62 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 Over the years, there have been almost 20 different mechanisms for 68 establishing SRTP [RFC3711] keys. Several years ago, two RTPSEC BoFs 69 (IETF66, IETF68) concluded that DTLS-SRTP was the preferred keying 70 mechanism [RFC5479]. The RTCWEB working group has concluded that 71 DTLS-SRTP [RFC5763] will be used for browser-to-browser calls. 73 However, the RTCWEB working group has also been considering 74 supporting Security Descriptions [RFC4568] as another keying 75 mechanism. The primary reason for allowing Security Descriptions is 76 to allow easy interworking with existing SRTP endpoints that support 77 Security Descriptions, that is, for calls from a browser to a non- 78 browser and vise versa. Other reasons are summarized in 79 [I-D.ohlsson-rtcweb-sdes-support]. 81 2. Problems with Security Descriptions in RTCWEB 83 This section describes the problems that occur by supporting Security 84 Descriptions in the RTCWEB architecture. 86 2.1. Downgrade Attacks 88 At IETF83, RTCWEB reached consensus that (unencrypted) RTP would not 89 be supported by RTCWEB endpoints. 91 While RTCWEB has agreed DTLS-SRTP will be used for keying "between 92 web browsers", there exists no cryptographically strong mechanism to 93 enforce this restriction. That is, there is no way to determine the 94 remote peer supports DTLS-SRTP, because the signaling (indicating 95 support of DTLS-SRTP) may have been manipulated on the path; the 96 signaling is not integrity protected end to end. This means all 97 RTCWEB hosts are vulnerable to a downgrade attack to Security 98 Descriptions (by merely removing the associated SDP lines). 100 One mitigation is for the RTCWEB endpoint to integrity protect its 101 signaling message and for the remote endpoint to validate the 102 integrity of the received signaling message. However, there is no 103 existing mechanism to protect the message integrity in that manner. 104 The existing SIP Identity [RFC4474] provides integrity protection of 105 the entire SDP, including the IP addresses in the SDP, which does not 106 survive SDP changes SBCs or by NATs doing SIP ALG rewriting. That 107 is, ICE would work alright with SIP Identity, but Trickle ICE is not 108 described for SIP Identity. 110 Another mitigation is to create a cryptographically strong mechanism 111 to determine the SRTP keying supported by a remote endpoint, such as 112 publishing into a directory (e.g., DNS protected by DNSSEC similar to 113 how email's DKIM or SPF). This is considered as an Identity Provider 114 in [I-D.ietf-rtcweb-security-arch]. However, this can be problematic 115 in practice, as a SIP user can have multiple endpoints with the same 116 identity (e.g., dwing@example.com) with different SRTP keying 117 capabilities, such as a WEBRTC endpoint and a non-WEBRTC voicemail 118 system. 120 +------------+ +------------+ 121 | web server +-----?----+ web server + 122 +-----+-+----+ +------+-----+ 123 / \ | 124 DTLS-SRTP / \ DTLS-SRTP | 125 / \ | 126 +-------+ +-------+ +---+---+ 127 | Alice +-------| Bob +-------+ Carol | 128 +-------+ media +-------+ media +-------+ 130 Figure 1: RTCWEB trapezoid 132 2.2. Impossible to Provide Strong Identity 134 Security Descriptions cannot provide proof of identity. It is often 135 useful to know you are speaking to a bank, a merchant, a travel 136 agency, or a specific person. With Security Descriptions, this can 137 never be achieved. 139 With DTLS-SRTP, a strong identity could be assured, because each 140 endpoint possesses a private key, and the DTLS-SRTP handshake proves 141 the endpoint possesses that private key. Their public key can be 142 signed by an Identity Provider [I-D.ietf-rtcweb-security-arch], and 143 correlated with the encrypted media stream 144 [I-D.wing-sip-identity-media]. 146 There is no way for Security Descriptions to provide this 147 functionality. 149 2.3. Mixing Weakens Security for Conference Calls 151 If a call starts as a browser-to-browser call, it will be keyed using 152 DTLS-SRTP. If another party is added to the call (becoming a 3-way 153 call), and that new party is on an IP PBX using Security 154 Descriptions, the new party will be keyed using Security 155 Descriptions. 157 This is shown in the diagram below, where Alice and Bob are both 158 using web browsers and key using DTLS-SRTP, and then Carol joins the 159 call and is keyed using Security Descriptions: 161 +-------+ 162 | Alice | 163 +---|---+ 164 /\ 165 DTLS-SRTP / \ SDES 166 / \ 167 +-------+ +-------+ 168 | Bob |------| Carol | 169 +-------+ SDES +-------+ 171 Figure 2: Mixed DTLS-SRTP and SDES 173 When this occurs, the creation of the Security Descriptions leg 174 exposes all parties (Alice, Bob, and Carol) to the weaknesses of 175 Security Descriptions. The alternative, which maintains security of 176 Alice and Bob's communications on their networks, is to interwork 177 with Carol using DTLS-SRTP. 179 2.4. Vulnerable to Passive Attack 181 The session key that encrypts the SRTP stream is sent within SIP 182 signaling, and is seen by all SIP signaling entities along the 183 signaling path (SIP proxies, B2BUAs, SBCs). Any of those SIP 184 signaling entities can use the session key to decyrpt the SRTP- 185 encrypted media, passively, without modifying any aspect of the 186 signaling. As shown in the figure below, an RTCWEB call can be 187 between web servers in different administrative domains, and can 188 traverse SIP proxies. With Security Descriptions, an attacker can 189 record the encrypted SRTP media and obtain the Security Description 190 keys any time later and decrypt the media. The Security Description 191 keys can be obtained by compromising any of the signaling elements on 192 the path, obtaining log files from any of the signaling elements on 193 the path (e.g., such as from backup tapes). As this attack is 194 passive, the victims have no way to determine such an attack 195 occurred. 197 +------------+ +-------------+ +------------+ 198 | web server +--+ SIP proxies +--+ web server + 199 +-----+------+ +-------------+ +------+-----+ 200 | | 201 | | 202 | | 203 +----+--+ +---+---+ 204 | Alice +--------------------------+ Carol | 205 +-------+ SRTP media +-------+ 207 There is no defense from this attack. 209 2.5. Forking 211 With Security Descriptions, the sender's key is included in the 212 INVITE. When SIP forks an INVITE to multiple user agents (such as 213 with multiple telephone extensions) all of those user agents receive 214 the key and could decrypt one direction of the SRTP flow if the SRTP 215 is captured. It is possible to correct this problem by issuing a re- 216 INVITE (with a new key) after every initial INVITE, but that prevents 217 a re-INVITE from being sent for other reasons (because only one 218 INVITE can be processed at a time), and increases the number of call 219 signaling messages. Other approaches have been discussed, such as 220 splitting the Security Descriptions key in half, and more recently 221 [I-D.zhou-mmusic-sdes-keymod]. 223 It is possible to extend Security Descriptions to defend against this 224 attack. 226 3. Security Considerations 228 This entire document describes security considerations. 230 4. IANA Considerations 232 None. 234 5. References 236 5.1. Normative References 238 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 239 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 240 RFC 3711, March 2004. 242 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 243 Description Protocol (SDP) Security Descriptions for Media 244 Streams", RFC 4568, July 2006. 246 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 247 "Requirements and Analysis of Media Security Management 248 Protocols", RFC 5479, April 2009. 250 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 251 for Establishing a Secure Real-time Transport Protocol 252 (SRTP) Security Context Using Datagram Transport Layer 253 Security (DTLS)", RFC 5763, May 2010. 255 5.2. Informative References 257 [I-D.ietf-rtcweb-security-arch] 258 Rescorla, E., "RTCWEB Security Architecture", 259 draft-ietf-rtcweb-security-arch-05 (work in progress), 260 October 2012. 262 [I-D.ohlsson-rtcweb-sdes-support] 263 Ohlsson, O., "Support of SDES in WebRTC", 264 draft-ohlsson-rtcweb-sdes-support-01 (work in progress), 265 August 2012. 267 [I-D.wing-sip-identity-media] 268 Wing, D. and H. Kaplan, "SIP Identity using Media Path", 269 draft-wing-sip-identity-media-02 (work in progress), 270 February 2008. 272 [I-D.zhou-mmusic-sdes-keymod] 273 Zhou, S. and T. Tian, "Security Descriptions Extension for 274 Media Streams", draft-zhou-mmusic-sdes-keymod-01 (work in 275 progress), March 2012. 277 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 278 Authenticated Identity Management in the Session 279 Initiation Protocol (SIP)", RFC 4474, August 2006. 281 Author's Address 283 Dan Wing 284 Cisco Systems, Inc. 285 170 West Tasman Drive 286 San Jose, California 95134 287 USA 289 Email: dwing@cisco.com