draft-ietf-rtcweb-security-arch-13.txt   draft-ietf-rtcweb-security-arch-14.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track October 30, 2017 Intended status: Standards Track March 10, 2018
Expires: May 3, 2018 Expires: September 11, 2018
WebRTC Security Architecture WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-13 draft-ietf-rtcweb-security-arch-14
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 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 May 3, 2018. This Internet-Draft will expire on September 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(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 2, line 44 skipping to change at page 2, line 44
5.5. Communications Security . . . . . . . . . . . . . . . . . 15 5.5. Communications Security . . . . . . . . . . . . . . . . . 15
5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 17 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 17
5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 18 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 18
5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 20 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 20
5.6.3. Items for Standardization . . . . . . . . . . . . . . 21 5.6.3. Items for Standardization . . . . . . . . . . . . . . 21
5.6.4. Binding Identity Assertions to JSEP Offer/Answer 5.6.4. Binding Identity Assertions to JSEP Offer/Answer
Transactions . . . . . . . . . . . . . . . . . . . . 21 Transactions . . . . . . . . . . . . . . . . . . . . 21
5.6.4.1. Carrying Identity Assertions . . . . . . . . . . 22 5.6.4.1. Carrying Identity Assertions . . . . . . . . . . 22
5.6.4.2. a=identity Attribute . . . . . . . . . . . . . . 23 5.6.4.2. a=identity Attribute . . . . . . . . . . . . . . 23
5.6.5. Determining the IdP URI . . . . . . . . . . . . . . . 23 5.6.5. Determining the IdP URI . . . . . . . . . . . . . . . 23
5.6.5.1. Authenticating Party . . . . . . . . . . . . . . 24 5.6.5.1. Authenticating Party . . . . . . . . . . . . . . 25
5.6.5.2. Relying Party . . . . . . . . . . . . . . . . . . 25 5.6.5.2. Relying Party . . . . . . . . . . . . . . . . . . 25
5.6.6. Requesting Assertions . . . . . . . . . . . . . . . . 25 5.6.6. Requesting Assertions . . . . . . . . . . . . . . . . 25
5.6.7. Managing User Login . . . . . . . . . . . . . . . . . 26 5.6.7. Managing User Login . . . . . . . . . . . . . . . . . 26
5.7. Verifying Assertions . . . . . . . . . . . . . . . . . . 26 5.7. Verifying Assertions . . . . . . . . . . . . . . . . . . 27
5.7.1. Identity Formats . . . . . . . . . . . . . . . . . . 27 5.7.1. Identity Formats . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Communications Security . . . . . . . . . . . . . . . . . 28 6.1. Communications Security . . . . . . . . . . . . . . . . . 28
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30
6.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 31 6.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 31
6.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 31 6.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 31
6.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 31 6.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 31
6.4.3. Privacy of IdP-generated identities and the hosting 6.4.3. Privacy of IdP-generated identities and the hosting
site . . . . . . . . . . . . . . . . . . . . . . . . 32 site . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 32 6.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 32
6.4.4.1. Confusable Characters . . . . . . . . . . . . . . 32
6.4.5. Web Security Feature Interactions . . . . . . . . . . 32 6.4.5. Web Security Feature Interactions . . . . . . . . . . 32
6.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 32 6.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 33
6.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 33 6.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Changes since -10 . . . . . . . . . . . . . . . . . . . . 33 9.1. Changes since -11 . . . . . . . . . . . . . . . . . . . . 34
9.2. Changes since -06 . . . . . . . . . . . . . . . . . . . . 34 9.2. Changes since -10 . . . . . . . . . . . . . . . . . . . . 34
9.3. Changes since -05 . . . . . . . . . . . . . . . . . . . . 34 9.3. Changes since -06 . . . . . . . . . . . . . . . . . . . . 34
9.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 34 9.4. Changes since -05 . . . . . . . . . . . . . . . . . . . . 34
9.5. Changes since -03 . . . . . . . . . . . . . . . . . . . . 34 9.5. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
9.6. Changes since -02 . . . . . . . . . . . . . . . . . . . . 34 9.6. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
9.7. Changes since -02 . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Example IdP Bindings to Specific Protocols . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
A.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
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
transfer. Unlike most conventional real-time systems, (e.g., SIP- transfer. Unlike most conventional real-time systems, (e.g., SIP-
based[RFC3261] soft phones) WebRTC communications are directly based[RFC3261] soft phones) WebRTC communications are directly
controlled by some Web server, via a JavaScript (JS) API as shown in controlled by some Web server, via a JavaScript (JS) API as shown in
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Figure 2: A multidomain WebRTC system Figure 2: A multidomain WebRTC system
This system presents a number of new security challenges, which are This system presents a number of new security challenges, which are
analyzed in [I-D.ietf-rtcweb-security]. This document describes a analyzed in [I-D.ietf-rtcweb-security]. This document describes a
security architecture for WebRTC which addresses the threats and security architecture for WebRTC which addresses the threats and
requirements described in that document. requirements described in that document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119]. [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Trust Model 3. Trust Model
The basic assumption of this architecture is that network resources The basic assumption of this architecture is that network resources
exist in a hierarchy of trust, rooted in the browser, which serves as exist in a hierarchy of trust, rooted in the browser, which serves as
the user's TRUSTED COMPUTING BASE (TCB). Any security property which the user's TRUSTED COMPUTING BASE (TCB). Any security property which
the user wishes to have enforced must be ultimately guaranteed by the the user wishes to have enforced must be ultimately guaranteed by the
browser (or transitively by some property the browser verifies). browser (or transitively by some property the browser verifies).
Conversely, if the browser is compromised, then no security Conversely, if the browser is compromised, then no security
guarantees are possible. Note that there are cases (e.g., Internet guarantees are possible. Note that there are cases (e.g., Internet
skipping to change at page 11, line 11 skipping to change at page 11, line 11
who is on-path to that IP address detouring the traffic. Note that who is on-path to that IP address detouring the traffic. Note that
it is not possible for an attacker who is on-path between Alice and it is not possible for an attacker who is on-path between Alice and
Bob but not attached to the signaling service to spoof these checks Bob but not attached to the signaling service to spoof these checks
because they do not have the ICE credentials. Bob has the same because they do not have the ICE credentials. Bob has the same
security guarantees with respect to Alice. security guarantees with respect to Alice.
4.3. DTLS Handshake 4.3. DTLS Handshake
Once the ICE checks have completed [more specifically, once some ICE Once the ICE checks have completed [more specifically, once some ICE
checks have completed], Alice and Bob can set up a secure channel or checks have completed], Alice and Bob can set up a secure channel or
channels. This is performed via DTLS [RFC4347] and DTLS-SRTP channels. This is performed via DTLS [RFC6347] and DTLS-SRTP
[RFC5763] keying for SRTP [RFC3711] for the media channel and SCTP [RFC5763] keying for SRTP [RFC3711] for the media channel and SCTP
over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps] for data channels. over DTLS [RFC8261] for data channels. Specifically, Alice and Bob
Specifically, Alice and Bob perform a DTLS handshake on every channel perform a DTLS handshake on every component which has been
which has been established by ICE. The total number of channels established by ICE. The total number of channels depends on the
depends on the amount of muxing; in the most likely case we are using amount of muxing; in the most likely case we are using both RTP/RTCP
both RTP/RTCP mux and muxing multiple media streams on the same mux and muxing multiple media streams on the same channel, in which
channel, in which case there is only one DTLS handshake. Once the case there is only one DTLS handshake. Once the DTLS handshake has
DTLS handshake has completed, the keys are exported [RFC5705] and completed, the keys are exported [RFC5705] and used to key SRTP for
used to key SRTP for the media channels. the media channels.
At this point, Alice and Bob know that they share a set of secure At this point, Alice and Bob know that they share a set of secure
data and/or media channels with keys which are not known to any data and/or media channels with keys which are not known to any
third-party attacker. If Alice and Bob authenticated via their IdPs, third-party attacker. If Alice and Bob authenticated via their IdPs,
then they also know that the signaling service is not mounting a man- then they also know that the signaling service is not mounting a man-
in-the-middle attack on their traffic. Even if they do not use an in-the-middle attack on their traffic. Even if they do not use an
IdP, as long as they have minimal trust in the signaling service not IdP, as long as they have minimal trust in the signaling service not
to perform a man-in-the-middle attack, they know that their to perform a man-in-the-middle attack, they know that their
communications are secure against the signaling service as well communications are secure against the signaling service as well
(i.e., that the signaling service cannot mount a passive attack on (i.e., that the signaling service cannot mount a passive attack on
skipping to change at page 11, line 49 skipping to change at page 11, line 49
encrypted and authenticated. encrypted and authenticated.
The one remaining security property we need to establish is "consent The one remaining security property we need to establish is "consent
freshness", i.e., allowing Alice to verify that Bob is still prepared freshness", i.e., allowing Alice to verify that Bob is still prepared
to receive her communications so that Alice does not continue to send to receive her communications so that Alice does not continue to send
large traffic volumes to entities which went abruptly offline. ICE large traffic volumes to entities which went abruptly offline. ICE
specifies periodic STUN keepalives but only if media is not flowing. specifies periodic STUN keepalives but only if media is not flowing.
Because the consent issue is more difficult here, we require WebRTC Because the consent issue is more difficult here, we require WebRTC
implementations to periodically send keepalives. As described in implementations to periodically send keepalives. As described in
Section 5.3, these keepalives MUST be based on the consent freshness Section 5.3, these keepalives MUST be based on the consent freshness
mechanism specified in [I-D.muthu-behave-consent-freshness]. If a mechanism specified in [RFC7675]. If a keepalive fails and no new
keepalive fails and no new ICE channels can be established, then the ICE channels can be established, then the session is terminated.
session is terminated.
5. Detailed Technical Description 5. Detailed Technical Description
5.1. Origin and Web Security Issues 5.1. Origin and Web Security Issues
The basic unit of permissions for WebRTC is the origin [RFC6454]. The basic unit of permissions for WebRTC is the origin [RFC6454].
Because the security of the origin depends on being able to Because the security of the origin depends on being able to
authenticate content from that origin, the origin can only be authenticate content from that origin, the origin can only be
securely established if data is transferred over HTTPS [RFC2818]. securely established if data is transferred over HTTPS [RFC2818].
Thus, clients MUST treat HTTP and HTTPS origins as different Thus, clients MUST treat HTTP and HTTPS origins as different
skipping to change at page 13, line 36 skipping to change at page 13, line 36
microphone input without the JS being able to prevent it. microphone input without the JS being able to prevent it.
UI Requirement: If the UI indication of camera/microphone use are UI Requirement: If the UI indication of camera/microphone use are
displayed in the browser such that minimizing the browser window displayed in the browser such that minimizing the browser window
would hide the indication, or the JS creating an overlapping would hide the indication, or the JS creating an overlapping
window would hide the indication, then the browser SHOULD stop window would hide the indication, then the browser SHOULD stop
camera and microphone input when the indication is hidden. [Note: camera and microphone input when the indication is hidden. [Note:
this may not be necessary in systems that are non-windows-based this may not be necessary in systems that are non-windows-based
but that have good notifications support, such as phones.] but that have good notifications support, such as phones.]
o Browsers MUST not permit permanent screen or application sharing o Browsers MUST NOT permit permanent screen or application sharing
permissions to be installed as a response to a JS request for permissions to be installed as a response to a JS request for
permissions. Instead, they must require some other user action permissions. Instead, they must require some other user action
such as a permissions setting or an application install experience such as a permissions setting or an application install experience
to grant permission to a site. to grant permission to a site.
o Browsers MUST provide a separate dialog request for screen/ o Browsers MUST provide a separate dialog request for screen/
application sharing permissions even if the media request is made application sharing permissions even if the media request is made
at the same time as camera and microphone. at the same time as camera and microphone.
o The browser MUST indicate any windows which are currently being o The browser MUST indicate any windows which are currently being
shared in some unambiguous way. Windows which are not visible shared in some unambiguous way. Windows which are not visible
MUST not be shared even if the application is being shared. If MUST NOT be shared even if the application is being shared. If
the screen is being shared, then that MUST be indicated. the screen is being shared, then that MUST be indicated.
Clients MAY permit the formation of data channels without any direct Clients MAY permit the formation of data channels without any direct
user approval. Because sites can always tunnel data through the user approval. Because sites can always tunnel data through the
server, further restrictions on the data channel do not provide any server, further restrictions on the data channel do not provide any
additional security. (though see Section 5.3 for a related issue). additional security. (though see Section 5.3 for a related issue).
Implementations which support some form of direct user authentication Implementations which support some form of direct user authentication
SHOULD also provide a policy by which a user can authorize calls only SHOULD also provide a policy by which a user can authorize calls only
to specific communicating peers. Specifically, the implementation to specific communicating peers. Specifically, the implementation
skipping to change at page 14, line 45 skipping to change at page 14, line 45
stack would accept a new response for that transaction). The JS MUST stack would accept a new response for that transaction). The JS MUST
NOT be permitted to control the local ufrag and password, though it NOT be permitted to control the local ufrag and password, though it
of course knows it. of course knows it.
While continuing consent is required, the ICE [RFC5245]; Section 10 While continuing consent is required, the ICE [RFC5245]; Section 10
keepalives use STUN Binding Indications which are one-way and keepalives use STUN Binding Indications which are one-way and
therefore not sufficient. The current WG consensus is to use ICE therefore not sufficient. The current WG consensus is to use ICE
Binding Requests for continuing consent freshness. ICE already Binding Requests for continuing consent freshness. ICE already
requires that implementations respond to such requests, so this requires that implementations respond to such requests, so this
approach is maximally compatible. A separate document will profile approach is maximally compatible. A separate document will profile
the ICE timers to be used; see [I-D.muthu-behave-consent-freshness]. the ICE timers to be used; see [RFC7675].
5.4. IP Location Privacy 5.4. IP Location Privacy
A side effect of the default ICE behavior is that the peer learns A side effect of the default ICE behavior is that the peer learns
one's IP address, which leaks large amounts of location information. one's IP address, which leaks large amounts of location information.
This has negative privacy consequences in some circumstances. The This has negative privacy consequences in some circumstances. The
API requirements in this section are intended to mitigate this issue. API requirements in this section are intended to mitigate this issue.
Note that these requirements are NOT intended to protect the user's Note that these requirements are NOT intended to protect the user's
IP address from a malicious site. In general, the site will learn at IP address from a malicious site. In general, the site will learn at
skipping to change at page 15, line 51 skipping to change at page 15, line 51
Note that some enterprises may operate proxies and/or NATs designed Note that some enterprises may operate proxies and/or NATs designed
to hide internal IP addresses from the outside world. WebRTC to hide internal IP addresses from the outside world. WebRTC
provides no explicit mechanism to allow this function. Either such provides no explicit mechanism to allow this function. Either such
enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or
the JS, or there needs to be browser support to set the "TURN-only" the JS, or there needs to be browser support to set the "TURN-only"
policy regardless of the site's preferences. policy regardless of the site's preferences.
5.5. Communications Security 5.5. Communications Security
Implementations MUST implement SRTP [RFC3711]. Implementations MUST Implementations MUST implement SRTP [RFC3711]. Implementations MUST
implement DTLS [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
keying. Implementations MUST implement keying. Implementations MUST implement [RFC8261].
[I-D.ietf-tsvwg-sctp-dtls-encaps].
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.0, with the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
[FIPS186]. The DTLS-SRTP protection profile [FIPS186]. 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 Implementations SHOULD implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations MUST favor cipher suites which support PFS over non- Implementations MUST favor cipher suites which support PFS over non-
PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. PFS cipher suites and SHOULD favor AEAD 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 an appropriate alert ("no_renegotiation" for TLS 1.2) if it with a "no_renegotiation" alert if offered.
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.
API Requirement: The API MUST provide a means to reuse a key pair API Requirement: The API MUST provide a means to reuse a key pair
for calls. This can be used to enable key continuity-based for calls. This can be used to enable key continuity-based
authentication, and could be used to amortize key generation authentication, and could be used to amortize key generation
costs. costs.
skipping to change at page 17, line 24 skipping to change at page 17, line 24
party verifiable X.509 certificate or via a Web IdP mechanism party verifiable X.509 certificate or via a Web IdP mechanism
(see Section 5.6) the "security characteristics" MUST include (see Section 5.6) the "security characteristics" MUST include
the verified information. X.509 identities and Web IdP the verified information. X.509 identities and Web IdP
identities have similar semantics and should be displayed in a identities have similar semantics and should be displayed in a
similar way. similar way.
The following properties are more likely to require some "drill- The following properties are more likely to require some "drill-
down" from the user: down" from the user:
* The "security characteristics" MUST indicate the cryptographic * The "security characteristics" MUST indicate the cryptographic
algorithms in use (For example: "AES-CBC" or "Null Cipher".) algorithms in use (For example: "AES-CBC".) However, if Null
However, if Null ciphers are used, that MUST be presented to ciphers are used, that MUST be presented to the user at the
the user at the top-level UI. top-level UI.
* The "security characteristics" MUST indicate whether PFS is * The "security characteristics" MUST indicate whether PFS 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 an SAS. certificate fingerprint or an SAS.
5.6. Web-Based Peer Authentication 5.6. Web-Based Peer Authentication
skipping to change at page 22, line 20 skipping to change at page 22, line 20
"algorithm": "sha-1", "algorithm": "sha-1",
"digest": "74:E9:76:C8:19:...:F4:45:6B" "digest": "74:E9:76:C8:19:...:F4:45:6B"
} ] } ]
} }
The "fingerprint" value is an array of objects. Each object in the The "fingerprint" value is an array of objects. Each object in the
array contains "algorithm" and "digest" values, which correspond array contains "algorithm" and "digest" values, which correspond
directly to the algorithm and digest values in the "a=fingerprint" directly to the algorithm and digest values in the "a=fingerprint"
line of the SDP [RFC8122]. line of the SDP [RFC8122].
This object is encoded in a JSON [RFC4627] string for passing to the This object is encoded in a JSON [RFC8259] string for passing to the
IdP. IdP.
This structure does not need to be interpreted by the IdP or the IdP This structure does not need to be interpreted by the IdP or the IdP
proxy. It is consumed solely by the RP's browser. The IdP merely proxy. It is consumed solely by the RP's browser. The IdP merely
treats it as an opaque value to be attested to. Thus, new parameters treats it as an opaque value to be attested to. Thus, new parameters
can be added to the assertion without modifying the IdP. can be added to the assertion without modifying the IdP.
5.6.4.1. Carrying Identity Assertions 5.6.4.1. Carrying Identity Assertions
Once an IdP has generated an assertion, it is attached to the SDP Once an IdP has generated an assertion, it is attached to the SDP
skipping to change at page 23, line 36 skipping to change at page 23, line 36
*(";" [ SP ] identity-extension) ] *(";" [ SP ] identity-extension) ]
identity-assertion = base64 identity-assertion = base64
base64 = 1*(ALPHA / DIGIT / "+" / "/" / "=" ) base64 = 1*(ALPHA / DIGIT / "+" / "/" / "=" )
identity-extension = extension-att-name [ "=" extension-att-value ] identity-extension = extension-att-name [ "=" extension-att-value ]
extension-att-name = token extension-att-name = token
extension-att-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff) extension-att-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
; byte-string from [RFC4566] omitting ";" ; byte-string from [RFC4566] omitting ";"
No extensions are defined for this attribute. No extensions are defined for this attribute.
The identity assertion is a JSON [RFC4627] encoded dictionary that The identity assertion is a JSON [RFC8259] encoded dictionary that
contains two values. The "assertion" attribute contains an opaque contains two values. The "assertion" attribute contains an opaque
string that is consumed by the IdP. The "idp" attribute is a string that is consumed by the IdP. The "idp" attribute is a
dictionary with one or two further values that identify the IdP, as dictionary with one or two further values that identify the IdP, as
described in Section 5.6.5. described in Section 5.6.5.
The semantics of multiple identity attributes are undefined.
Implementations SHOULD only include a single identity attribute in an
offer and relying parties MAY elect to ignore all but the first
identity attribute.
5.6.5. Determining the IdP URI 5.6.5. Determining the IdP URI
In order to ensure that the IdP is under control of the domain owner In order to ensure that the IdP is under control of the domain owner
rather than someone who merely has an account on the domain owner's rather than someone who merely has an account on the domain owner's
server (e.g., in shared hosting scenarios), the IdP JavaScript is server (e.g., in shared hosting scenarios), the IdP JavaScript is
hosted at a deterministic location based on the IdP's domain name. hosted at a deterministic location based on the IdP's domain name.
Each IdP proxy instance is associated with two values: Each IdP proxy instance is associated with two values:
domain name: The IdP's domain name Authority: The authority [RFC3986] at which the IdP's service is
hosted. Note that this may include a non-default port or a
userinfo component, but neither will be available in a certificate
verifying the site.
protocol: The specific IdP protocol which the IdP is using. This is protocol: The specific IdP protocol which the IdP is using. This is
a completely opaque IdP-specific string, but allows an IdP to a completely opaque IdP-specific string, but allows an IdP to
implement two protocols in parallel. This value may be the empty implement two protocols in parallel. This value may be the empty
string. If no value for protocol is provided, a value of string. If no value for protocol is provided, a value of
"default" is used. "default" is used.
Each IdP MUST serve its initial entry page (i.e., the one loaded by Each IdP MUST serve its initial entry page (i.e., the one loaded by
the IdP proxy) from a well-known URI [RFC5785]. The well-known URI the IdP proxy) from a well-known URI [RFC5785]. The well-known URI
for an IdP proxy is formed from the following URI components: for an IdP proxy is formed from the following URI components:
1. The scheme, "https:". An IdP MUST be loaded using HTTPS 1. The scheme, "https:". An IdP MUST be loaded using HTTPS
[RFC2818]. [RFC2818].
2. The authority, which is the IdP domain name. The authority MAY 2. The authority [RFC3986]. As noted above, the authority MAY
contain a non-default port number. Any port number is removed contain a non-default port number or userinfo sub-component.
when determining if an asserted identity matches the name of the Both are removed when determining if an asserted identity matches
IdP. The authority MUST NOT include a userinfo sub-component. the name of the IdP.
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://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.
5.6.5.1. Authenticating Party 5.6.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 page 26, line 26 skipping to change at page 26, line 36
For use in signaling, the assertion is serialized into JSON, For use in signaling, the assertion is serialized into JSON,
base64-encoded [RFC4648], and used as the value of the "a=identity" base64-encoded [RFC4648], and used as the value of the "a=identity"
attribute. attribute.
5.6.7. Managing User Login 5.6.7. Managing User Login
In order to generate an identity assertion, the IdP needs proof of In order to generate an identity assertion, the IdP needs proof of
the user's identity. It is common practice to authenticate users the user's identity. It is common practice to authenticate users
(using passwords or multi-factor authentication), then use Cookies (using passwords or multi-factor authentication), then use Cookies
[RFC6265] or HTTP authentication [RFC2617] for subsequent exchanges. [RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges.
The IdP proxy is able to access cookies, HTTP authentication or other The IdP proxy is able to access cookies, HTTP authentication or other
persistent session data because it operates in the security context persistent session data because it operates in the security context
of the IdP origin. Therefore, if a user is logged in, the IdP could of the IdP origin. Therefore, if a user is logged in, the IdP could
have all the information needed to generate an assertion. have all the information needed to generate an assertion.
An IdP proxy is unable to generate an assertion if the user is not An IdP proxy is unable to generate an assertion if the user is not
logged in, or the IdP wants to interact with the user to acquire more logged in, or the IdP wants to interact with the user to acquire more
information before generating the assertion. If the IdP wants to information before generating the assertion. If the IdP wants to
interact with the user before generating an assertion, the IdP proxy interact with the user before generating an assertion, the IdP proxy
skipping to change at page 29, line 41 skipping to change at page 30, line 4
privacy enhancing technologies such as Tor. Combined WebRTC/Tor privacy enhancing technologies such as Tor. Combined WebRTC/Tor
implementations SHOULD arrange to route the media as well as the implementations SHOULD arrange to route the media as well as the
signaling through Tor. Currently this will produce very suboptimal signaling through Tor. Currently this will produce very suboptimal
performance. performance.
Additionally, any identifier which persists across multiple calls is Additionally, any identifier which persists across multiple calls is
potentially a problem for privacy, especially for anonymous calling potentially a problem for privacy, especially for anonymous calling
services. Such services SHOULD instruct the browser to use separate services. Such services SHOULD instruct the browser to use separate
DTLS keys for each call and also to use TURN throughout the call. DTLS keys for each call and also to use TURN throughout the call.
Otherwise, the other side will learn linkable information. Otherwise, the other side will learn linkable information.
Additionally, browsers SHOULD implement the privacy-preserving CNAME Additionally, browsers SHOULD implement the privacy-preserving CNAME
generation mode of [I-D.ietf-avtcore-6222bis]. generation mode of [RFC7022].
6.3. Denial of Service 6.3. Denial of Service
The consent mechanisms described in this document are intended to The consent mechanisms described in this document are intended to
mitigate denial of service attacks in which an attacker uses clients mitigate denial of service attacks in which an attacker uses clients
to send large amounts of traffic to a victim without the consent of to send large amounts of traffic to a victim without the consent of
the victim. While these mechanisms are sufficient to protect victims the victim. While these mechanisms are sufficient to protect victims
who have not implemented WebRTC at all, WebRTC implementations need who have not implemented WebRTC at all, WebRTC implementations need
to be more careful. to be more careful.
skipping to change at page 31, line 19 skipping to change at page 31, line 29
above. At a high level, the IdP is attesting that the user above. At a high level, the IdP is attesting that the user
identified in the assertion wishes to be associated with the identified in the assertion wishes to be associated with the
assertion. Thus, it must not be possible for arbitrary third parties assertion. Thus, it must not be possible for arbitrary third parties
to get assertions tied to a user or to produce assertions that RPs to get assertions tied to a user or to produce assertions that RPs
will accept. will accept.
6.4.1. PeerConnection Origin Check 6.4.1. PeerConnection Origin Check
Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by
the browser, so nothing stops a Web attacker from creating their own the browser, so nothing stops a Web attacker from creating their own
IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. IFRAME, loading the IdP proxy HTML/JS, and requesting a signature
In order to prevent this attack, we require that all signatures be over his own keys rather than those generated in the browser.
tied to a specific origin ("rtcweb://...") which cannot be produced However, that proxy would be in the attacker's origin, not the IdP's
by content JavaScript. Thus, while an attacker can instantiate the origin. Only the browser itself can instantiate a context that (a)
IdP proxy, they cannot send messages from an appropriate origin and is in the IdP's origin and (b) exposes the correct API surface.
so cannot create acceptable assertions. I.e., the assertion request Thus, the IdP proxy on the sender's side MUST ensure that it is
must have come from the browser. This origin check is enforced on running in the IdP's origin prior to issuing assertions.
the relying party side, not on the authenticating party side. The
reason for this is to take the burden of knowing which origins are
valid off of the IdP, thus making this mechanism extensible to other
applications besides WebRTC. The IdP simply needs to gather the
origin information (from the posted message) and attach it to the
assertion.
Note that although this origin check is enforced on the RP side and
not at the IdP, it is absolutely imperative that it be done. The
mechanisms in this document rely on the browser enforcing access
restrictions on the DTLS keys and assertion requests which do not
come with the right origin may be from content JS rather than from
browsers, and therefore those access restrictions cannot be assumed.
Note that this check only asserts that the browser (or some other Note that this check only asserts that the browser (or some other
entity with access to the user's authentication data) attests to the entity with access to the user's authentication data) attests to the
request and hence to the fingerprint. It does not demonstrate that request and hence to the fingerprint. It does not demonstrate that
the browser has access to the associated private key. However, the browser has access to the associated private key, and therefore
attaching one's identity to a key that the user does not control does an attacker can attach their own identity to another party's keying
not appear to provide substantial leverage to an attacker, so a proof material, thus making a call which comes from Alice appear to come
of possession is omitted for simplicity. from the attacker. See [I-D.ietf-mmusic-sdp-uks] for defenses
against this form of attack.
6.4.2. IdP Well-known URI 6.4.2. IdP Well-known URI
As described in Section 5.6.5 the IdP proxy HTML/JS landing page is As described in Section 5.6.5 the IdP proxy HTML/JS landing page is
located at a well-known URI based on the IdP's domain name. This located at a well-known URI based on the IdP's domain name. This
requirement prevents an attacker who can write some resources at the requirement prevents an attacker who can write some resources at the
IdP (e.g., on one's Facebook wall) from being able to impersonate the IdP (e.g., on one's Facebook wall) from being able to impersonate the
IdP. IdP.
6.4.3. Privacy of IdP-generated identities and the hosting site 6.4.3. Privacy of IdP-generated identities and the hosting site
skipping to change at page 32, line 37 skipping to change at page 32, line 35
As discussed above, each third-party IdP represents a new universal As discussed above, each third-party IdP represents a new universal
trust point and therefore the number of these IdPs needs to be quite trust point and therefore the number of these IdPs needs to be quite
limited. Most IdPs, even those which issue unqualified identities limited. Most IdPs, even those which issue unqualified identities
such as Facebook, can be recast as authoritative IdPs (e.g., such as Facebook, can be recast as authoritative IdPs (e.g.,
123456@facebook.com). However, in such cases, the user interface 123456@facebook.com). However, in such cases, the user interface
implications are not entirely desirable. One intermediate approach implications are not entirely desirable. One intermediate approach
is to have special (potentially user configurable) UI for large is to have special (potentially user configurable) UI for large
authoritative IdPs, thus allowing the user to instantly grasp that authoritative IdPs, thus allowing the user to instantly grasp that
the call is being authenticated by Facebook, Google, etc. the call is being authenticated by Facebook, Google, etc.
6.4.4.1. Confusable Characters
Because a broad range of characters are permitted in identity
strings, it may be possible for attackers to craft identities which
are confusable with other identities (see [RFC6943] for more on this
topic). This is a problem with any identifier space of this type
(e.g., e-mail addresses). Those minting identifers should avoid
mixed scripts and similar confusable characters. Those presenting
these identifiers to a user should consider highlighting cases of
mixed script usage (see [RFC5890], section 4.4). Other best
practices are still in development.
6.4.5. Web Security Feature Interactions 6.4.5. Web Security Feature Interactions
A number of optional Web security features have the potential to A number of optional Web security features have the potential to
cause issues for this mechanism, as discussed below. cause issues for this mechanism, as discussed below.
6.4.5.1. Popup Blocking 6.4.5.1. Popup Blocking
The IdP proxy is unable to generate popup windows, dialogs or any The IdP proxy is unable to generate popup windows, dialogs or any
other form of user interactions. This prevents the IdP proxy from other form of user interactions. This prevents the IdP proxy from
being used to circumvent user interaction. The "LOGINNEEDED" message being used to circumvent user interaction. The "LOGINNEEDED" message
skipping to change at page 33, line 46 skipping to change at page 34, line 7
8. Acknowledgements 8. Acknowledgements
Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen
Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin
Thomson, Magnus Westerland. Matthew Kaufman provided the UI material Thomson, Magnus Westerland. Matthew Kaufman provided the UI material
in Section 5.5. in Section 5.5.
9. Changes 9. Changes
9.1. Changes since -10 9.1. Changes since -11
Update discussion of IdP security model
Replace "domain name" with RFC 3986 Authority
Clean up discussion of how to generate IdP URI.
Remove obsolete text about null cipher suites.
Remove obsolete appendixes about older IdP systems
Require support for ECDSA, PFS, and AEAD
9.2. Changes since -10
Update cipher suite profiles. Update cipher suite profiles.
Rework IdP interaction based on implementation experience in Firefox. Rework IdP interaction based on implementation experience in Firefox.
9.2. Changes since -06 9.3. Changes since -06
Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the
IETF WG IETF WG
Forbade use in mixed content as discussed in Orlando. Forbade use in mixed content as discussed in Orlando.
Added a requirement to surface NULL ciphers to the top-level. Added a requirement to surface NULL ciphers to the top-level.
Tried to clarify SRTP versus DTLS-SRTP. Tried to clarify SRTP versus DTLS-SRTP.
Added a section on screen sharing permissions. Added a section on screen sharing permissions.
Assorted editorial work. Assorted editorial work.
9.3. Changes since -05 9.4. Changes since -05
The following changes have been made since the -05 draft. The following changes have been made since the -05 draft.
o Response to comments from Richard Barnes o Response to comments from Richard Barnes
o More explanation of the IdP security properties and the federation o More explanation of the IdP security properties and the federation
use case. use case.
o Editorial cleanup. o Editorial cleanup.
9.4. Changes since -03 9.5. Changes since -03
Version -04 was a version control mistake. Please ignore. Version -04 was a version control mistake. Please ignore.
The following changes have been made since the -04 draft. The following changes have been made since the -04 draft.
o Move origin check from IdP to RP per discussion in YVR. o Move origin check from IdP to RP per discussion in YVR.
o Clarified treatment of X.509-level identities. o Clarified treatment of X.509-level identities.
o Editorial cleanup. o Editorial cleanup.
9.5. Changes since -03 9.6. Changes since -03
9.6. Changes since -02 9.7. Changes since -02
The following changes have been made since the -02 draft. The following changes have been made since the -02 draft.
o Forbid persistent HTTP permissions. o Forbid persistent HTTP permissions.
o Clarified the text in S 5.4 to clearly refer to requirements on o Clarified the text in S 5.4 to clearly refer to requirements on
the API to provide functionality to the site. the API to provide functionality to the site.
o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp
skipping to change at page 35, line 21 skipping to change at page 35, line 44
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), [FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013. 2013.
[I-D.ietf-avtcore-6222bis] [I-D.ietf-mmusic-sdp-uks]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
"Guidelines for Choosing RTP Control Protocol (RTCP) uses of Transport Layer Security with the Session
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-01
(work in progress), July 2013. (work in progress), January 2018.
[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-26 (work in progress), March draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016. 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-09 (work in progress), October 2017. ietf-rtcweb-security-10 (work in progress), January 2018.
[I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-09 (work in progress), January 2015.
[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.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, <https://www.rfc- DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
editor.org/info/rfc2818>. 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, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, Resource Identifier (URI): Generic Syntax", STD 66,
<https://www.rfc-editor.org/info/rfc4347>. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/info/rfc4568>. <https://www.rfc-editor.org/info/rfc4568>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, <https://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, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
skipping to change at page 37, line 27 skipping to change at page 37, line 38
[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, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, <https://www.rfc- DOI 10.17487/RFC5785, April 2010, <https://www.rfc-
editor.org/info/rfc5785>. 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, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, <https://www.rfc- DOI 10.17487/RFC6454, December 2011, <https://www.rfc-
editor.org/info/rfc6454>. editor.org/info/rfc6454>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <https://www.rfc-editor.org/info/rfc7022>.
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, <https://www.rfc- DOI 10.17487/RFC8122, March 2017, <https://www.rfc-
editor.org/info/rfc8122>. editor.org/info/rfc8122>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, <https://www.rfc-
editor.org/info/rfc8259>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/info/rfc8261>.
[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-24 Session Establishment Protocol", draft-ietf-rtcweb-jsep-24
(work in progress), October 2017. (work in progress), October 2017.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999,
<https://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,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. 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>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, <https://www.rfc- DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
editor.org/info/rfc6265>. editor.org/info/rfc6265>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
[XmlHttpRequest] [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for
van Kesteren, A., "XMLHttpRequest Level 2", January 2012. Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
2013, <https://www.rfc-editor.org/info/rfc6943>.
Appendix A. Example IdP Bindings to Specific Protocols
[[TODO: These still need some cleanup.]]
This section provides some examples of how the mechanisms described
in this document could be used with existing authentication protocols
such as OAuth. Note that this does not require browser-level support
for either protocol. Rather, the protocols can be fit into the
generic framework.
A.1. OAuth
While OAuth is not directly designed for user-to-user authentication,
with a little lateral thinking it can be made to serve. We use the
following mapping of OAuth concepts to WebRTC concepts:
+----------------------+----------------------+
| OAuth | WebRTC |
+----------------------+----------------------+
| Client | Relying party |
| Resource owner | Authenticating party |
| Authorization server | Identity service |
| Resource server | Identity service |
+----------------------+----------------------+
Table 1
The idea here is that when Alice wants to authenticate to Bob (i.e.,
for Bob to be aware that she is calling). In order to do this, she
allows Bob to see a resource on the identity provider that is bound
to the call, her identity, and her public key. Then Bob retrieves
the resource from the identity provider, thus verifying the binding
between Alice and the call.
Alice IdP Bob
---------------------------------------------------------
Call-Id, Fingerprint ------->
<------------------- Auth Code
Auth Code ---------------------------------------------->
<----- Get Token + Auth Code
Token --------------------->
<------------- Get call-info
Call-Id, Fingerprint ------>
This is a modified version of a common OAuth flow, but omits the [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
redirects required to have the client point the resource owner to the RFC 7617, DOI 10.17487/RFC7617, September 2015,
IdP, which is acting as both the resource server and the <https://www.rfc-editor.org/info/rfc7617>.
authorization server, since Alice already has a handle to the IdP.
Above, we have referred to "Alice", but really what we mean is the [XmlHttpRequest]
PeerConnection. Specifically, the PeerConnection will instantiate an van Kesteren, A., "XMLHttpRequest Level 2", January 2012.
IFRAME with JS from the IdP and will use that IFRAME to communicate
with the IdP, authenticating with Alice's identity (e.g., cookie).
Similarly, Bob's PeerConnection instantiates an IFRAME to talk to the
IdP.
Author's Address Author's Address
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Phone: +1 650 678 2350 Phone: +1 650 678 2350
 End of changes. 50 change blocks. 
170 lines changed or deleted 153 lines changed or added

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