idnits 2.17.1
draft-johnston-rtcweb-zrtp-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (August 22, 2013) is 3899 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-13) exists of
draft-ietf-rtcweb-data-channel-05
== Outdated reference: A later version (-19) exists of
draft-ietf-rtcweb-overview-07
== Outdated reference: A later version (-12) exists of
draft-ietf-rtcweb-security-05
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force A. Johnston
3 Internet-Draft Avaya
4 Intended status: Informational P. Zimmermann
5 Expires: February 23, 2014 J. Callas
6 Silent Circle
7 T. Cross
8 OfficeTone
9 J. Yoakum
10 Avaya
11 August 22, 2013
13 Using ZRTP to Secure WebRTC
14 draft-johnston-rtcweb-zrtp-00
16 Abstract
18 WebRTC, Web Real-Time Communications, is a set of protocols and APIs
19 used to enable web developers to add real-time communications into
20 their web pages and applications with a few lines of JavaScript.
21 WebRTC media flows are encrypted and authenticated by SRTP, the
22 Secure Real-time Transport Protocol while the key agreement is
23 provided by DTLS-SRTP, Datagram Transport Layer Security for Secure
24 Real-time Transport Protocol. However, without some third party
25 identity service or certificate authority, WebRTC media flows have no
26 protection against a man-in-the-middle (MitM) attack. ZRTP, Media
27 Path Key Agreement for Unicast Secure RTP, RFC 6189, does provide
28 protection against MitM attackers using key continuity augmented with
29 a Short Authentication String (SAS). This specification describes
30 how ZRTP can be used over the WebRTC data channel to provide MitM
31 protection for WebRTC media flows keyed using DTLS-SRTP. This
32 provides users protection against MitM attackers without requiring
33 browsers to support ZRTP or users to download a plugin or extension
34 to implement ZRTP.
36 Status of this Memo
38 This Internet-Draft is submitted in full conformance with the
39 provisions of BCP 78 and BCP 79.
41 Internet-Drafts are working documents of the Internet Engineering
42 Task Force (IETF). Note that other groups may also distribute
43 working documents as Internet-Drafts. The list of current Internet-
44 Drafts is at http://datatracker.ietf.org/drafts/current/.
46 Internet-Drafts are draft documents valid for a maximum of six months
47 and may be updated, replaced, or obsoleted by other documents at any
48 time. It is inappropriate to use Internet-Drafts as reference
49 material or to cite them other than as "work in progress."
51 This Internet-Draft will expire on February 23, 2014.
53 Copyright Notice
55 Copyright (c) 2013 IETF Trust and the persons identified as the
56 document authors. All rights reserved.
58 This document is subject to BCP 78 and the IETF Trust's Legal
59 Provisions Relating to IETF Documents
60 (http://trustee.ietf.org/license-info) in effect on the date of
61 publication of this document. Please review these documents
62 carefully, as they describe your rights and restrictions with respect
63 to this document. Code Components extracted from this document must
64 include Simplified BSD License text as described in Section 4.e of
65 the Trust Legal Provisions and are provided without warranty as
66 described in the Simplified BSD License.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 5
72 2. ZRTP over a WebRTC Data Channel . . . . . . . . . . . . . . . . 5
73 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
74 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
75 5. Informative References . . . . . . . . . . . . . . . . . . . . 9
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
78 1. Introduction
80 WebRTC, Web Real-Time Communications, adds real-time, interactive
81 voice and video media capabilities to browsers
82 [I-D.ietf-rtcweb-overview] without a plugin or download, and allows
83 web developers to access this functionality using JavaScript API
84 calls [WebRTC-API]. For a complete description of WebRTC protocols
85 and APIs see [WebRTC-Book]. In addition, WebRTC supports the
86 establishment of a peer-to-peer data channel between browsers
87 [I-D.ietf-rtcweb-data-channel]. This document describes how ZRTP,
88 Media Path Key Agreement for Unicast Secure RTP, [RFC6189], can be
89 used over the WebRTC data channel to secure voice and video sessions
90 established using WebRTC.
92 The security of voice and video media sessions established using
93 WebRTC is described in [I-D.ietf-rtcweb-security]. All media
94 sessions utilize SRTP encryption and authentication, which relies on
95 DTLS-SRTP for key management. DTLS-SRTP can utilize TLS modes
96 offering perfect forward secrecy (PFS), but relies on the exchange of
97 fingerprints for protection against Man-in-the-Middle (MitM) attacks
98 [RFC5763]. A mechanism for utilizing trusted third parties, known as
99 Identity Providers, to authenticate the fingerprint is also
100 described. ZRTP always offers perfect forward secrecy, and protects
101 against MitM attacks with key continuity, Short Authentication
102 Strings (SAS), and optionally and additionally, with long-term
103 signing keys or shared secrets. For subsequent calls between the
104 same ZRTP endpoints, a hash of previous keying material is mixed in
105 when generating the current keying material. In addition, the SAS
106 can be used to confirm the absence of a MitM attack over the entire
107 lifetime of the key continuity (going both backwards and forwards in
108 time). Both parties in the communication must have ZRTP software,
109 which performs a DH key agreement and are capable of storing a cache
110 of previous shared secrets and rendering the SAS to the users. The
111 human users then have the option to compare the SAS's to see if they
112 match to confirm the absence of a MitM attacker. This could be done
113 by verbally reading aloud the string (which can be two words or four
114 hex characters), or otherwise exchanging them. If the SAS values
115 match, then there is no MitM attacker. ZRTP is signaling channel and
116 protocol independent, and does not rely on ANY third party services
117 for authentication (though it can optionally and additionally
118 leverage a public key infrastructure (PKI)). As such, ZRTP has been
119 used with SIP, Jingle, and proprietary signaled VoIP systems. There
120 are a number of open source ZRTP stacks and commercial
121 implementations and products. For the reasons why ZRTP is a good fit
122 for WebRTC, see [I-D.johnston-rtcweb-media-privacy].
124 ZRTP is not currently built into the browser like DTLS-SRTP.
125 However, this doesn't mean that ZRTP cannot be used with WebRTC.
127 ZRTP can be implemented in JavaScript and run over the WebRTC data
128 channel between the browsers. The format and message flow can be
129 identical to RFC 6189, with the exception that instead of ZRTP
130 running on UDP, it runs on top of SCTP/DTLS/UDP. A small change in
131 the policy usage of the ZRTP auxsecret provides MitM protection for
132 media sessions established by WebRTC between the browsers.
134 This allows the ZRTP SAS to be used to authenticate WebRTC media
135 sessions for WebRTC applications that include ZRTP JavaScript. Also,
136 since the ZRTP data channel can be used to authenticate all WebRTC
137 Peer Connections between a pair of browsers, a ZRTP WebRTC
138 application could be used to authenticate and protect other WebRTC
139 sessions that do not even use ZRTP. For example, users of a
140 particular WebRTC service which claims to offer end-to-end media
141 privacy could use a ZRTP-enabled WebRTC application in another tab or
142 window to verify that assertion or audit the service and protect
143 against MitM attacks.
145 1.1. Requirements Language
147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
149 document are to be interpreted as described in RFC 2119 [RFC2119].
151 2. ZRTP over a WebRTC Data Channel
153 In the base ZRTP protocol [RFC6189], ZRTP uses UDP transport,
154 multiplexed over the same port as the media session that it is
155 keying. ZRTP over a WebRTC data channel means that ZRTP messages are
156 sent over the SCTP/DTLS/UDP protocol stack. It is RECOMMENDED that
157 SCTP reliability be used so that the ZRTP timer and retransmissions
158 in Section 6 of [RFC6189] are not needed. The state machine is
159 identical, with the exchange beginning with the Hello and ending with
160 the ConfACK. The ZRTP Hello Hash MAY be exchanged over the WebRTC
161 signaling channel. The ZID MAY be statelessly generated by hashing
162 the DTLS-SRTP fingerprint of the browser. Also, the ZRTP cache of
163 previous shared secrets can be stored in a number of ways, including
164 indexed database, HTML5 file system, or even as a cookie.
166 In order to provide protection against a MitM attack of WebRTC media
167 sessions, ZRTP needs to:
169 o Verify that both browsers see the same local and remote
170 fingerprint used by DTLS-SRTP. This is accomplished by always
171 including the DTLS-SRTP fingerprints in the ZRTP auxsecret.
173 o Verify that there is no MitM attack against ZRTP. This is
174 accomplished by the various mechanisms ZRTP provides, including
175 key continuity and human users comparing the SAS.
177 The ZRTP auxsecret is defined in Section 4.3 of [RFC6189]. This
178 specification defines the following new policies relating to the
179 usage of auxsecret when ZRTP is used to secure DTLS-SRTP media
180 sessions.
182 The auxsecret MUST be used. The auxsecret is truncated to the
183 negotiated hash length (defined in Section 4.5.1 of [RFC6189]) of:
185 auxsecret = hash(initiator's DTLS-SRTP fingerprint ||
186 responder's DTLS-SRTP fingerprint ||
187 original_auxsecret)
189 The original_auxsecret is any auxsecret value that would otherwise
190 have been used with ZRTP, or the null string if no such value exists
191 as will ordinarily be the case.
193 Note that this auxsecret is actually not a secret, since the
194 fingerprints are hashes of known public keys used by the browsers.
195 This does not affect the security of ZRTP.
197 If the auxsecrets of the initiator and responder do not match, this
198 MUST be treated as a MitM attack. This is to protect against the
199 case where the DTLS-SRTP session has an MitM attacker but the ZRTP
200 session does not. Note that this can be done as soon as the DHPart1
201 and DHPart2 messages have been exchanged and can be done
202 automatically without calculating or comparing the SAS.
204 Any failure in the ZRTP exchange MUST be treated as a MitM attack.
206 Detection of a MitM attack MUST result in the closure of the DTLS-
207 SRTP sessions and alerting the browser users.
209 If the users successfully compare the SAS strings, it means that
210 neither the DTLS nor the ZRTP sessions have MitM attackers. Any
211 media sessions which were established using this same pair of local
212 and remote fingerprints also do not have MitM attackers, regardless
213 of which browser tab or window they are present in.
215 This specification requires DTLS to use a Forward Secrecy (FS) mode.
216 If a FS mode is not available, the DTLS connection MUST fail.
218 3. IANA Considerations
220 This memo includes no request to IANA.
222 4. Security Considerations
224 For the security analysis of this approach, consider a pair of
225 browsers, used by Alice and Bob which have established at a minimum a
226 voice media session and a ZRTP data channel. There are two
227 possibilities:
229 o Both the media and data run over the same DTLS connection, or
231 o The media and data run over separate DTLS connections.
233 As such, an attacker could choose to attack any combination of these
234 connections and the DTLS and/or ZRTP protocols. However, note that
235 since ZRTP runs on top of DTLS, it is not possible to MitM ZRTP
236 without first launching a MitM attack on the DTLS connection over
237 which it runs. In the following analysis, "attacking the media
238 channel" means a MitM attack launched against the DTLS session used
239 to establish the voice media session, and "attacking the data
240 channel" means a MitM attack against ZRTP and the DTLS session over
241 which ZRTP runs.
243 Given these two possibilities, the attacker could choose to attack:
245 o Both the media and data channel,
247 o Just the media channel,
249 o Just the data channel, or
251 o Neither media or data channel.
253 These will be considered in turn. Note that a MitM attack launched
254 against DTLS-SRTP will result in the remote fingerprint as seen by
255 each browser to be that of the attacker instead of the other browser.
257 If the MitM attacks both the media and the data channel, the SAS as
258 computed by each browser will be different, and the users can detect
259 this by verbally comparing the SAS. Additionally, if the users have
260 communicated before without a MitM attacker, the presence of the MitM
261 will create a break in key continuity and the users will be alerted
262 that they should verify the SAS.
264 If the MitM attacks just the media channel, after the exchange of
265 DHPart1 and DHPart2 messages, the different fingerprints will be
266 detected by checking the hashed auxsecret values and discovering that
267 they do not match. The MitM attack is immediately and automatically
268 detected.
270 If the MitM attacks just the data channel, the SAS as computed by
271 each browser will be different as two independent DH exchanges
272 occurred. If the users have spoken before, the MitM will cause a
273 break in key continuity. In any case, the MitM will be definitively
274 detected by comparing ZRTP's SAS. Note that it doesn't make much
275 sense for the MitM to attack just the data channel, but this could
276 happen.
278 If the MitM attacks neither the media nor the data channel, the
279 auxsecrets will match, the SAS as computed by each browser will be
280 the same, and key continuity will be maintained. As a result, both
281 the ZRTP and media session are free of MitM attackers.
283 Note that only in one scenario does this approach rely on the users
284 comparing the SAS -- and even there, the users would likely be
285 protected by key continuity even if the SAS were not manually
286 checked. Also, note that all these attacks rely on the attacker
287 being able to insert herself in the path as a MitM. For the scenario
288 in which the media channel and data channel use different DTLS
289 connections, it could be potentially difficult for the attacker to
290 insert herself as a MitM in the data channel as it could take a
291 complete different route over the Internet from the media channel.
292 For example, the data channel used by ZRTP could be deliberately
293 routed over a different IP connection or via a TURN server forcing a
294 different path that may not accessible to the attacker.
296 In summary, this approach can be thought of as having three distinct
297 layers. The first layer is the DTLS session, which protects against
298 passive attacks but has no protection against a MitM attack without a
299 third party service. The next layer is the ZRTP session, which
300 allows the fingerprints to be exchanged and compared. A fingerprint
301 mismatch allows a MitM attack on DTLS to be detected. The third
302 layer is ZRTP and its protections against a MitM: short
303 authentication strings, key continuity, and optional SAS signing with
304 a PKI. These protections are cumulative -- even over time. Because
305 of key continuity, a single comparison of the SAS guarantees that no
306 MitM has attacked past sessions and cannot attack future sessions.
307 And even if the SAS is not compared, key continuity ensures that for
308 a MitM attacker to remain undetected, she must attack each session
309 between the users without exception.
311 5. Informative References
313 [I-D.ietf-rtcweb-data-channel]
314 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data
315 Channels", draft-ietf-rtcweb-data-channel-05 (work in
316 progress), July 2013.
318 [I-D.ietf-rtcweb-overview]
319 Alvestrand, H., "Overview: Real Time Protocols for Brower-
320 based Applications", draft-ietf-rtcweb-overview-07 (work
321 in progress), August 2013.
323 [I-D.ietf-rtcweb-security]
324 Rescorla, E., "Security Considerations for WebRTC",
325 draft-ietf-rtcweb-security-05 (work in progress),
326 July 2013.
328 [I-D.johnston-rtcweb-media-privacy]
329 Johnston, A. and P. Zimmermann, "RTCWEB Media Privacy",
330 draft-johnston-rtcweb-media-privacy-00 (work in progress),
331 May 2011.
333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
334 Requirement Levels", BCP 14, RFC 2119, March 1997.
336 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
337 for Establishing a Secure Real-time Transport Protocol
338 (SRTP) Security Context Using Datagram Transport Layer
339 Security (DTLS)", RFC 5763, May 2010.
341 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
342 Path Key Agreement for Unicast Secure RTP", RFC 6189,
343 April 2011.
345 [WebRTC-API]
346 Bergkvist, A., Burnett, D., Jennings, C., and A.
347 Narayanan, "WebRTC 1.0: Real-time Communication Between
348 Browsers", W3C Working Draft http://www.w3.org/TR/webrtc/,
349 2013, .
351 [WebRTC-Book]
352 Johnston, A. and D. Burnett, "WebRTC: APIs and RTCWEB
353 Protocols of the HTML5 Real-Time Web", Digital Codex LLC,
354 2013, .
356 Authors' Addresses
358 Alan Johnston
359 Avaya
360 St. Louis, MO
361 USA
363 Phone:
364 Email: alan.b.johnston@gmail.com
366 Phil Zimmermann
367 Silent Circle
368 Santa Cruz, CA
369 USA
371 Phone:
372 Email: prz@mit.edu
374 Jon Callas
375 Silent Circle
377 Phone:
378 Email: jon@callas.org
380 Travis Cross
381 OfficeTone
383 Phone:
384 Email: tc@traviscross.com
386 John Yoakum
387 Avaya
388 Cary, NC
389 USA
391 Phone:
392 Email: yoakum@avaya.com