draft-ietf-rtcweb-security-arch-16.txt   draft-ietf-rtcweb-security-arch-17.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track October 22, 2018 Intended status: Standards Track November 17, 2018
Expires: April 25, 2019 Expires: May 21, 2019
WebRTC Security Architecture WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-16 draft-ietf-rtcweb-security-arch-17
Abstract Abstract
This document defines the security architecture for WebRTC, a This document defines the security architecture for WebRTC, a
protocol suite intended for use with real-time applications that can protocol suite intended for use with real-time applications that can
be deployed in browsers - "real time communication on the Web". be deployed in browsers - "real time communication on the Web".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 25, 2019. This Internet-Draft will expire on May 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 32 skipping to change at page 2, line 32
3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5
3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8
4.2. Media Consent Verification . . . . . . . . . . . . . . . 10 4.2. Media Consent Verification . . . . . . . . . . . . . . . 10
4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11
4.4. Communications and Consent Freshness . . . . . . . . . . 11 4.4. Communications and Consent Freshness . . . . . . . . . . 11
5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12 5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12
5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13
5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13 5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13
5.1.2. Answerer Processing of SDP Offer . . . . . . . . . . 14 5.1.2. Generating of SDP Answer . . . . . . . . . . . . . . 14
5.1.3. Generating of SDP Answer . . . . . . . . . . . . . . 14 5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14
5.1.4. Offerer Processing of SDP Answer . . . . . . . . . . 14 5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14
5.1.5. Modifying the Session . . . . . . . . . . . . . . . . 14
6. Detailed Technical Description . . . . . . . . . . . . . . . 14 6. Detailed Technical Description . . . . . . . . . . . . . . . 14
6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14 6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14
6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15 6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15
6.3. Communications Consent . . . . . . . . . . . . . . . . . 17 6.3. Communications Consent . . . . . . . . . . . . . . . . . 17
6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17
6.5. Communications Security . . . . . . . . . . . . . . . . . 18 6.5. Communications Security . . . . . . . . . . . . . . . . . 18
7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20 7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20
7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21 7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21
7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22
7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 5 skipping to change at page 3, line 4
7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22
7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24
7.4. Binding Identity Assertions to JSEP Offer/Answer 7.4. Binding Identity Assertions to JSEP Offer/Answer
Transactions . . . . . . . . . . . . . . . . . . . . . . 24 Transactions . . . . . . . . . . . . . . . . . . . . . . 24
7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25 7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25
7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26 7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26
7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27 7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27
7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 27 7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 27
7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 27 7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 27
7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 28 7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 28
8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29 8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29
8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 29 8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Communications Security . . . . . . . . . . . . . . . . . 30 9.1. Communications Security . . . . . . . . . . . . . . . . . 31
9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32
9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 33 9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 33
9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 33 9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 33
9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34 9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34
9.4.3. Privacy of IdP-generated identities and the hosting 9.4.3. Privacy of IdP-generated identities and the hosting
site . . . . . . . . . . . . . . . . . . . . . . . . 34 site . . . . . . . . . . . . . . . . . . . . . . . . 34
9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 34 9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 34
9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 34 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35
9.4.5. Web Security Feature Interactions . . . . . . . . . . 35 9.4.5. Web Security Feature Interactions . . . . . . . . . . 35
9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 35 9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 35
9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 35 9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 36 12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 36
12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 36 12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 36
12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 36 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37
12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37 12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37
12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 37 12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 37
12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 37 12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 37
12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 37 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38
12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 37 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
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
skipping to change at page 14, line 7 skipping to change at page 14, line 7
SDP session that contains an SDP "identity" attribute. SDP session that contains an SDP "identity" attribute.
5.1.1. Generating the Initial SDP Offer 5.1.1. Generating the Initial SDP Offer
When an offerer sends an offer, in order to provide its identity When an offerer sends an offer, in order to provide its identity
assertion to the peer, it includes an 'identity' attribute in the assertion to the peer, it includes an 'identity' attribute in the
offer. In addition, the offerer includes one or more SDP offer. In addition, the offerer includes one or more SDP
'fingerprint' attributes. The 'identity' attribute MUST be bound to 'fingerprint' attributes. The 'identity' attribute MUST be bound to
all the 'fingerprint' attributes in the session description. all the 'fingerprint' attributes in the session description.
5.1.2. Answerer Processing of SDP Offer 5.1.2. Generating of SDP Answer
When an answerer receives an offer that contains an 'identity'
attribute, the answerer can use the the attribute information to
contact the IdP, and verify the identity of the peer. If the
identity verification fails, the answerer MUST reject the offer.
5.1.3. Generating of SDP Answer
If the answerer elects to include an 'identity' attribute, it follows If the answerer elects to include an 'identity' attribute, it follows
the same steps as those in Section 5.1.1. The answerer can choose to the same steps as those in Section 5.1.1. The answerer can choose to
include or omit an 'identity' attribute independently, regardless of include or omit an 'identity' attribute independently, regardless of
whether the offerer did so. whether the offerer did so.
5.1.4. Offerer Processing of SDP Answer 5.1.3. Processing an SDP Offer or Answer
Offer processing of an 'identity' attribute is the same as that When an endpoint receives an offer or answer that contains an
described in Section 5.1.2. 'identity' attribute, the answerer can use the the attribute
information to contact the IdP, and verify the identity of the peer.
If the identity verification fails, the answerer MUST discard the
offer or answer as malformed.
5.1.5. Modifying the Session 5.1.4. Modifying the Session
When modifying a session, if the set of fingerprints is unchanged, When modifying a session, if the set of fingerprints is unchanged,
then the sender MAY send the same 'identity' attribute. In this then the sender MAY send the same 'identity' attribute. In this
case, the established identity SHOULD be applied to existing DTLS case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those connections as well as new connections established using one of those
fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1
requires that each media section use the same set of fingerprints for requires that each media section use the same set of fingerprints for
every media section. every media section.
If the set of fingerprints changes, then the sender MUST either send If the set of fingerprints changes, then the sender MUST either send
skipping to change at page 19, line 7 skipping to change at page 19, line 5
All media channels MUST be secured via SRTP and SRTCP. Media traffic All media channels MUST be secured via SRTP and SRTCP. Media traffic
MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
implementations MUST NOT negotiate cipher suites with NULL encryption implementations MUST NOT negotiate cipher suites with NULL encryption
modes. DTLS-SRTP MUST be offered for every media channel. WebRTC modes. DTLS-SRTP MUST be offered for every media channel. WebRTC
implementations MUST NOT offer SDP Security Descriptions [RFC4568] or implementations MUST NOT offer SDP Security Descriptions [RFC4568] or
select it if offered. A SRTP MKI MUST NOT be used. select it if offered. A SRTP MKI MUST NOT be used.
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.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
[FIPS186]. The DTLS-SRTP protection profile curve [FIPS186]. Earlier drafts of this specification required DTLS
1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
at the time of this writing some implementations do not support DTLS
1.2; endpoints which support only DTLS 1.2 might encounter
interoperability issues. The DTLS-SRTP protection profile
SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
Implementations SHOULD implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations MUST favor cipher suites which support (Perfect Implementations MUST favor cipher suites which support (Perfect
Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD
over non-AEAD cipher suites. over non-AEAD cipher suites.
Implementations MUST NOT implement DTLS renegotiation and MUST reject Implementations MUST NOT implement DTLS renegotiation and MUST reject
it with a "no_renegotiation" alert if offered. it with a "no_renegotiation" alert if offered.
API Requirement: The API MUST generate a new authentication key pair API Requirement: The API MUST generate a new authentication key pair
for every new call by default. This is intended to allow for for every new call by default. This is intended to allow for
unlinkability. unlinkability.
skipping to change at page 30, line 5 skipping to change at page 30, line 4
"contents": "{\"fingerprint\":[ ... ]}" "contents": "{\"fingerprint\":[ ... ]}"
} }
Figure 6: Example verification result Figure 6: Example verification result
8.1. Identity Formats 8.1. Identity Formats
The identity provided from the IdP to the RP browser MUST consist of The identity provided from the IdP to the RP browser MUST consist of
a string representing the user's identity. This string is in the a string representing the user's identity. This string is in the
form "<user>@<domain>", where "user" consists of any character except form "<user>@<domain>", where "user" consists of any character except
'@', and domain is an internationalized domain name [RFC5890]. '@', and domain is an internationalized domain name [RFC5890] encoded
as a sequence of U-labels.
The PeerConnection API MUST check this string as follows: The PeerConnection API MUST check this string as follows:
1. If the domain portion of the string is equal to the domain name 1. If the domain portion of the string is equal to the domain name
of the IdP proxy, then the assertion is valid, as the IdP is of the IdP proxy, then the assertion is valid, as the IdP is
authoritative for this domain. Comparison of domain names is authoritative for this domain. Comparison of domain names is
done using the label equivalence rule defined in Section 2.3.2.4 done using the label equivalence rule defined in Section 2.3.2.4
of [RFC5890]. of [RFC5890].
2. If the domain portion of the string is not equal to the domain 2. If the domain portion of the string is not equal to the domain
name of the IdP proxy, then the PeerConnection object MUST reject name of the IdP proxy, then the PeerConnection object MUST reject
the assertion unless: the assertion unless:
1. the IdP domain is trusted as an acceptable third-party IdP; 1. the IdP domain is trusted as an acceptable third-party IdP;
and and
2. local policy is configured to trust this IdP domain for the 2. local policy is configured to trust this IdP domain for the
domain portion of the identity string. domain portion of the identity string.
Sites that have identities that do not fit into the RFC822 style (for Any "@" or "%" characters in the "user" portion of the identity MUST
instance, identifiers that are simple numeric values, or values that be escaped according to the "Percent-Encoding" rules defined in
contain '@' characters) SHOULD convert them to this form by escaping Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT
illegal characters and appending their IdP domain (e.g., be percent-encoded. For example, with a user of "user@133" and a
user%40133@identity.example.com), thus ensuring that they are domain of "identity.example.com", the resulting string will be
authoritative for the identity. encoded as "user%40133@identity.example.com".
Implementations are cautioned to take care when displaying user
identities containing escaped "@" characters. If such characters are
unescaped prior to display, implementations MUST distinguish between
the domain of the IdP proxy and any domain that might be implied by
the portion of the <user> portion that appears after the escaped "@"
sign.
9. Security Considerations 9. Security Considerations
Much of the security analysis of this problem is contained in Much of the security analysis of this problem is contained in
[I-D.ietf-rtcweb-security] or in the discussion of the particular [I-D.ietf-rtcweb-security] or in the discussion of the particular
issues above. In order to avoid repetition, this section focuses on issues above. In order to avoid repetition, this section focuses on
(a) residual threats that are not addressed by this document and (b) (a) residual threats that are not addressed by this document and (b)
threats produced by failure/misbehavior of one of the components in threats produced by failure/misbehavior of one of the components in
the system. the system.
skipping to change at page 41, line 21 skipping to change at page 41, line 26
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
13.2. Informative References 13.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-24 Session Establishment Protocol", draft-ietf-rtcweb-jsep-25
(work in progress), October 2017. (work in progress), October 2018.
[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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://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, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
 End of changes. 18 change blocks. 
39 lines changed or deleted 45 lines changed or added

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