draft-ietf-rtcweb-security-06.txt   draft-ietf-rtcweb-security-07.txt 
RTC-Web E. Rescorla RTC-Web E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track January 22, 2014 Intended status: Standards Track July 04, 2014
Expires: July 26, 2014 Expires: January 5, 2015
Security Considerations for WebRTC Security Considerations for WebRTC
draft-ietf-rtcweb-security-06 draft-ietf-rtcweb-security-07
Abstract Abstract
The Real-Time Communications on the Web (RTCWEB) working group is The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC". The major use cases between Web browsers, generally called "WebRTC". The major use cases
for WebRTC technology are real-time audio and/or video calls, Web for WebRTC technology are real-time audio and/or video calls, Web
conferencing, and direct data transfer. Unlike most conventional conferencing, and direct data transfer. Unlike most conventional
real-time systems (e.g., SIP-based soft phones) WebRTC communications real-time systems (e.g., SIP-based soft phones) WebRTC communications
are directly controlled by a Web server, which poses new security are directly controlled by a Web server, which poses new security
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
4. Security for WebRTC Applications . . . . . . . . . . . . . . . 7 4. Security for WebRTC Applications . . . . . . . . . . . . . . . 7
4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 8 4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 8
4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 9 4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 9
4.1.2. Calling Scenarios and User Expectations . . . . . . . 9 4.1.2. Calling Scenarios and User Expectations . . . . . . . 9
4.1.2.1. Dedicated Calling Services . . . . . . . . . . . . 9 4.1.2.1. Dedicated Calling Services . . . . . . . . . . . . 9
4.1.2.2. Calling the Site You're On . . . . . . . . . . . . 10 4.1.2.2. Calling the Site You're On . . . . . . . . . . . . 10
4.1.3. Origin-Based Security . . . . . . . . . . . . . . . . 10 4.1.3. Origin-Based Security . . . . . . . . . . . . . . . . 10
4.1.4. Security Properties of the Calling Page . . . . . . . 12 4.1.4. Security Properties of the Calling Page . . . . . . . 12
4.2. Communications Consent Verification . . . . . . . . . . . 13 4.2. Communications Consent Verification . . . . . . . . . . . 13
4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Backward Compatibility . . . . . . . . . . . . . . . . 14 4.2.3. Backward Compatibility . . . . . . . . . . . . . . . . 14
4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15 4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15
4.3. Communications Security . . . . . . . . . . . . . . . . . 15 4.3. Communications Security . . . . . . . . . . . . . . . . . 16
4.3.1. Protecting Against Retrospective Compromise . . . . . 16 4.3.1. Protecting Against Retrospective Compromise . . . . . 17
4.3.2. Protecting Against During-Call Attack . . . . . . . . 17 4.3.2. Protecting Against During-Call Attack . . . . . . . . 17
4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . . 17 4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . . 18
4.3.2.2. Short Authentication Strings . . . . . . . . . . . 18 4.3.2.2. Short Authentication Strings . . . . . . . . . . . 18
4.3.2.3. Third Party Identity . . . . . . . . . . . . . . . 19 4.3.2.3. Third Party Identity . . . . . . . . . . . . . . . 19
4.3.2.4. Page Access to Media . . . . . . . . . . . . . . . 19 4.3.2.4. Page Access to Media . . . . . . . . . . . . . . . 20
4.3.3. Malicious Peers . . . . . . . . . . . . . . . . . . . 20 4.3.3. Malicious Peers . . . . . . . . . . . . . . . . . . . 20
4.4. Privacy Considerations . . . . . . . . . . . . . . . . . . 20 4.4. Privacy Considerations . . . . . . . . . . . . . . . . . . 21
4.4.1. Correlation of Anonymous Calls . . . . . . . . . . . . 20 4.4.1. Correlation of Anonymous Calls . . . . . . . . . . . . 21
4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . . 21 4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21 7. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Real-Time Communications on the Web (RTCWEB) working group is The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC" between Web browsers, generally called "WebRTC"
[I-D.ietf-rtcweb-overview]. The major use cases for WebTC technology [I-D.ietf-rtcweb-overview]. The major use cases for WebTC technology
are real-time audio and/or video calls, Web conferencing, and direct are real-time audio and/or video calls, Web conferencing, and direct
data transfer. Unlike most conventional real-time systems, (e.g., data transfer. Unlike most conventional real-time systems, (e.g.,
SIP-based[RFC3261] soft phones) WebRTC communications are directly SIP-based[RFC3261] soft phones) WebRTC communications are directly
skipping to change at page 13, line 18 skipping to change at page 13, line 18
network access via the browser introduces the risk of using the network access via the browser introduces the risk of using the
browser as an attack platform against machines which would not browser as an attack platform against machines which would not
otherwise be accessible to the malicious site, for instance because otherwise be accessible to the malicious site, for instance because
they are topologically restricted (e.g., behind a firewall or NAT). they are topologically restricted (e.g., behind a firewall or NAT).
In order to prevent this form of attack as well as cross-protocol In order to prevent this form of attack as well as cross-protocol
attacks it is important to require that the target of traffic attacks it is important to require that the target of traffic
explicitly consent to receiving the traffic in question. Until that explicitly consent to receiving the traffic in question. Until that
consent has been verified for a given endpoint, traffic other than consent has been verified for a given endpoint, traffic other than
the consent handshake MUST NOT be sent to that endpoint. the consent handshake MUST NOT be sent to that endpoint.
Note that consent verification is not sufficient to prevent overuse
of network resources. Because WebRTC allows for a Web site to create
data flows between two browser instances without user consent, it is
possible for a malicious site to chew up a signficant amount of a
user's bandwidth without incurring significant costs to himself by
setting up such a channel to another user. However, as a practical
matter there are a large number of Web sites which can act as data
sources, so an attacker can at least use downlink bandwidth with
existing Web APIs. However, this potential DoS vector reinforces the
need for adequate congestion control for WebRTC protocols to ensure
that they play fair with other demands on the user's bandwidth.
4.2.1. ICE 4.2.1. ICE
Verifying receiver consent requires some sort of explicit handshake, Verifying receiver consent requires some sort of explicit handshake,
but conveniently we already need one in order to do NAT hole- but conveniently we already need one in order to do NAT hole-
punching. ICE [RFC5245] includes a handshake designed to verify that punching. ICE [RFC5245] includes a handshake designed to verify that
the receiving element wishes to receive traffic from the sender. It the receiving element wishes to receive traffic from the sender. It
is important to remember here that the site initiating ICE is is important to remember here that the site initiating ICE is
presumed malicious; in order for the handshake to be secure the presumed malicious; in order for the handshake to be secure the
receiving element MUST demonstrate receipt/knowledge of some value receiving element MUST demonstrate receipt/knowledge of some value
not available to the site (thus preventing the site from forging not available to the site (thus preventing the site from forging
skipping to change at page 13, line 42 skipping to change at page 14, line 5
to receive traffic from a particular sender, and at this time; for to receive traffic from a particular sender, and at this time; for
example a malicious site may simply attempt ICE to known servers that example a malicious site may simply attempt ICE to known servers that
are using ICE for other sessions. ICE provides this verification as are using ICE for other sessions. ICE provides this verification as
well, by using the STUN credentials as a form of per-session shared well, by using the STUN credentials as a form of per-session shared
secret. Those credentials are known to the Web application, but secret. Those credentials are known to the Web application, but
would need to also be known and used by the STUN-receiving element to would need to also be known and used by the STUN-receiving element to
be useful. be useful.
There also needs to be some mechanism for the browser to verify that There also needs to be some mechanism for the browser to verify that
the target of the traffic continues to wish to receive it. Because the target of the traffic continues to wish to receive it. Because
ICE keepalives are indications, they will not work here, so some ICE keepalives are indications, they will not work here.
other mechanism is needed as described in [I-D.ietf-rtcweb-stun-consent-freshness] describes the mechanism for
[I-D.muthu-behave-consent-freshness]. providing consent freshness.
4.2.2. Masking 4.2.2. Masking
Once consent is verified, there still is some concern about Once consent is verified, there still is some concern about
misinterpretation attacks as described by Huang et al.[huang-w2sp]. misinterpretation attacks as described by Huang et al.[huang-w2sp].
Once consent is verified, there still is some concern about
misinterpretation attacks as described by Huang et al.[huang-w2sp].
Where TCP is used the risk is substantial due to the potential Where TCP is used the risk is substantial due to the potential
presence of transparent proxies and therefore if TCP is to be used, presence of transparent proxies and therefore if TCP is to be used,
then WebSockets style masking MUST be employed. then WebSockets style masking MUST be employed.
Since DTLS (with the anti-chosen plaintext mechanisms required by TLS Since DTLS (with the anti-chosen plaintext mechanisms required by TLS
1.1) does not allow the attacker to generate predictable ciphertext, 1.1) does not allow the attacker to generate predictable ciphertext,
there is no need for masking of protocols running over DTLS (e.g. there is no need for masking of protocols running over DTLS (e.g.
SCTP over DTLS, UDP over DTLS, etc.). SCTP over DTLS, UDP over DTLS, etc.).
Note that in principle an attacker could exert some control over SRTP
packets by using a combination of the WebAudio API and extremely
tight timing control. The primary risk here seems to be carriage of
SRTP over TURN TCP. However, as SRTP packets have an extremely
characteristic packet header it seems unlikely that any but the most
aggressive intermediaries would be confused into thinking that
another application layer protocol was in use.
4.2.3. Backward Compatibility 4.2.3. Backward Compatibility
A requirement to use ICE limits compatibility with legacy non-ICE A requirement to use ICE limits compatibility with legacy non-ICE
clients. It seems unsafe to completely remove the requirement for clients. It seems unsafe to completely remove the requirement for
some check. All proposed checks have the common feature that the some check. All proposed checks have the common feature that the
browser sends some message to the candidate traffic recipient and browser sends some message to the candidate traffic recipient and
refuses to send other traffic until that message has been replied to. refuses to send other traffic until that message has been replied to.
The message/reply pair must be generated in such a way that an The message/reply pair must be generated in such a way that an
attacker who controls the Web application cannot forge them, attacker who controls the Web application cannot forge them,
generally by having the message contain some secret value that must generally by having the message contain some secret value that must
skipping to change at page 19, line 7 skipping to change at page 19, line 29
much longer. much longer.
Additionally, it is unclear that users will actually use an SAS. As Additionally, it is unclear that users will actually use an SAS. As
discussed above, the browser UI constraints preclude requiring the discussed above, the browser UI constraints preclude requiring the
SAS exchange prior to completing the call and so it must be SAS exchange prior to completing the call and so it must be
voluntary; at most the browser will provide some UI indicator that voluntary; at most the browser will provide some UI indicator that
the SAS has not yet been checked. However, it it is well-known that the SAS has not yet been checked. However, it it is well-known that
when faced with optional security mechanisms, many users simply when faced with optional security mechanisms, many users simply
ignore them [whitten-johnny]. ignore them [whitten-johnny].
Once uses have checked the SAS once, key continuity is required to Once users have checked the SAS once, key continuity is required to
avoid them needing to check it on every call. However, this is avoid them needing to check it on every call. However, this is
problematic for reasons indicated in Section 4.3.2.1. In principle problematic for reasons indicated in Section 4.3.2.1. In principle
it is of course possible to render a different UI element to indicate it is of course possible to render a different UI element to indicate
that calls are using an unauthenticated set of keying material that calls are using an unauthenticated set of keying material
(recall that the attacker can just present a slightly different name (recall that the attacker can just present a slightly different name
so that the attack shows the same UI as a call to a new device or to so that the attack shows the same UI as a call to a new device or to
someone you haven't called before) but as a practical matter, users someone you haven't called before) but as a practical matter, users
simply ignore such indicators even in the rather more dire case of simply ignore such indicators even in the rather more dire case of
mixed content warnings. mixed content warnings.
skipping to change at page 21, line 21 skipping to change at page 21, line 43
incremental fingerprint risk. incremental fingerprint risk.
5. Security Considerations 5. Security Considerations
This entire document is about security. This entire document is about security.
6. Acknowledgements 6. Acknowledgements
Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan
Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman, Martin Thomson, Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman, Martin Thomson,
Magnus Westerland. Magnus Westerlund.
7. Changes Since -04 7. Changes Since -04
o Replaced RTCWEB and RTC-Web with WebRTC, except when referring to o Replaced RTCWEB and RTC-Web with WebRTC, except when referring to
the IETF WG the IETF WG
o Removed discussion of the IFRAMEd advertisement case, since we o Removed discussion of the IFRAMEd advertisement case, since we
decided not to treat it specially. decided not to treat it specially.
o Added a privacy section considerations section. o Added a privacy section considerations section.
o Significant edits to the SAS section to reflect Alan Johnston's o Significant edits to the SAS section to reflect Alan Johnston's
comments. comments.
o Added some discussion if IP location privacy and Tor. o Added some discussion if IP location privacy and Tor.
o Updated the "communications consent" section to reflrect draft- o Updated the "communications consent" section to reflrect draft-
muthu. ietf.
o Added a section about "malicious peers". o Added a section about "malicious peers".
o Added a section describing screen sharing threats. o Added a section describing screen sharing threats.
o Assorted editorial changes. o Assorted editorial changes.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for
based Applications", draft-ietf-rtcweb-overview-08 (work Browser-based Applications", draft-ietf-rtcweb-overview-10
in progress), September 2013. (work in progress), June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing". [CORS] van Kesteren, A., "Cross-Origin Resource Sharing".
[I-D.ietf-avtcore-6222bis] [I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), July 2013. (work in progress), July 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", Rescorla, E., "WebRTC Security Architecture",
draft-ietf-rtcweb-security-arch-07 (work in progress), draft-ietf-rtcweb-security-arch-09 (work in progress),
July 2013. February 2014.
[I-D.ietf-rtcweb-stun-consent-freshness]
Perumal, M., Wing, D., R, R., Reddy, T., and M. Thomson,
"STUN Usage for Consent Freshness",
draft-ietf-rtcweb-stun-consent-freshness-04 (work in
progress), June 2014.
[I-D.kaufman-rtcweb-security-ui] [I-D.kaufman-rtcweb-security-ui]
Kaufman, M., "Client Security User Interface Requirements Kaufman, M., "Client Security User Interface Requirements
for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
progress), June 2011. progress), June 2011.
[I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
for Consent Freshness",
draft-muthu-behave-consent-freshness-04 (work in
progress), July 2013.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
 End of changes. 21 change blocks. 
33 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/