rfc8827v5.txt   rfc8827.txt 
Internet Engineering Task Force (IETF) E. Rescorla Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8827 Mozilla Request for Comments: 8827 Mozilla
Category: Standards Track December 2020 Category: Standards Track January 2021
ISSN: 2070-1721 ISSN: 2070-1721
WebRTC Security Architecture WebRTC Security Architecture
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".
skipping to change at line 31 skipping to change at line 31
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8827. https://www.rfc-editor.org/info/rfc8827.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
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 line 267 skipping to change at line 267
figures below. This topology is derived from the topology shown in figures below. This topology is derived from the topology shown in
Figure 1, but separates Alice's and Bob's identities from the process Figure 1, but separates Alice's and Bob's identities from the process
of signaling. Specifically, Alice and Bob have relationships with of signaling. Specifically, Alice and Bob have relationships with
some Identity Provider (IdP) that supports a protocol (such as OpenID some Identity Provider (IdP) that supports a protocol (such as OpenID
Connect) that can be used to demonstrate their identity to other Connect) that can be used to demonstrate their identity to other
parties. For instance, Alice might have an account with a social parties. For instance, Alice might have an account with a social
network which she can then use to authenticate to other Web sites network which she can then use to authenticate to other Web sites
without explicitly having an account with those sites; this is a without explicitly having an account with those sites; this is a
fairly conventional pattern on the Web. Section 7.1 provides an fairly conventional pattern on the Web. Section 7.1 provides an
overview of IdPs and the relevant terminology. Alice and Bob might overview of IdPs and the relevant terminology. Alice and Bob might
have relationships with different IdPs as well. have relationships with different IdPs as well. Note: The IdP
mechanism described here has not seen wide adoption. See Section 7
for more on the status of IdP-based authentication.
This separation of identity provision and signaling isn't This separation of identity provision and signaling isn't
particularly important in "closed world" cases where Alice and Bob particularly important in "closed world" cases where Alice and Bob
are users on the same social network and have identities based on are users on the same social network and have identities based on
that domain (Figure 3). However, there are important settings where that domain (Figure 3). However, there are important settings where
that is not the case, such as federation (calls from one domain to that is not the case, such as federation (calls from one domain to
another; see Figure 4) and calling on untrusted sites, such as where another; see Figure 4) and calling on untrusted sites, such as where
two users who have a relationship via a given social network want to two users who have a relationship via a given social network want to
call each other on another, untrusted, site, such as a poker site. call each other on another, untrusted, site, such as a poker site.
skipping to change at line 910 skipping to change at line 912
* The "security characteristics" MUST indicate whether FS is * The "security characteristics" MUST indicate whether FS is
provided. provided.
* The "security characteristics" MUST include some mechanism to * The "security characteristics" MUST include some mechanism to
allow an out-of-band verification of the peer, such as a allow an out-of-band verification of the peer, such as a
certificate fingerprint or a Short Authentication String (SAS). certificate fingerprint or a Short Authentication String (SAS).
These are compared by the peers to authenticate one another. These are compared by the peers to authenticate one another.
7. Web-Based Peer Authentication 7. Web-Based Peer Authentication
NOTE: The mechanism described in this section was designed relatively
early in the RTCWEB process. In retrospect, the WG was too
optimistic about the enthusiasm for this kind of mechanism. At the
time of publication, it has not been widely adopted or implemented.
It appears in this document as a description of the state of the art
as of this writing.
In a number of cases, it is desirable for the endpoint (i.e., the In a number of cases, it is desirable for the endpoint (i.e., the
browser) to be able to directly identify the endpoint on the other browser) to be able to directly identify the endpoint on the other
side without trusting the signaling service to which they are side without trusting the signaling service to which they are
connected. For instance, users may be making a call via a federated connected. For instance, users may be making a call via a federated
system where they wish to get direct authentication of the other system where they wish to get direct authentication of the other
side. Alternately, they may be making a call on a site which they side. Alternately, they may be making a call on a site which they
minimally trust (such as a poker site) but to someone who has an minimally trust (such as a poker site) but to someone who has an
identity on a site they do trust (such as a social network). identity on a site they do trust (such as a social network).
Recently, a number of Web-based identity technologies (OAuth, Recently, a number of Web-based identity technologies (OAuth,
skipping to change at line 1215 skipping to change at line 1224
3. The path, starting with "/.well-known/idp-proxy/" and appended 3. The path, starting with "/.well-known/idp-proxy/" and appended
with the IdP protocol. Note that the separator characters '/' with the IdP protocol. Note that the separator characters '/'
(%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field,
lest an attacker be able to direct requests outside of the lest an attacker be able to direct requests outside of the
controlled "/.well-known/" prefix. Query and fragment values MAY controlled "/.well-known/" prefix. Query and fragment values MAY
be used by including '?' or '#' characters. be used by including '?' or '#' characters.
For example, for the IdP "identity.example.com" and the protocol For example, for the IdP "identity.example.com" and the protocol
"example", the URL would be: "example", the URL would be:
<https://identity.example.com/.well-known/idp-proxy/example> https://identity.example.com/.well-known/idp-proxy/example
The IdP MAY redirect requests to this URL, but they MUST retain the The IdP MAY redirect requests to this URL, but they MUST retain the
"https:" scheme. This changes the effective origin of the IdP, but "https:" scheme. This changes the effective origin of the IdP, but
not the domain of the identities that the IdP is permitted to assert not the domain of the identities that the IdP is permitted to assert
and validate. I.e., the IdP is still regarded as authoritative for and validate. I.e., the IdP is still regarded as authoritative for
the original domain. the original domain.
7.5.1. Authenticating Party 7.5.1. Authenticating Party
How an AP determines the appropriate IdP domain is out of scope of How an AP determines the appropriate IdP domain is out of scope of
skipping to change at line 1788 skipping to change at line 1797
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>. <https://www.rfc-editor.org/info/rfc8615>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, December 2020, DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/info/rfc8825>.
[RFC8826] Rescorla, E., "Security Considerations for WebRTC", [RFC8826] Rescorla, E., "Security Considerations for WebRTC",
RFC 8826, DOI 10.17487/RFC8826, December 2020, RFC 8826, DOI 10.17487/RFC8826, January 2021,
<https://www.rfc-editor.org/info/rfc8826>. <https://www.rfc-editor.org/info/rfc8826>.
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
"JavaScript Session Establishment Protocol (JSEP)", "JavaScript Session Establishment Protocol (JSEP)",
RFC 8829, DOI 10.17487/RFC8829, December 2020, RFC 8829, DOI 10.17487/RFC8829, January 2021,
<https://www.rfc-editor.org/info/rfc8829>. <https://www.rfc-editor.org/info/rfc8829>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
December 2020, <https://www.rfc-editor.org/info/rfc8834>. January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
Uses of TLS with the Session Description Protocol (SDP)", Uses of TLS with the Session Description Protocol (SDP)",
RFC 8844, DOI 10.17487/RFC8844, December 2020, RFC 8844, DOI 10.17487/RFC8844, January 2021,
<https://www.rfc-editor.org/info/rfc8844>. <https://www.rfc-editor.org/info/rfc8844>.
[webcrypto] [webcrypto]
Watson, M., "Web Cryptography API", W3C Recommendation, 26 Watson, M., "Web Cryptography API", W3C Recommendation, 26
January 2017, January 2017,
<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>. <https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>.
[webrtc-api] [webrtc-api]
Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
Real-time Communication Between Browsers", W3C Candidate Real-time Communication Between Browsers", W3C Proposed
Recommendation, <https://www.w3.org/TR/webrtc/>. Recommendation, <https://www.w3.org/TR/webrtc/>.
11.2. Informative References 11.2. Informative References
[fetch] van Kesteren, A., "Fetch", [fetch] van Kesteren, A., "Fetch",
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[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,
skipping to change at line 1860 skipping to change at line 1869
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8828] Uberti, J., "WebRTC IP Address Handling Requirements", [RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling
RFC 8828, DOI 10.17487/RFC8828, December 2020, Requirements", RFC 8828, DOI 10.17487/RFC8828, January
<https://www.rfc-editor.org/info/rfc8828>. 2021, <https://www.rfc-editor.org/info/rfc8828>.
[TLS-DTLS13] [TLS-DTLS13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-39, 2 November 2020, dtls13-39, 2 November 2020,
<https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>. <https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
Acknowledgements Acknowledgements
 End of changes. 12 change blocks. 
13 lines changed or deleted 22 lines changed or added

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