draft-ietf-rtcweb-security-arch-09.txt   draft-ietf-rtcweb-security-arch-10.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track February 14, 2014 Intended status: Standards Track July 4, 2014
Expires: August 18, 2014 Expires: January 5, 2015
WebRTC Security Architecture WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-09 draft-ietf-rtcweb-security-arch-10
Abstract Abstract
The Real-Time Communications on the Web (RTCWEB) working group is The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for enabling real-time tasked with standardizing protocols for enabling real-time
communications within user-agents using web technologies (commonly communications within user-agents using web technologies (commonly
called "WebRTC"). This document defines the security architecture called "WebRTC"). This document defines the security architecture
for WebRTC. for WebRTC.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 16 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 16
5.5. Communications Security . . . . . . . . . . . . . . . . . 17 5.5. Communications Security . . . . . . . . . . . . . . . . . 17
5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 18 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 18
5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 19 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 19
5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 21 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 21
5.6.3. Items for Standardization . . . . . . . . . . . . . . 22 5.6.3. Items for Standardization . . . . . . . . . . . . . . 22
5.6.4. Binding Identity Assertions to JSEP Offer/Answer 5.6.4. Binding Identity Assertions to JSEP Offer/Answer
Transactions . . . . . . . . . . . . . . . . . . . . . 22 Transactions . . . . . . . . . . . . . . . . . . . . . 22
5.6.4.1. Input to Assertion Generation Process . . . . . . 22 5.6.4.1. Input to Assertion Generation Process . . . . . . 22
5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 23 5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 23
5.6.4.3. a=identity Attribute . . . . . . . . . . . . . . . 24
5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 24 5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 24
5.6.5.1. General Message Structure . . . . . . . . . . . . 24 5.6.5.1. General Message Structure . . . . . . . . . . . . 24
5.6.5.2. Errors . . . . . . . . . . . . . . . . . . . . . . 25 5.6.5.2. Errors . . . . . . . . . . . . . . . . . . . . . . 25
5.6.5.3. IdP Proxy Setup . . . . . . . . . . . . . . . . . 25 5.6.5.3. IdP Proxy Setup . . . . . . . . . . . . . . . . . 26
5.7. Security Considerations . . . . . . . . . . . . . . . . . 30 5.6.5.4. Verifying Assertions . . . . . . . . . . . . . . . 30
5.7.1. Communications Security . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Communications Security . . . . . . . . . . . . . . . . . 31
5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 32 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 33 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33
5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 33 6.4. IdP Authentication Mechanism . . . . . . . . . . . . . . . 34
5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 34 6.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 34
5.7.4.3. Privacy of IdP-generated identities and the 6.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . . 35
hosting site . . . . . . . . . . . . . . . . . . . 34 6.4.3. Privacy of IdP-generated identities and the
5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 34 hosting site . . . . . . . . . . . . . . . . . . . . . 35
5.7.4.5. Web Security Feature Interactions . . . . . . . . 34 6.4.4. Security of Third-Party IdPs . . . . . . . . . . . . . 36
5.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 35 6.4.5. Web Security Feature Interactions . . . . . . . . . . 36
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 6.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . . 36
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 36
7.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 36 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
7.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36 9.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 37
7.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 36 9.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 9.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 9.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Example IdP Bindings to Specific Protocols . . . . . 39 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 42 10.2. Informative References . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Example IdP Bindings to Specific Protocols . . . . . 41
A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45
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 17, line 25 skipping to change at page 17, line 25
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 [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
keying. Implementations MUST implement keying. Implementations MUST implement
[I-D.ietf-tsvwg-sctp-dtls-encaps]. [I-D.ietf-tsvwg-sctp-dtls-encaps].
All media channels MUST be secured via SRTP. Media traffic MUST NOT All media channels MUST be secured via SRTP. Media traffic MUST NOT
be sent over plain (unencrypted) RTP. DTLS-SRTP MUST be offered for be sent over plain (unencrypted) RTP; that is, implementations MUST
every media channel. WebRTC implements MUST NOT offer SDES or select NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP
it if offered. MUST be offered for every media channel. WebRTC implementations MUST
NOT offer SDES or select it if offered.
All data channels MUST be secured via DTLS. All data channels MUST be secured via DTLS.
[[OPEN ISSUE: Are these the right cipher suites?]] All All implementations MUST implement both DTLS 1.2 and DTLS 1.0, with
implementations MUST implement the following two cipher suites: the cipher suites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and the DTLS-SRTP protection SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD favor cipher
profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD favor suites which support PFS over non-PFS cipher suites and GCM over CBC
cipher suites which support PFS over non-PFS cipher suites. cipher suites. [[OPEN ISSUE: Should we require ECDHE? Waiting for
TLS WG Consensus.]]
API Requirement: The API MUST provide a mechanism to indicate that a API Requirement: The API MUST provide a mechanism to indicate that a
fresh DTLS key pair is to be generated for a specific call. This fresh DTLS key pair is to be generated for a specific call. This
is intended to allow for unlinkability. Note that there are also is intended to allow for unlinkability. Note that there are also
settings where it is attractive to use the same keying material settings where it is attractive to use the same keying material
repeatedly, especially those with key continuity-based repeatedly, especially those with key continuity-based
authentication. Unless the user specifically configures an authentication. Unless the user specifically configures an
external key pair, different key pairs MUST be used for each external key pair, different key pairs MUST be used for each
origin. (This avoids creating a super-cookie.) origin. (This avoids creating a super-cookie.)
skipping to change at page 21, line 17 skipping to change at page 21, line 17
In order to provide security without trusting the calling site, the In order to provide security without trusting the calling site, the
PeerConnection component of the browser must interact directly with PeerConnection component of the browser must interact directly with
the IdP. The details of the mechanism are described in the W3C API the IdP. The details of the mechanism are described in the W3C API
specification, but the general idea is that the PeerConnection specification, but the general idea is that the PeerConnection
component downloads JS from a specific location on the IdP dictated component downloads JS from a specific location on the IdP dictated
by the IdP domain name. That JS (the "IdP proxy") runs in an by the IdP domain name. That JS (the "IdP proxy") runs in an
isolated security context within the browser and the PeerConnection isolated security context within the browser and the PeerConnection
talks to it via a secure message passing channel. talks to it via a secure message passing channel.
Note that there are two logically separate functions here: Note that there are two logically separate functions here:
o Identity assertion generation. o Identity assertion generation.
o Identity assertion verification. o Identity assertion verification.
The same IdP JS "endpoint" is used for both functions but of course a The same IdP JS "endpoint" is used for both functions but of course a
given IdP might behave differently and load new JS to perform one given IdP might behave differently and load new JS to perform one
function or the other. function or the other.
+------------------------------------+ +--------------------------------------+
| https://calling-site.example.com | | Browser |
| | | |
| | | +----------------------------------+ |
| | | | https://calling-site.example.com | |
| Calling JS Code | | | | |
| ^ | | | Calling JS Code | |
| | API Calls | | | ^ | |
| v | | +---------------|------------------+ |
| PeerConnection | | | API Calls |
| ^ | | v |
| | postMessage() | | PeerConnection |
| v | | ^ |
| +-------------------------+ | +---------------+ | | MessageChannel |
| | https://idp.example.org | | | | | +-----------|-------------+ | +---------------+
| | |<--------->| Identity | | | v | | | |
| | IdP JS | | | Provider | | | IdP Proxy |<-------->| Identity |
| | | | | | | | | | | Provider |
| +-------------------------+ | +---------------+ | | https://idp.example.org | | | |
| | | +-------------------------+ | +---------------+
+------------------------------------+ | |
+--------------------------------------+
When the PeerConnection object wants to interact with the IdP, the When the PeerConnection object wants to interact with the IdP, the
sequence of events is as follows: sequence of events is as follows:
1. The browser (the PeerConnection component) instantiates an IdP 1. The browser (the PeerConnection component) instantiates an IdP
proxy with its source at the IdP. This allows the IdP to load proxy with its source at the IdP. This allows the IdP to load
whatever JS is necessary into the proxy, which runs in the IdP's whatever JS is necessary into the proxy, which runs in the IdP's
security context. security context. The browser uses a MessageChannel
2. If the user is not already logged in, the IdP does whatever is
required to log them in, such as soliciting a username and [WebMessaging] to interact with the IdP proxy.
password. 2. Once the IdP is ready, the IdP proxy uses the MessageChannel to
3. Once the user is logged in, the IdP proxy notifies the browser notify the browser that it is ready.
that it is ready. 3. The browser and IdP proxy communicate using the MessageChannel
4. The browser and the IdP proxy communicate via a standardized using a standardized message exchange to create or verify
series of messages delivered via a MessageChannel [WebMessaging]. identity assertions.
For instance, the browser might request the IdP proxy to sign or
verify a given identity assertion.
This approach allows us to decouple the browser from any particular This approach allows us to decouple the browser from any particular
identity provider; the browser need only know how to load the IdP's identity provider; the browser need only know how to load the IdP's
JavaScript--which is deterministic from the IdP's identity--and the JavaScript--which is deterministic from the IdP's identity--and the
generic protocol for requesting and verifying assertions. The IdP generic protocol for requesting and verifying assertions. The IdP
provides whatever logic is necessary to bridge the generic protocol provides whatever logic is necessary to bridge the generic protocol
to the IdP's specific requirements. Thus, a single browser can to the IdP's specific requirements. Thus, a single browser can
support any number of identity protocols, including being forward support any number of identity protocols, including being forward
compatible with IdPs which did not exist at the time the browser was compatible with IdPs which did not exist at the time the browser was
written. written.
skipping to change at page 22, line 47 skipping to change at page 22, line 44
assertions were received. assertions were received.
The first two items are defined in this document. The final one is The first two items are defined in this document. The final one is
defined in the companion W3C WebRTC API specification [webrtc-api]. defined in the companion W3C WebRTC API specification [webrtc-api].
5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions 5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions
5.6.4.1. Input to Assertion Generation Process 5.6.4.1. Input to Assertion Generation Process
An identity assertion binds the user's identity (as asserted by the An identity assertion binds the user's identity (as asserted by the
IdP) to the JSEP offer/exchange transaction and specifically to the IdP) to the SDP offer/exchange transaction and specifically to the
media. In order to achieve this, the PeerConnection must provide the media. In order to achieve this, the PeerConnection must provide the
DTLS-SRTP fingerprint to be bound to the identity. This is provided DTLS-SRTP fingerprint to be bound to the identity. This is provided
as a JavaScript object (also known as a dictionary or hash) with a as a JavaScript object (also known as a dictionary or hash) with a
single "fingerprint" key, as shown below: single "fingerprint" key, as shown below:
{ {
"fingerprint": { "fingerprint": [ {
"algorithm": "sha-256", "algorithm": "sha-256",
"digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
} }, {
"algorithm": "sha-1",
"digest": "74:E9:76:C8:19:...:F4:45:6B"
} ]
} }
This object is encoded in a JSON [RFC4627] string for passing to the The "fingerprint" value is an array of objects. Each object in the
IdP. array contains "algorithm" and "digest" values, which correspond
directly to the algorithm and digest values in the "a=fingerprint"
The "algorithm" and "digest" values correspond directly to the line of the SDP [RFC4572].
algorithm and digest values in the a=fingerprint line of the SDP.
[RFC4572].
Note: this structure does not need to be interpreted by the IdP or Note: 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 the IdP 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 merely treats it as an opaque value to be attested to. Thus, new
parameters can be added to the assertion without modifying the IdP. parameters can be added to the assertion without modifying the IdP.
This object is encoded in a JSON [RFC4627] string for passing to the
IdP.
5.6.4.2. Carrying Identity Assertions 5.6.4.2. 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
message. This is done by adding a new a-line to the SDP, of the form message. This is done by adding a new a-line to the SDP, of the form
a=identity. The sole contents of this value are a base-64 encoded a=identity. The sole contents of this value are a base-64 encoded
[RFC4848] identity assertion. For example: [RFC4648] identity assertion. For example:
v=0 v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1 s=example1
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint:sha-1 \ a=fingerprint:sha-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=identity:\ a=identity:\
ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs\ IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg== aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
a=...
t=0 0 t=0 0
m=audio 6056 RTP/SAVP 0 m=audio 6056 RTP/SAVP 0
a=sendrecv a=sendrecv
... ...
Each identity attribute should be paired (and attests to) with an Each identity attribute should be paired (and attests to) with an
"a=fingerprint" attribute and therefore can exist either at the "a=fingerprint" attribute and therefore can exist either at the
session or media level. Multiple identity attributes may appear at session or media level. Multiple identity attributes may appear at
either level, though it is RECOMMENDED that implementations not do either level, though it is RECOMMENDED that implementations not do
this, because it becomes very unclear what security claim that they this, because it becomes very unclear what security claim that they
are making and the UI guidelines above become unclear. Browsers MAY are making and the UI guidelines above become unclear. Browsers MAY
choose refuse to display any identity indicators in the face of choose refuse to display any identity indicators in the face of
multiple identity attributes with different identities but SHOULD multiple identity attributes with different identities but SHOULD
process multiple attributes with the same identity as described process multiple attributes with the same identity as described
above. above.
TODO: write up paragraph on the consequences of multiple Multiple "a=fingerprint" values can be used to offer alternative
a=fingerprint attributes. certificates for a peer. The "a=identity" attribute MUST include all
fingerprint values that are included in "a=fingerprint" lines. This
ensures that the in-use certificate for a DTLS connection is in the
set of fingerprints returned from the IdP when verifying an
assertion. This MUST be enforced by an RP by ensuring that all
"a=fingerprint" attributes for a given media section are present in
the "VERIFY" response (see Section 5.6.5.4).
5.6.4.3. a=identity Attribute
The identity attribute is session level only. It contains an
identity assertion, encoded as a base-64 string [RFC4648].
The syntax of this SDP attribute is defined using Augmented BNF
[RFC5234]:
identity-attribute = "identity:" identity-assertion
[ SP identity-extension
*(";" [ SP ] identity-extension) ]
identity-assertion = base64
base64 = 1*(ALPHA / DIGIT / "+" / "/" / "=" )
identity-extension = extension-att-name [ "=" extension-att-value ]
extension-att-name = token
extension-att-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
; byte-string from [RFC4566] omitting ";"
No extensions are defined for this attribute.
5.6.5. IdP Interaction Details 5.6.5. IdP Interaction Details
5.6.5.1. General Message Structure 5.6.5.1. General Message Structure
Messages between the PeerConnection object and the IdP proxy are Messages between the PeerConnection object and the IdP proxy are
JavaScript objects, shown in examples using JSON [RFC4627]. For JavaScript objects, shown in examples using JSON [RFC4627]. For
instance, the PeerConnection would request a signature with the instance, the PeerConnection would request a signature with the
following "SIGN" message: following "SIGN" message:
skipping to change at page 26, line 15 skipping to change at page 26, line 46
5.6.5.3.1. Determining the IdP URI 5.6.5.3.1. 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 domain name: The IdP's domain name
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 IdP-specific string, but allows an IdP to implement a completely opaque IdP-specific string, but allows an IdP to
two protocols in parallel. This value may be the empty string. implement two protocols in parallel. This value may be the empty
string.
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, which is the IdP domain name. The authority MAY
contain a non-default port number. Any port number is removed contain a non-default port number. Any port number is removed
when determining if an asserted identity matches the name of the when determining if an asserted identity matches the name of the
IdP. The authority MUST NOT include a userinfo sub-component. IdP. The authority MUST NOT include a userinfo sub-component.
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
skipping to change at page 27, line 9 skipping to change at page 27, line 42
5.6.5.3.1.2. Relying Party 5.6.5.3.1.2. Relying Party
Unlike the AP, the RP need not have any particular relationship with Unlike the AP, the RP need not have any particular relationship with
the IdP. Rather, it needs to be able to process whatever assertion the IdP. Rather, it needs to be able to process whatever assertion
is provided by the AP. As the assertion contains the IdP's identity, is provided by the AP. As the assertion contains the IdP's identity,
the URI can be constructed directly from the assertion, and thus the the URI can be constructed directly from the assertion, and thus the
RP can directly verify the technical validity of the assertion with RP can directly verify the technical validity of the assertion with
no user interaction. Authoritative assertions need only be no user interaction. Authoritative assertions need only be
verifiable. Third-party assertions also MUST be verified against verifiable. Third-party assertions also MUST be verified against
local policy, as described in Section 5.6.5.3.3.1. local policy, as described in Section 5.6.5.4.1.
5.6.5.3.2. Requesting Assertions 5.6.5.3.2. Requesting Assertions
In order to request an assertion, the PeerConnection sends a "SIGN" In order to request an assertion, the PeerConnection sends a "SIGN"
message. Aside from the mandatory fields, this message has a message. Aside from the mandatory fields, this message has a
"message" field containing a string. The string contains a JSON- "message" field containing a string. The string contains a JSON-
encoded object containing certificate fingerprints but are treated as encoded object containing certificate fingerprints but are treated as
opaque from the perspective of the IdP. opaque from the perspective of the IdP.
An application can optionally provide a user identifier when
specifying an IdP. This value is a hint that the IdP can use to
select amongst multiple identities, or to avoid providing assertions
for unwanted identities. The user identifier hint is passed to the
IdP in a "username" field alongside the "message". The "username" is
a string that has no meaning to any entity other than the IdP, it can
contain any data the IdP needs in order to correctly generate an
assertion.
A successful response to a "SIGN" message contains a "message" field A successful response to a "SIGN" message contains a "message" field
which is a JavaScript dictionary consisting of two fields: which is a JavaScript dictionary consisting of two fields:
idp: A dictionary containing the domain name of the provider and the idp: A dictionary containing the domain name of the provider and the
protocol string. protocol string.
assertion: An opaque value containing the assertion itself. This is assertion: An opaque value containing the assertion itself. This is
only interpretable by the IdP or its proxy. only interpretable by the IdP or its proxy.
Figure 6 shows an example transaction, with the message "abcde..." Figure 6 shows an example transaction, with the message "abcde..."
(remember, the messages are opaque at this layer) being signed and (remember, the messages are opaque at this layer) being signed and
skipping to change at page 28, line 10 skipping to change at page 28, line 33
presumably been digitally signed/MACed in some way that the IdP can presumably been digitally signed/MACed in some way that the IdP can
later verify it, but this is an implementation detail and out of later verify it, but this is an implementation detail and out of
scope of this document. Line breaks are inserted solely for scope of this document. Line breaks are inserted solely for
readability. readability.
PeerConnection -> IdP proxy: PeerConnection -> IdP proxy:
{ {
"type": "SIGN", "type": "SIGN",
"id": "1", "id": "1",
"origin": "https://calling-service.example.com/", "origin": "https://calling-service.example.com/",
"message": "abcdefghijklmnopqrstuvwyz" "message": "abcdefghijklmnopqrstuvwyz",
"username": "bob"
} }
IdPProxy -> PeerConnection: IdPProxy -> PeerConnection:
{ {
"type": "SUCCESS", "type": "SUCCESS",
"id": "1", "id": "1",
"message": { "message": {
"idp":{ "idp":{
"domain": "example.org" "domain": "example.org",
"protocol": "bogus" "protocol": "bogus"
}, },
"assertion": "{\"identity\":\"bob@example.org\", "assertion": "{\"identity\":\"bob@example.org\",
\"contents\":\"abcdefghijklmnopqrstuvwyz\", \"contents\":\"abcdefghijklmnopqrstuvwyz\",
\"signature\":\"010203040506\"}" \"signature\":\"010203040506\"}"
} }
} }
Figure 6: Example assertion request Figure 6: Example assertion request
The "message" structure is serialized into JSON, base64-encoded The "message" structure is serialized into JSON, base64-encoded
[RFC4848], and placed in an "a=identity" attribute. [RFC4648], and placed in an "a=identity" attribute.
5.6.5.3.3. Verifying Assertions 5.6.5.3.3. Managing User Login
In order to generate an identity assertion, the IdP needs proof of
the user's identity. It is common practice to authenticate users
(using passwords or multi-factor authentication), then use Cookies
[RFC6265] or HTTP authentication [RFC2617] for subsequent exchanges.
The IdP proxy is able to access cookies, HTTP authentication or other
persistent session data because it operates in the security context
of the IdP origin. Therefore, if a user is logged in, the IdP could
have all the information needed to generate an assertion.
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
information before generating the assertion. If the IdP wants to
interact with the user before generating an assertion, the IdP proxy
can respond with a "LOGINNEEDED" message.
IdPProxy -> PeerConnection:
{
"type": "LOGINNEEDED",
"id": "1",
"error": "...a message explaining the reason for failure...",
"loginUrl": "https://example.org/login?context=e982606f4fd5"
}
Figure 7: User interaction needed response
The "loginUrl" field of the "LOGINNEEDED" response contains a URL.
The PeerConnection provides an error event (or similar) to the
calling site that includes this URL.
A calling site is then able to load the provided URL in an IFRAME in
order to trigger the required user interactions. Once any user
interactions are complete, the IFRAME MUST send a postMessage
[WebMessaging] to its containing window indicating completion. Any
message is sufficient for this purpose, the "source" parameter
identifies the originating IFRAME.
In all other respects, "LOGINNEEDED" can be treated as an "ERROR"
message.
5.6.5.4. Verifying Assertions
In order to verify an assertion, an RP sends a "VERIFY" message to In order to verify an assertion, an RP sends a "VERIFY" message to
the IdP proxy containing the assertion supplied by the AP in the the IdP proxy containing the assertion supplied by the AP in the
"message" field. "message" field.
The IdP proxy verifies the assertion. Depending on the identity The IdP proxy verifies the assertion. Depending on the identity
protocol, the proxy might contact the IdP server or other servers. protocol, the proxy might contact the IdP server or other servers.
For instance, an OAuth-based protocol will likely require using the For instance, an OAuth-based protocol will likely require using the
IdP as an oracle, whereas with BrowserID the IdP proxy can likely IdP as an oracle, whereas with BrowserID the IdP proxy can likely
verify the signature on the assertion without contacting the IdP, verify the signature on the assertion without contacting the IdP,
skipping to change at page 29, line 4 skipping to change at page 30, line 21
The IdP proxy verifies the assertion. Depending on the identity The IdP proxy verifies the assertion. Depending on the identity
protocol, the proxy might contact the IdP server or other servers. protocol, the proxy might contact the IdP server or other servers.
For instance, an OAuth-based protocol will likely require using the For instance, an OAuth-based protocol will likely require using the
IdP as an oracle, whereas with BrowserID the IdP proxy can likely IdP as an oracle, whereas with BrowserID the IdP proxy can likely
verify the signature on the assertion without contacting the IdP, verify the signature on the assertion without contacting the IdP,
provided that it has cached the IdP's public key. provided that it has cached the IdP's public key.
Regardless of the mechanism, if verification succeeds, a successful Regardless of the mechanism, if verification succeeds, a successful
response from the IdP proxy MUST contain a message field consisting response from the IdP proxy MUST contain a message field consisting
of a object with the following fields: of a object with the following fields:
identity: The identity of the AP from the IdP's perspective. identity: The identity of the AP from the IdP's perspective.
Details of this are provided in Section 5.6.5.3.3.1. Details of this are provided in Section 5.6.5.4.1.
contents: The original unmodified string provided by the AP in the contents: The original unmodified string provided by the AP in the
original SIGN request. original SIGN request.
Figure 7 shows an example transaction. Line breaks are inserted Figure 8 shows an example transaction. Line breaks are inserted
solely for readability. solely for readability.
PeerConnection -> IdP Proxy: PeerConnection -> IdP Proxy:
{ {
"type": "VERIFY", "type": "VERIFY",
"id": 2, "id": 2,
"origin": "https://calling-service.example.com/", "origin": "https://calling-service.example.com/",
"message": "{\"identity\":\"bob@example.org\", "message": "{\"identity\":\"bob@example.org\",
\"contents\":\"abcdefghijklmnopqrstuvwyz\", \"contents\":\"abcdefghijklmnopqrstuvwyz\",
\"signature\":\"010203040506\"}" \"signature\":\"010203040506\"}"
skipping to change at page 29, line 33 skipping to change at page 30, line 49
IdP Proxy -> PeerConnection: IdP Proxy -> PeerConnection:
{ {
"type": "SUCCESS", "type": "SUCCESS",
"id": 2, "id": 2,
"message": { "message": {
"identity": "bob@example.org", "identity": "bob@example.org",
"contents": "abcdefghijklmnopqrstuvwyz" "contents": "abcdefghijklmnopqrstuvwyz"
} }
} }
Figure 7: Example verification request Figure 8: Example verification request
5.6.5.3.3.1. Identity Formats 5.6.5.4.1. Identity Formats
Identities passed from the IdP proxy to the PeerConnection are passed Identities passed from the IdP proxy to the PeerConnection are passed
in the "identity" field. This field MUST consist of a string in the "identity" field. This field MUST consist of a string
representing the user's identity. This string is in the form representing the user's identity. This string is in the form
"<user>@<domain>", where "user" consists of any character except '@', "<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].
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
skipping to change at page 30, line 17 skipping to change at page 31, line 34
2. local policy is configured to trust this IdP domain for the 2. local policy is configured to trust this IdP domain for the
RHS of the identity string. RHS of the identity string.
Sites which have identities that do not fit into the RFC822 style Sites which have identities that do not fit into the RFC822 style
(for instance, identifiers that are simple numeric values, or values (for instance, identifiers that are simple numeric values, or values
that contain '@' characters) SHOULD convert them to this form by that contain '@' characters) SHOULD convert them to this form by
escaping illegal characters and appending their IdP domain (e.g., escaping illegal characters and appending their IdP domain (e.g.,
user%40133@identity.example.com), thus ensuring that they are user%40133@identity.example.com), thus ensuring that they are
authoritative for the identity. authoritative for the identity.
5.7. Security Considerations 6. 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.
5.7.1. Communications Security 6.1. Communications Security
While this document favors DTLS-SRTP, it permits a variety of While this document favors DTLS-SRTP, it permits a variety of
communications security mechanisms and thus the level of communications security mechanisms and thus the level of
communications security actually provided varies considerably. Any communications security actually provided varies considerably. Any
pair of implementations which have multiple security mechanisms in pair of implementations which have multiple security mechanisms in
common are subject to being downgraded to the weakest of those common common are subject to being downgraded to the weakest of those common
mechanisms by any attacker who can modify the signaling traffic. If mechanisms by any attacker who can modify the signaling traffic. If
communications are over HTTP, this means any on-path attacker. If communications are over HTTP, this means any on-path attacker. If
communications are over HTTPS, this means the signaling server. communications are over HTTPS, this means the signaling server.
Implementations which wish to avoid downgrade attack should only Implementations which wish to avoid downgrade attack should only
skipping to change at page 31, line 25 skipping to change at page 32, line 43
JS, thus violating the security guarantees otherwise provided by the JS, thus violating the security guarantees otherwise provided by the
IdP mechanism. Note that it is not sufficient merely to deny the IdP mechanism. Note that it is not sufficient merely to deny the
content JS direct access to the keys, as some have suggested doing content JS direct access to the keys, as some have suggested doing
with the WebCrypto API. [webcrypto]. The JS must also not be allowed with the WebCrypto API. [webcrypto]. The JS must also not be allowed
to perform operations that would be valid for a DTLS endpoint. By to perform operations that would be valid for a DTLS endpoint. By
far the safest approach is simply to deny the ability to perform any far the safest approach is simply to deny the ability to perform any
operations that depend on secret information associated with the key. operations that depend on secret information associated with the key.
Operations that depend on public information, such as exporting the Operations that depend on public information, such as exporting the
public key are of course safe. public key are of course safe.
5.7.2. Privacy 6.2. Privacy
The requirements in this document are intended to allow: The requirements in this document are intended to allow:
o Users to participate in calls without revealing their location. o Users to participate in calls without revealing their location.
o Potential callees to avoid revealing their location and even o Potential callees to avoid revealing their location and even
presence status prior to agreeing to answer a call. presence status prior to agreeing to answer a call.
However, these privacy protections come at a performance cost in However, these privacy protections come at a performance cost in
terms of using TURN relays and, in the latter case, delaying ICE. terms of using TURN relays and, in the latter case, delaying ICE.
Sites SHOULD make users aware of these tradeoffs. Sites SHOULD make users aware of these tradeoffs.
skipping to change at page 32, line 4 skipping to change at page 33, line 22
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 [I-D.ietf-avtcore-6222bis].
5.7.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.
Consider the case of a call center which accepts calls via RTCWeb. Consider the case of a call center which accepts calls via RTCWeb.
An attacker proxies the call center's front-end and arranges for An attacker proxies the call center's front-end and arranges for
skipping to change at page 33, line 5 skipping to change at page 34, line 22
the victim to make a call and then uses its control of other users the victim to make a call and then uses its control of other users
browsers to get them to attempt a call to someone. It then browsers to get them to attempt a call to someone. It then
translates their offers into apparent answers to the victim, which translates their offers into apparent answers to the victim, which
looks like large-scale parallel forking. The victim still responds looks like large-scale parallel forking. The victim still responds
to ICE responses and now the browsers all try to send media to the to ICE responses and now the browsers all try to send media to the
victim. Implementations can defend themselves from this attack by victim. Implementations can defend themselves from this attack by
only responding to ICE Binding Requests for a limited number of only responding to ICE Binding Requests for a limited number of
remote ufrags (this is the reason for the requirement that the JS not remote ufrags (this is the reason for the requirement that the JS not
be able to control the ufrag and password). be able to control the ufrag and password).
[I-D.ietf-rtcweb-rtp-usage] Section 13 documents a number of
potential RTCP-based DoS attacks and countermeasures.
Note that attacks based on confusing one end or the other about Note that attacks based on confusing one end or the other about
consent are possible even in the face of the third-party identity consent are possible even in the face of the third-party identity
mechanism as long as major parts of the signaling messages are not mechanism as long as major parts of the signaling messages are not
signed. On the other hand, signing the entire message severely signed. On the other hand, signing the entire message severely
restricts the capabilities of the calling application, so there are restricts the capabilities of the calling application, so there are
difficult tradeoffs here. difficult tradeoffs here.
5.7.4. IdP Authentication Mechanism 6.4. IdP Authentication Mechanism
This mechanism relies for its security on the IdP and on the This mechanism relies for its security on the IdP and on the
PeerConnection correctly enforcing the security invariants described PeerConnection correctly enforcing the security invariants described
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.
5.7.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 o from creating their the browser, so nothing stops a Web attacker o from creating their
own IFRAME, loading the IdP proxy HTML/JS, and requesting a own IFRAME, loading the IdP proxy HTML/JS, and requesting a
signature. In order to prevent this attack, we require that all signature. In order to prevent this attack, we require that all
signatures be tied to a specific origin ("rtcweb://...") which cannot signatures be tied to a specific origin ("rtcweb://...") which cannot
be produced by content JavaScript. Thus, while an attacker can be produced by content JavaScript. Thus, while an attacker can
instantiate the IdP proxy, they cannot send messages from an instantiate the IdP proxy, they cannot send messages from an
appropriate origin and so cannot create acceptable assertions. I.e., appropriate origin and so cannot create acceptable assertions. I.e.,
the assertion request must have come from the browser. This origin the assertion request must have come from the browser. This origin
skipping to change at page 34, line 6 skipping to change at page 35, line 27
browsers, and therefore those access restrictions cannot be assumed. 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. However,
attaching one's identity to a key that the user does not control does attaching one's identity to a key that the user does not control does
not appear to provide substantial leverage to an attacker, so a proof not appear to provide substantial leverage to an attacker, so a proof
of possession is omitted for simplicity. of possession is omitted for simplicity.
5.7.4.2. IdP Well-known URI 6.4.2. IdP Well-known URI
As described in Section 5.6.5.3.1 the IdP proxy HTML/JS landing page As described in Section 5.6.5.3.1 the IdP proxy HTML/JS landing page
is located at a well-known URI based on the IdP's domain name. This is 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.
5.7.4.3. Privacy of IdP-generated identities and the hosting site 6.4.3. Privacy of IdP-generated identities and the hosting site
Depending on the structure of the IdP's assertions, the calling site Depending on the structure of the IdP's assertions, the calling site
may learn the user's identity from the perspective of the IdP. In may learn the user's identity from the perspective of the IdP. In
many cases this is not an issue because the user is authenticating to many cases this is not an issue because the user is authenticating to
the site via the IdP in any case, for instance when the user has the site via the IdP in any case, for instance when the user has
logged in with Facebook Connect and is then authenticating their call logged in with Facebook Connect and is then authenticating their call
with a Facebook identity. However, in other case, the user may not with a Facebook identity. However, in other case, the user may not
have already revealed their identity to the site. In general, IdPs have already revealed their identity to the site. In general, IdPs
SHOULD either verify that the user is willing to have their identity SHOULD either verify that the user is willing to have their identity
revealed to the site (e.g., through the usual IdP permissions dialog) revealed to the site (e.g., through the usual IdP permissions dialog)
or arrange that the identity information is only available to known or arrange that the identity information is only available to known
RPs (e.g., social graph adjacencies) but not to the calling site. RPs (e.g., social graph adjacencies) but not to the calling site.
The "origin" field of the signature request can be used to check that The "origin" field of the signature request can be used to check that
the user has agreed to disclose their identity to the calling site; the user has agreed to disclose their identity to the calling site;
because it is supplied by the PeerConnection it can be trusted to be because it is supplied by the PeerConnection it can be trusted to be
correct. correct.
5.7.4.4. Security of Third-Party IdPs 6.4.4. Security of Third-Party IdPs
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.
5.7.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.
5.7.4.5.1. Popup Blocking 6.4.5.1. Popup Blocking
If the user is not already logged into the IdP, the IdP proxy may The IdP proxy is unable to generate popup windows, dialogs or any
need to pop up a top level window in order to prompt the user for other form of user interactions. This prevents the IdP proxy from
their authentication information (it is bad practice to do this in an being used to circumvent user interaction. The "LOGINNEEDED" message
IFRAME inside the window because then users have no way to determine allows the IdP proxy to inform the calling site of a need for user
the destination for their password). If the user's browser is login, providing the information necessary to satisfy this
configured to prevent popups, this may fail (depending on the exact requirement without resorting to direct user interaction from the IdP
algorithm that the popup blocker uses to suppress popups). It may be proxy itself.
necessary to provide a standardized mechanism to allow the IdP proxy
to request popping of a login window. Note that care must be taken
here to avoid PeerConnection becoming a general escape hatch from
popup blocking. One possibility would be to only allow popups when
the user has explicitly registered a given IdP as one of theirs (this
is only relevant at the AP side in any case).
5.7.4.5.2. Third Party Cookies 6.4.5.2. Third Party Cookies
Some browsers allow users to block third party cookies (cookies Some browsers allow users to block third party cookies (cookies
associated with origins other than the top level page) for privacy associated with origins other than the top level page) for privacy
reasons. Any IdP which uses cookies to persist logins will be broken reasons. Any IdP which uses cookies to persist logins will be broken
by third-party cookie blocking. One option is to accept this as a by third-party cookie blocking. One option is to accept this as a
limitation; another is to have the PeerConnection object disable limitation; another is to have the PeerConnection object disable
third-party cookie blocking for the IdP proxy. third-party cookie blocking for the IdP proxy.
5.8. IANA Considerations 7. IANA Considerations
[TODO: IANA registration for Identity header. Or should this be in This specification defines the "identity" SDP attribute per the
MMUSIC?] procedures of Section 8.2.4 of [RFC4566]. The required information
for the registration is included here:
Contact Name: Eric Rescorla (ekr@rftm.com)
Attribute Name: identity
Long Form: identity
Type of Attribute: session-level
Charset Considerations: This attribute is not subject to the charset
attribute.
Purpose: This attribute carries an identity assertion, binding an
identity to the transport-level security session.
Appropriate Values: See Section 5.6.4.3 of RFCXXXX [[Editor Note:
This document.
6. 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.
7. Changes 9. Changes
7.1. Changes since -06 9.1. 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.
7.2. Changes since -05 9.2. 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.
7.3. Changes since -03 9.3. 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.
7.4. Changes since -03 9.4. Changes since -03
7.5. Changes since -02 9.5. 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
o Retarget the continuing consent section to assume Binding Requests o Retarget the continuing consent section to assume Binding Requests
o Added some more privacy and linkage text in various places. o Added some more privacy and linkage text in various places.
o Editorial improvements o Editorial improvements
8. References 10. References
8.1. Normative References 10.1. Normative References
[I-D.ietf-avtcore-6222bis] [I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), July 2013. (work in progress), July 2013.
[I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-15 (work in progress),
May 2014.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", Rescorla, E., "Security Considerations for WebRTC",
draft-ietf-rtcweb-security-06 (work in progress), draft-ietf-rtcweb-security-06 (work in progress),
January 2014. January 2014.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", Encapsulation of SCTP Packets",
draft-ietf-tsvwg-sctp-dtls-encaps-03 (work in progress), draft-ietf-tsvwg-sctp-dtls-encaps-04 (work in progress),
February 2014. May 2014.
[I-D.muthu-behave-consent-freshness] [I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
for Consent Freshness", for Consent Freshness",
draft-muthu-behave-consent-freshness-04 (work in draft-muthu-behave-consent-freshness-04 (work in
progress), July 2013. progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Using URIs and the Dynamic Delegation Discovery Service Encodings", RFC 4648, October 2006.
(DDDS)", RFC 4848, April 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
April 2010. April 2010.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
skipping to change at page 38, line 44 skipping to change at page 40, line 34
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 Available at
http://dev.w3.org/2011/webrtc/editor/webrtc.html http://dev.w3.org/2011/webrtc/editor/webrtc.html
8.2. Informative References 10.2. Informative References
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session Uberti, J. and C. Jennings, "Javascript Session
Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work
in progress), February 2014. in progress), February 2014.
[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, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011. RFC 6455, December 2011.
[XmlHttpRequest] [XmlHttpRequest]
van Kesteren, A., "XMLHttpRequest Level 2". van Kesteren, A., "XMLHttpRequest Level 2", January 2012.
Appendix A. Example IdP Bindings to Specific Protocols Appendix A. Example IdP Bindings to Specific Protocols
[[TODO: These still need some cleanup.]] [[TODO: These still need some cleanup.]]
This section provides some examples of how the mechanisms described This section provides some examples of how the mechanisms described
in this document could be used with existing authentication protocols in this document could be used with existing authentication protocols
such as BrowserID or OAuth. Note that this does not require browser- such as BrowserID or OAuth. Note that this does not require browser-
level support for either protocol. Rather, the protocols can be fit level support for either protocol. Rather, the protocols can be fit
into the generic framework. (Though BrowserID in particular works into the generic framework. (Though BrowserID in particular works
 End of changes. 69 change blocks. 
149 lines changed or deleted 259 lines changed or added

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