One document matched: draft-johnston-rtcweb-media-privacy-00.txt

Network Working Group                                        A. Johnston
Internet-Draft                                                     Avaya
Intended status: Standards Track                           P. Zimmermann
Expires: December 2, 2011                                  Zfone Project
                                                            May 31, 2011


                          RTCWEB Media Privacy
                 draft-johnston-rtcweb-media-privacy-00

Abstract

   RTCWEB is the joint effort between the IETF and the W3C to add real-
   time voice, video, and communication capabilities to browsers.  This
   document looks at the requirements for media privacy and existing
   mechanisms.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 December 2, 2011.

Copyright Notice

   Copyright (c) 2011 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.



Johnston & Zimmermann   Expires December 2, 2011                [Page 1]

Internet-Draft            RTCWEB Media Security                 May 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Media Security Requirements . . . . . . . . . . . . . . . . . . 3
   3.  Security Mechanism Discussion . . . . . . . . . . . . . . . . . 4
   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7










































Johnston & Zimmermann   Expires December 2, 2011                [Page 2]

Internet-Draft            RTCWEB Media Security                 May 2011


1.  Introduction

   The requirements for real-time communications in web browsers or
   RTCWEB are currently being discussed and developed.  For both the
   IETF and the W3C, there are significant challenges due to the unique
   architecture of browsers.

   The same is true for security as well - the requirements are
   evolving, but starting to come into focus.  This draft raises a few
   issues relating to media security and privacy, something the authors
   have spent considerable time and effort thinking, writing, and
   deploying code over the past seven years.


2.  Media Security Requirements

   One possible model for RTCWEB is described in
   [I-D.alvestrand-dispatch-rtcweb-protocols], which is summarized here.
   To implement RTCWEB, both signaling and media is needed.  Media for
   audio and video will likely use RTP [RFC3550], and using some NAT
   traversal/media authorization approach, will ideally go end-to-end
   between the two browsers, bypassing the web server and any
   intermediaries.  ICE [RFC5245] is commonly mentioned as a potential
   protocol for both the NAT traversal method and also for the media
   authorization method.

   Signaling is quite a different story, however.  This approach does
   not standardize any signaling between the browser and the web server.
   Instead, the state machine and capability negotiation abilities will
   be downloaded from the web server into the browser - the same way
   other features and functionality are provided in web apps and pages
   today.  For example, Javascript could be used for this purpose.

   There are two interesting side effects of this.  It means that there
   will be many different signaling protocols used for RTCWEB.  Also, it
   means that will not be any single security or trust model for the
   signaling - it will depend on the web page, the application, and the
   way in which the signaling works.

   Both of these side effects pose significant challenges for media
   security.  The best way to secure RTP streams is to use SRTP
   [RFC3711].  However, SRTP requires a key management protocol.  A key
   management protocol generates and distributes the symmetric secret
   keys to the sender and receiver of the stream.  The simplest SRTP key
   management is to have the SRTP sender generate the key and use the
   signaling channel to send it to the receiver.  However, in order to
   do this, the signaling protocol must meet some security requirements
   relating to confidentiality.  In the RTCWEB architecture, there is no



Johnston & Zimmermann   Expires December 2, 2011                [Page 3]

Internet-Draft            RTCWEB Media Security                 May 2011


   standardization of the signaling protocol possible, and hence this
   approach can not be used.  Another approach which does not rely on
   security properties of the signaling protocol is to use a key
   management system backed by a PKI.  In this way, secret keys can be
   transported by any signaling protocol.  However, this requires public
   private key pairs on every browser, and the infrastructure to manage
   them.

   Instead, what is needed is a key management protocol for SRTP that
   does not place any reliance on the signaling protocol.


3.  Security Mechanism Discussion

   The issues and requirements in the previous section are very
   different from those normally encountered in telephony systems.
   Nearly all key management protocols for SRTP either rely on a PKI-
   backed certificate or place strict requirements and trust on the
   signaling layer.  However, the ZRTP key management protocol [RFC6189]
   does not.  In fact, to read its design principles, one might come to
   the conclusion that it was specifically designed for RTCWEB, despite
   the fact that it predates the RTCWEB effort by five years.

   ZRTP is an entirely self-contained key management protocol for SRTP
   that places no requirements or reliance on the signaling path.  It
   was originally designed as an extension to RTP, but is now a separate
   protocol that runs over the same ports and IP addresses as an RTP
   stream.  Today, ZRTP is used with SIP, Jingle, and even proprietary
   VoIP (Voice over IP) and video systems - the only requirement is that
   they use RTP for media.  This flexibility is something that is simply
   not possible for other key management protocols.  It implements its
   own discovery mechanism, having first applied the concept of "Best
   Effort Encryption" to VoIP as defined in [RFC5479].  It uses an in-
   band Diffie Hellman exchange to generate the secret keying material
   for SRTP.  ZRTP avoids the need for PKI backed certificates by using
   techniques borrowed from SSH and key continuity.

   ZRTP has been widely discussed in the IETF, and has been published by
   the IETF as an informational RFC, to document an existing and
   deployed security model.  Through this process, ZRTP benefited from
   significant review from the IETF and security community.  ZRTP
   inspired other media-path keying protocols such as DTLS/SRTP
   [RFC5764].  However, DTLS-SRTP missed the mark on many of the key
   advantages of ZRTP and has seen little or no deployment or interest
   in the marketplace despite being published as a proposed standard.
   The single most important failure is its reliance on either PKI
   backed endpoint certificates, or on an end-to-end integrity protected
   signaling path.  While there are SIP mechanisms that have been



Johnston & Zimmermann   Expires December 2, 2011                [Page 4]

Internet-Draft            RTCWEB Media Security                 May 2011


   published to implement an end-to-end integrity protected signaling
   path [RFC4474], this approach also has no deployment and no traction
   in the industry.  As discussed earlier, there is way to place any
   requirements on the signaling protocol, let alone one as difficult as
   end-to-end integrity protection.

   In the development of ZRTP, it was realized that there are scenarios
   in which the media can not be encrypted end-to-end.  For example,
   when a client has a trusted server or PBX which provides media
   services in the path.  For these cases, ZRTP developed mechanisms for
   handling a "trusted MiTM" which can terminate than reoriginate the
   SRTP encryption.  This is done without compromising the basic
   security of the protocol, or allowing arbitrary MiTM entities in the
   media path.  With RTCWEB applications, there may be cases where the
   web server application is providing media services and hence needs
   access to the media path.  ZRTP can support these scenarios, allowing
   for a user to explicitly authorize this, while still having all the
   benefits of ZRTP.  ZRTP also handles cases where each endpoint of a
   communications session have a trusted MiTM.  In this case, there will
   actually be three separately encrypted media paths.  These types of
   scenarios could easily be encountered where each user has a trusted
   MiTM web server.

   To take full advantage of ZRTP, a voice path is needed in order for
   users to compare the Short Authentication String (SAS).  However,
   ZRTP still provides security similar to SSH in its key continuity.
   Also, ZRTP normally requires a display for rendering the SAS, but
   this is not an issue for a browser.

   RFC 6189 documents the ZRTP protocol as it is deployed today in VoIP
   systems.  For the RTCWEB application, it is likely that modifications
   and enhancements might need to be made.  It is the hope of the
   authors that these modifications could be done by the working group
   in a way that does not compromise the core principles of ZRTP, and
   also perhaps provides fallback interoperabilty between browsers and
   existing ZRTP VoIP devices and systems.


4.  Summary

   In summary, this draft has discussed some of the unique requirements
   of RTCWEB media security and shown that ZRTP actually meets these.
   In fact, the authors believe that ZRTP is ideally architected for
   providing media security, privacy, and even some identity services
   for RTCWEB.  ZRTP is not perfect, but it has the correct architecture
   that other protocols do not have, and can be adapted to meet the
   needs of the RTCWEB effort.




Johnston & Zimmermann   Expires December 2, 2011                [Page 5]

Internet-Draft            RTCWEB Media Security                 May 2011


5.  Security Considerations

   This whole document is about security.  In the RTCWEB effort, we are
   hoping to provide a browser based real-time communication platform
   that can be trusted and used by Internet users worldwide.  The
   privacy of the browser to browser media path should be our most
   important concern.  Choosing the wrong media security approach will
   hurt users of the Internet and limit the usefulness of the HTML5
   RTCWEB extensions.  It is the hope of the authors that the IETF will
   take this responsibility seriously and give users of RTCWEB the best
   options for media security and privacy.


6.  Informative References

   [I-D.alvestrand-dispatch-rtcweb-protocols]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications",
              draft-alvestrand-dispatch-rtcweb-protocols-01 (work in
              progress), March 2011.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC6189]  Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
              Path Key Agreement for Unicast Secure RTP", RFC 6189,
              April 2011.

   [RFC5479]  Wing, D., Fries, S., Tschofenig, H., and F. Audet,
              "Requirements and Analysis of Media Security Management
              Protocols", RFC 5479, April 2009.

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

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session



Johnston & Zimmermann   Expires December 2, 2011                [Page 6]

Internet-Draft            RTCWEB Media Security                 May 2011


              Initiation Protocol (SIP)", RFC 4474, August 2006.


Authors' Addresses

   Alan Johnston
   Avaya
   St. Louis, MO  63124

   Email: alan.b.johnston@gmail.com


   Philip Zimmermann
   Zfone Project

   Email: prz@mit.edu



































Johnston & Zimmermann   Expires December 2, 2011                [Page 7]