Internet DRAFT - draft-ohlsson-rtcweb-sdes-support


Network Working Group                                         O. Ohlsson
Internet-Draft                                                  Ericsson
Intended status: Informational                           August 20, 2012
Expires: February 21, 2013

                       Support of SDES in WebRTC


   Which key management protocols to support has been lively debated in
   WebRTC on several occasions.  This document explains the benefits of
   SDES and argues why allowing it as an alternative option has little
   impact on security.

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

   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 February 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
   ( 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.

Ohlsson                 Expires February 21, 2013               [Page 1]
Internet-Draft          Support of SDES in WebRTC            August 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Benefits of Supporting SDES  . . . . . . . . . . . . . . . . .  3
     2.1.  Reduced Complexity of WebRTC-SIP Gateway . . . . . . . . .  3
     2.2.  Reduced Processing (Less SRTP Terminations)  . . . . . . .  3
     2.3.  Reduced Call Setup Time  . . . . . . . . . . . . . . . . .  4
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
     3.1.  SDES in case of an Outside Attacker  . . . . . . . . . . .  5
       3.1.1.  Extraction of Log Data . . . . . . . . . . . . . . . .  6
       3.1.2.  Script Injection . . . . . . . . . . . . . . . . . . .  6
     3.2.  SDES in case of an Inside Attacker . . . . . . . . . . . .  7
       3.2.1.  Downgrade Attack . . . . . . . . . . . . . . . . . . .  7
       3.2.2.  Difficulties with Key Continuity . . . . . . . . . . .  8
       3.2.3.  3rd Party Identity Assertion . . . . . . . . . . . . .  9
   4.  Discussion and Conclusion  . . . . . . . . . . . . . . . . . .  9
   5.  Informative References . . . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11

Ohlsson                 Expires February 21, 2013               [Page 2]
Internet-Draft          Support of SDES in WebRTC            August 2012

1.  Introduction

   Which key management protocols to support has been lively debated in
   WebRTC on several occasions.  The main question is the following:
   Should applications be restricted to DTLS-SRTP or could SDES be
   allowed as an alternative option?

   In this document we identify and address the issues that have been
   raised.  We explain the benefits of SDES and argue why allowing it as
   an alternative option has little impact on security.

2.  Benefits of Supporting SDES

   Being able to communicate from WebRTC applications to existing SIP/
   RTP endpoints is a highly desirable use case.  The SIP installed base
   is huge and contains millions of devices and a large number of
   applications (e.g. conferencing and voicemail).  Even more important,
   nearly all mobile phones and landlines are reachable through SIP/RTP
   gateways deployed in service provider networks.  The same can also be
   said for other signaling protocols, such as XMPP or H.323.  As a
   sidenote, the recent work on the DTMF tone API in WebRTC proves that
   many members consider legacy interworking to be important.

2.1.  Reduced Complexity of WebRTC-SIP Gateway

   Communication between the Browser and SIP/RTP endpoint will most
   likely require some form om media-plane gateway (due to the need to
   terminate ICE).  The development and testing costs for such gateways
   are typically very high since they need to handle a large number of
   users and often contain special purpose hardware.  It is definitely
   worthwhile to try to reduce costs by lowering the complexity and
   removing functionality that is not strictly required.  This would
   result in lower prices which will lead to a higher degree of
   interconnectivity between WebRTC and existing SIP deployments.

   Already today there are Session Border Controllers (SBC) that perform
   SRTP termination on behalf of endpoints with SDES based keying (there
   are SBCs that support DTLS-SRTP but this is uncommon).  If the
   browser also supported SDES, the WebRTC gateway could simply forward
   all SRTP packets to the SBC and let it decide whether to terminate
   encryption or not (depending on the capabilities of the receiving

2.2.  Reduced Processing (Less SRTP Terminations)

   A large part of modern SIP/RTP devices support SRTP and most of them
   that do, use SDES based keying.  This is confirmed in the report from

Ohlsson                 Expires February 21, 2013               [Page 3]
Internet-Draft          Support of SDES in WebRTC            August 2012

   the latest [SIPit] event which stated that:

   o  80 percent of the tested implementations supported SRTP

   o  100 percent of the SRTP implementations supported SDES

   o  0 percent of the SRTP implementations supported DTLS-SRTP

   Although these figures may not be entirely accurate, they at least
   provide an indication of the current situation.

   The 3rd Generation Partnership Project (3GPP) has also selected SDES
   for key management in the IP Multimedia Subsystem (IMS)
   [3GPP.33.328].  We can therefore expect the number of SDES capable
   devices to increase as Voice over LTE (VoLTE) and other IMS based
   systems become more widely deployed.

   Provided SDES is included in browsers, calls between the WebRTC and
   SIP domains do not need to be encrypted/decrypted by an intermediate
   gateway when the SIP endpoint supports SDES.  This leads to a
   substantial reduction in processing cost for the gateway in SIP
   domains where a large part of the devices support SDES.  Another
   benefit is that for those endpoints that support SDES the call will
   be protected end-to-end for free.  Achieving this with DTLS-SRTP
   would require the gateway to first decrypt and then re-encrypt

   Note that the important question is whether the gateway needs to
   terminate SRTP at all.  Processing wise there is probably not that
   much difference in terminating an SRTP + SDES or an SRTP + DTLS-SRTP

   DTLS-SRTP with Encrypted Key Transport (EKT)
   [I-D.ietf-avtcore-srtp-ekt] has been suggested as an alternative to
   avoid expensive encryption/decryption in gateways.  If browsers
   support DTLS-SRTP with EKT, a gateway can force the browser and the
   SDES endpoint to agree on the same set of SRTP keys and algorithm
   settings.  Once this is done, the gateway will simply forward the
   SRTP (and SRTCP) packets in both directions.  The downside of using
   this approach is the increased complexity of the gateway (new
   protocols and additional signaling are required) and the lack of
   implementation experience.

2.3.  Reduced Call Setup Time

   With SDES a peer can begin to send media as soon as an ICE candidate
   pair has been nominated for use and the connectivity check for that
   pair has succeeded.  If DTLS-SRTP is being used the peer would also

Ohlsson                 Expires February 21, 2013               [Page 4]
Internet-Draft          Support of SDES in WebRTC            August 2012

   need to wait for the DTLS-SRTP handshake to complete, which requires
   two additional roundtrips.

   Obviously, being able to start sending media quickly is not very
   useful unless the receiver knows how to process the incoming packets.
   One common argument against SDES is its inability to handle early
   media (i.e. media that arrives at the SDP offerer before the SDP
   answer arrives).  However, this problem cannot occur if the offerer
   is ICE full.  To see why, recall that sending media requires that a
   candidate pair has been nominated for use by the ICE controlling
   agent, which is always the offerer when the offerer is ICE full.
   Since nomination is done by sending a connectivity check (with the
   nomination flag set) which requires the password provided in the SDP
   answer, no pair gets nominated at the answerer and no media is sent
   before the SDP answer has arrived at the offerer.

   If the offerer is ICE lite or if multiplexing is used (i.e. all media
   streams are sent over a single ICE candidate pair) and an additional
   media stream is added later in time via an updated offer, then the
   problem with early media could arise when SDES is used (but never
   with DTLS-SRTP).

3.  Security Considerations

   At this point most readers should agree that SDES is favourable from
   an interworking point of view.  It is also clear that implementing
   SDES in WebRTC is a relatively straight forward task.  What remains
   to be considered are its impacts on security.

   We distinguish between the following two types of attackers:

   Outside Attacker    An external party attempts to intercept a call
                       (e.g. a host located on the same WLAN as the

   Inside Attacker     The web application itself (or the signaling
                       server, in case the web server and signaling
                       server are separated) attempts to intercept a

3.1.  SDES in case of an Outside Attacker

   By requiring that signaling is secured using TLS, an outside attacker
   that monitors network traffic will not be able to extract the SDES
   keys.  Therefore, in this scenario both SDES and DTLS-SRTP provide a
   sufficient level of protection.

Ohlsson                 Expires February 21, 2013               [Page 5]
Internet-Draft          Support of SDES in WebRTC            August 2012

   The two other types of attacks that have been mentioned in this
   context are extraction of log data and code injection, each of which
   are considered below.

3.1.1.  Extraction of Log Data

   In this scenario the attacker manages to decrypt a previously
   recorded call by attacking the signaling server and extracting the
   SDES keys from the server log.

   First of all, if the attacker gets as far as reading the logging data
   then eavesdropping of past calls is probably not the only problem.
   The effort required to break into the server is also related to the
   amount of trust the user assigns to the web application: well trusted
   sites often have well protected servers.

   Secondly, it can be questioned how common this type of extensive
   logging really is.  Storing passwords and other sensitive information
   in log files is an implementation mistake that can easily be avoided.

   Finally, SDES will primarily be used when interworking with existing
   SIP systems deployed within enterprises or service providers.  These
   have been using SDES for a long time and know that it is critical to
   protect the plain text keys.

3.1.2.  Script Injection

   In this scenario the attacker manages to inject his own piece of
   JavaScript into the WebRTC application.  The next time a user
   downloads the application and places a call, the script will execute
   and start eavesdropping on the conversation.

   There are three major ways in which code can be injected into a web

   o  The page itself or one of its included JavaScript files is
      downloaded over a non-HTTPS link and is modified en route

   o  The web application intentionally includes JavaScript supplied by
      the attacker (e.g. a third-party library or advertisement)

   o  HTML form input or URL parameters are not properly sanitized (i.e.
      classical XSS vulnerability)

   Modification en route is prevented by requiring HTTPS to be used for
   all content.  Whether the two other injection techniques are feasible
   or not largely depends on the application.

Ohlsson                 Expires February 21, 2013               [Page 6]
Internet-Draft          Support of SDES in WebRTC            August 2012

   If script injection occurs then there are other methods to intercept
   a call, like establishing additional PeerConnection objects or use a
   recording interface and send the data using WebSocket.  As long as
   these methods are available it does not matter much whether the
   application uses SDES or DTLS-SRTP.

   In general, if an attacker manages to execute even a small piece of
   JavaScript then he has effectively gained full control of the
   application (additional code can be included and HTML elements
   removed/inserted).  Since this situation is exactly the same as the
   situation with an inside attacker, script injection will not be
   discussed further.

3.2.  SDES in case of an Inside Attacker

   First of all, it can be questioned if we really want to protect
   ourselves against an inside attacker.  If consent is required every
   time the application wants to record or forward media then the user
   experience will suffer.  One could also imagine future applications
   that want to use their own codecs or filters (for example a voice
   scrambler or face detection software), something which is difficult
   to achieve without access to the underlying bitstreams.

   We ignore this problem for now and simply assume that the application
   cannot access the media from within the browser.  In other words, we
   only consider protection of the media during transport.

3.2.1.  Downgrade Attack

   The major argument against SDES is that it would make it trivial for
   the application to perform interception.  Let us compare what would
   be required in both cases.

   Interception of SDES call:

   1.  Copy and store the 'a=crypto:' lines in the offer/answer SDP

   2.  Force media to pass through TURN server by deleting all
       candidates except the relayed one

   3.  Store all SRTP packets that pass through the TURN server and
       decrypt them later on (using the keys from step 1)

   Interception of DTLS-SRTP call:

   1.  Replace the 'a=fingerprint:' lines in the offer/answer SDP with
       the fingerprint of a public key generated by the application

Ohlsson                 Expires February 21, 2013               [Page 7]
Internet-Draft          Support of SDES in WebRTC            August 2012

   2.  Force the media to go through the TURN server by deleting all ICE
       candidates except the relayed one

   3.  Modify an existing TURN server implementation so that it decrypts
       and re-encrypts the DTLS traffic (using the public-private key
       pair from step 1)

   Putting the modified TURN server into place is the hardest part of
   intercepting a DTLS-SRTP call.  Once this is done however, the
   remaining steps are fairly straightforward.  This shows that neither
   DTLS-SRTP nor SDES provides any significant protection against an
   inside attacker.

   There is one benefit of DTLS-SRTP that is not directly apparent from
   the above description.  If both users read their respective
   fingerprint values over the voice channel then they can detect if the
   conversation is being intercepted.  However, it is very unlikely that
   the average user would bother doing this.

3.2.2.  Difficulties with Key Continuity

   The comparison in the previous section is somewhat simplified since
   it does not consider DTLS-SRTP key continuity.  The way this
   mechanism works is that the browser will notify the user whenever it
   receives a certificate which has not previously been seen (i.e. not
   present in the browser cache).  Since the user will receive this
   notification every time he calls someone new and whenever someone
   changes browser, it is very likely that he/she will simply ignore it.

   Reuse of public keys also has privacy implications as it enables user
   tracking.  A user that wants to remain anonymous towards a service
   provider would need to generate a fresh key for each interaction.
   Furthermore, in order to avoid colluding service providers (e.g.
   medical clinics and insurance agencies) from linking a user's
   activities, separate certificates are needed for different domains.
   However, storing domain names together with the certificates might
   allow the next browser user (e.g. a family member) to see which sites
   the previous user visited.  All of this leads to more certificates
   being generated which in turn results in even more "new key"

   It is also important to understand that the cached certificates are
   not bound to any identity (the certificates are simple containers for
   the public key without any additional information).  This means that
   if just one of the cached keys is compromised any user call can be
   intercepted without causing the "new key" notification to be
   displayed.  Note that the risk of this happening is directly related
   to the size of the cache, which grows over time.

Ohlsson                 Expires February 21, 2013               [Page 8]
Internet-Draft          Support of SDES in WebRTC            August 2012

3.2.3.  3rd Party Identity Assertion

   [I-D.rescorla-rtcweb-generic-idp] suggests a way to strengthen the
   security of DTLS-SRTP by validating the received fingerprint via an
   identity provider.  At the time of writing there are still some
   details missing from the proposal (for example, it is not clear how
   the identity provider is selected in practice or how the peer
   identity is displayed to the user) but it definitely seems promising.
   Such a mechanism (including the necessary browser chrome) would make
   it significantly harder for the application to act as man-in-the-

   The question is whether the identity mechanism is optional or not,
   i.e. will it be possible for an application to use "plain" DTLS-SRTP.
   The answer is most likely "yes" due to the following reasons:

   o  Many applications are already trusted by the user

   o  Some applications do not want to depend on third parties

   o  Some users do not have any identity provider account

   o  Users may not always want to reveal their identity

   o  Working out all the details of the identity mechanism will take
      time (and if it is not mandatory from start there are backward
      compatibility issues)

   Note that allowing an application to be its own identity provider is
   effectively the same as allowing plain DTLS-SRTP (the user trusts the
   application) only more complicated.

4.  Discussion and Conclusion

   We are not looking to replace DTLS-SRTP with SDES.  The 20-line
   WebRTC developer will continue to use the default option which is
   DTLS-SRTP, while others who are interested in interworking will
   select SDES.  The latter group will be required to use HTTPS for all
   content and can be informed of the necessary precautions (secure
   storage of log files or otherwise no extensive logging).

   The main issue that appears to concern members is the application's
   ability to downgrade security.  But as we have seen it is not
   significantly harder for the application to attack DTLS-SRTP.  The
   main advantage of DTLS-SRTP is the possibility to detect when a call
   is being intercepted.  However, doing so requires an effort from the
   user and a certain degree of technical skill.

Ohlsson                 Expires February 21, 2013               [Page 9]
Internet-Draft          Support of SDES in WebRTC            August 2012

   It has been suggested that additional identity mechanisms could
   prevent the application from listening in on calls.  While this is
   certainly true, any such mechanism would most likely be made
   optional.  If that is the case or if an application can be its own
   identity provider, then we are back at the situation where the user
   has to decide which sites to trust.

   It can also be questioned to what extent the application should be
   restricted from accessing media since this limits usability and
   innovativity.  The W3C would need to update its specifications and
   ensure that a web application cannot record or forward a MediaStream
   without permission from the user.

5.  Informative References

              3GPP, "IP Multimedia Subsystem (IMS) media plane
              security", 3GPP TS 33.328 9.3.0, December 2010,

              McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
              Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
              (work in progress), July 2012.

              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-04 (work
              in progress), June 2012.

              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements",
              draft-ietf-rtcweb-use-cases-and-requirements-09 (work in
              progress), June 2012.

              Kaplan, H., "Requirements for Interworking WebRTC with
              Current SIP Deployments",
              draft-kaplan-rtcweb-sip-interworking-requirements-02 (work
              in progress), November 2011.

              Rescorla, E., "RTCWEB Generic Identity Provider
              Interface", draft-rescorla-rtcweb-generic-idp-01 (work in
              progress), March 2012.

Ohlsson                 Expires February 21, 2013              [Page 10]
Internet-Draft          Support of SDES in WebRTC            August 2012

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [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.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

   [SIPit]    "SIPit27 Summary",

Author's Address

   Oscar Ohlsson
   Farogatan 6
   SE-164 80 Kista


Ohlsson                 Expires February 21, 2013              [Page 11]