| Network Working Group | A. Johnston |
| Internet-Draft | Avaya |
| Intended status: Standards Track | P. Zimmermann |
| Expires: December 02, 2011 | Zfone Project |
| May 31, 2011 |
RTCWEB Media Privacy
draft-johnston-rtcweb-media-privacy-00
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.
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 02, 2011.
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.
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.
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 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.
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 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.
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.
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.