Internet DRAFT - draft-wing-rtcweb-sdes-problems
draft-wing-rtcweb-sdes-problems
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]
