draft-ietf-rtcweb-security-arch-11.txt   draft-ietf-rtcweb-security-arch-12.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track March 7, 2015 Intended status: Standards Track June 8, 2016
Expires: September 8, 2015 Expires: December 10, 2016
WebRTC Security Architecture WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-11 draft-ietf-rtcweb-security-arch-12
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 enabling real-time tasked with standardizing protocols for enabling real-time
communications within user-agents using web technologies (commonly communications within user-agents using web technologies (commonly
called "WebRTC"). This document defines the security architecture called "WebRTC"). This document defines the security architecture
for WebRTC. for WebRTC.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 8, 2015. This Internet-Draft will expire on December 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 26 skipping to change at page 3, line 26
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Changes since -10 . . . . . . . . . . . . . . . . . . . . 34 9.1. Changes since -10 . . . . . . . . . . . . . . . . . . . . 34
9.2. Changes since -06 . . . . . . . . . . . . . . . . . . . . 34 9.2. Changes since -06 . . . . . . . . . . . . . . . . . . . . 34
9.3. Changes since -05 . . . . . . . . . . . . . . . . . . . . 35 9.3. Changes since -05 . . . . . . . . . . . . . . . . . . . . 35
9.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35 9.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
9.5. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35 9.5. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
9.6. Changes since -02 . . . . . . . . . . . . . . . . . . . . 35 9.6. Changes since -02 . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Example IdP Bindings to Specific Protocols . . . . . 38 Appendix A. Example IdP Bindings to Specific Protocols . . . . . 39
A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 39 A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Real-Time Communications on the Web (WebRTC) working group is The Real-Time Communications on the Web (WebRTC) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers. The major use cases for WebRTC technology are between Web browsers. The major use cases for WebRTC technology are
real-time audio and/or video calls, Web conferencing, and direct data real-time audio and/or video calls, Web conferencing, and direct data
skipping to change at page 16, line 43 skipping to change at page 16, line 43
All media channels MUST be secured via SRTP. Media traffic MUST NOT All media channels MUST be secured via SRTP. Media traffic MUST NOT
be sent over plain (unencrypted) RTP; that is, implementations MUST be sent over plain (unencrypted) RTP; that is, implementations MUST
NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP
MUST be offered for every media channel. WebRTC implementations MUST MUST be offered for every media channel. WebRTC implementations MUST
NOT offer SDES or select it if offered. NOT offer SDES or select it if offered.
All data channels MUST be secured via DTLS. All data channels MUST be secured via DTLS.
All implementations MUST implement DTLS 1.0, with the cipher suite All implementations MUST implement DTLS 1.0, with the cipher suite
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD [FIPS186]. The DTLS-SRTP protection profile
implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
cipher suite. Implementations SHOULD favor cipher suites which Implementations SHOULD implement DTLS 1.2 with the
support PFS over non-PFS cipher suites and GCM over CBC cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG Implementations MUST favor cipher suites which support PFS over non-
Consensus.]] PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
API Requirement: The API MUST provide a mechanism to indicate that a
fresh DTLS key pair is to be generated for a specific call. This API Requirement: The API MUST generate a new authentication key pair
is intended to allow for unlinkability. Note that there are also for every new call by default. This is intended to allow for
settings where it is attractive to use the same keying material unlinkability.
repeatedly, especially those with key continuity-based
authentication. Unless the user specifically configures an API Requirement: The API MUST provide a means to reuse a key pair
external key pair, different key pairs MUST be used for each for calls. This can be used to enable key continuity-based
origin. (This avoids creating a super-cookie.) authentication, and could be used to amortize key generation
costs.
API Requirement: Unless the user specifically configures an external
key pair, different key pairs MUST be used for each origin. (This
avoids creating a super-cookie.)
API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the
JS to obtain the negotiated keying material. This requirement JS to obtain the negotiated keying material. This requirement
preserves the end-to-end security of the media. preserves the end-to-end security of the media.
UI Requirements: A user-oriented client MUST provide an "inspector" UI Requirements: A user-oriented client MUST provide an "inspector"
interface which allows the user to determine the security interface which allows the user to determine the security
characteristics of the media. characteristics of the media.
The following properties SHOULD be displayed "up-front" in the The following properties SHOULD be displayed "up-front" in the
skipping to change at page 36, line 9 skipping to change at page 36, line 9
o Retarget the continuing consent section to assume Binding Requests o Retarget the continuing consent section to assume Binding Requests
o Added some more privacy and linkage text in various places. o Added some more privacy and linkage text in various places.
o Editorial improvements o Editorial improvements
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013.
[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-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-22 (work in progress), draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
February 2015. 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-09 (work in progress), January 2015. dtls-encaps-09 (work in progress), January 2015.
[I-D.muthu-behave-consent-freshness] [I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
for Consent Freshness", draft-muthu-behave-consent- for Consent Freshness", draft-muthu-behave-consent-
freshness-04 (work in progress), July 2013. freshness-04 (work in progress), July 2013.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
<http://www.rfc-editor.org/info/rfc4347>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006,
<http://www.rfc-editor.org/info/rfc4572>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April Uniform Resource Identifiers (URIs)", RFC 5785,
2010. DOI 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
2011.
[WebMessaging] [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
Hickson, , "HTML5 Web Messaging", May 2012, DOI 10.17487/RFC6454, December 2011,
<http://www.w3.org/TR/2012/CR-webmessaging-20120501/>. <http://www.rfc-editor.org/info/rfc6454>.
[webcrypto] [webcrypto]
Dahl, Sleevi, , "Web Cryptography API", June 2013. Dahl, Sleevi, , "Web Cryptography API", June 2013.
Available at http://www.w3.org/TR/WebCryptoAPI/ Available at http://www.w3.org/TR/WebCryptoAPI/
[webrtc-api] [webrtc-api]
Bergkvist, Burnett, Jennings, Narayanan, , "WebRTC 1.0: Bergkvist, Burnett, Jennings, Narayanan, , "WebRTC 1.0:
Real-time Communication Between Browsers", October 2011. Real-time Communication Between Browsers", October 2011.
Available at http://dev.w3.org/2011/webrtc/editor/ Available at http://dev.w3.org/2011/webrtc/editor/
webrtc.html webrtc.html
10.2. Informative References 10.2. Informative References
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J., Jennings, C., and E. Rescorla, "Javascript Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 Session Establishment Protocol", draft-ietf-rtcweb-jsep-14
(work in progress), October 2014. (work in progress), March 2016.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[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. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
6455, December 2011. RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>.
[XmlHttpRequest] [XmlHttpRequest]
van Kesteren, A., "XMLHttpRequest Level 2", January 2012. van Kesteren, A., "XMLHttpRequest Level 2", January 2012.
Appendix A. Example IdP Bindings to Specific Protocols Appendix A. Example IdP Bindings to Specific Protocols
[[TODO: These still need some cleanup.]] [[TODO: These still need some cleanup.]]
This section provides some examples of how the mechanisms described This section provides some examples of how the mechanisms described
in this document could be used with existing authentication protocols in this document could be used with existing authentication protocols
 End of changes. 30 change blocks. 
55 lines changed or deleted 88 lines changed or added

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