[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/