draft-ietf-rtcweb-security-arch-04.txt   draft-ietf-rtcweb-security-arch-05.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track October 22, 2012 Intended status: Standards Track October 22, 2012
Expires: April 25, 2013 Expires: April 25, 2013
RTCWEB Security Architecture RTCWEB Security Architecture
draft-ietf-rtcweb-security-arch-04 draft-ietf-rtcweb-security-arch-05
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 (e.g communications within user-agents using web technologies (e.g
JavaScript). The major use cases for RTCWEB technology are real-time JavaScript). The major use cases for RTCWEB technology are real-time
audio and/or video calls, Web conferencing, and direct data transfer. audio and/or video calls, Web conferencing, and direct data transfer.
Unlike most conventional real-time systems (e.g., SIP-based soft Unlike most conventional real-time systems (e.g., SIP-based soft
phones) RTCWEB communications are directly controlled by some Web phones) RTCWEB communications are directly controlled by some Web
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6
3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8
4.2. Media Consent Verification . . . . . . . . . . . . . . . . 10 4.2. Media Consent Verification . . . . . . . . . . . . . . . . 10
4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 11 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Communications and Consent Freshness . . . . . . . . . . . 11 4.4. Communications and Consent Freshness . . . . . . . . . . . 11
5. Detailed Technical Description . . . . . . . . . . . . . . . . 11 5. Detailed Technical Description . . . . . . . . . . . . . . . . 11
5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 11 5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 11
5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 12 5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 12
5.3. Communications Consent . . . . . . . . . . . . . . . . . . 14 5.3. Communications Consent . . . . . . . . . . . . . . . . . . 13
5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 14 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 14
5.5. Communications Security . . . . . . . . . . . . . . . . . 15 5.5. Communications Security . . . . . . . . . . . . . . . . . 15
5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 16 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 16
5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 17 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 17
5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 19 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 18
5.6.3. Binding Identity Assertions to JSEP Offer/Answer 5.6.3. Items for Standardization . . . . . . . . . . . . . . 20
5.6.4. Binding Identity Assertions to JSEP Offer/Answer
Transactions . . . . . . . . . . . . . . . . . . . . . 20 Transactions . . . . . . . . . . . . . . . . . . . . . 20
5.6.3.1. Input to Assertion Generation Process . . . . . . 20 5.6.4.1. Input to Assertion Generation Process . . . . . . 20
5.6.3.2. Carrying Identity Assertions . . . . . . . . . . . 21 5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 21
5.6.4. IdP Interaction Details . . . . . . . . . . . . . . . 21 5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 21
5.6.4.1. General Message Structure . . . . . . . . . . . . 21 5.6.5.1. General Message Structure . . . . . . . . . . . . 21
5.6.4.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 22 5.6.5.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 22
5.7. Security Considerations . . . . . . . . . . . . . . . . . 27 5.7. Security Considerations . . . . . . . . . . . . . . . . . 27
5.7.1. Communications Security . . . . . . . . . . . . . . . 27 5.7.1. Communications Security . . . . . . . . . . . . . . . 27
5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 28 5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 29
5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 29 5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 30
5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 29 5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 30
5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 30 5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 30
5.7.4.3. Privacy of IdP-generated identities and the 5.7.4.3. Privacy of IdP-generated identities and the
hosting site . . . . . . . . . . . . . . . . . . . 30 hosting site . . . . . . . . . . . . . . . . . . . 30
5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 30 5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 31
5.7.4.5. Web Security Feature Interactions . . . . . . . . 30 5.7.4.5. Web Security Feature Interactions . . . . . . . . 31
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
7. Changes since -03 . . . . . . . . . . . . . . . . . . . . . . 31 7. Changes since -03 . . . . . . . . . . . . . . . . . . . . . . 32
8. Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 31 8. Changes since -03 . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
Appendix A. Example IdP Bindings to Specific Protocols . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Example IdP Bindings to Specific Protocols . . . . . 34
A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 34
A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
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 real-time communications tasked with standardizing protocols for real-time communications
between Web browsers. The major use cases for RTCWEB technology are between Web browsers. The major use cases for RTCWEB 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) RTCWEB communications are directly based[RFC3261] soft phones) RTCWEB communications are directly
controlled by some Web server, as shown in Figure 1. controlled by some Web server, as shown in Figure 1.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
have a functional system. Other network elements fall into two have a functional system. Other network elements fall into two
categories: those which can be authenticated by the browser and thus categories: those which can be authenticated by the browser and thus
are partly trusted--though to the minimum extent necessary--and those are partly trusted--though to the minimum extent necessary--and those
which cannot be authenticated and thus are untrusted. This is a which cannot be authenticated and thus are untrusted. This is a
natural extension of the end-to-end principle. natural extension of the end-to-end principle.
3.1. Authenticated Entities 3.1. Authenticated Entities
There are two major classes of authenticated entities in the system: There are two major classes of authenticated entities in the system:
o Calling services: Web sites whose origin we can verify (in o Calling services: Web sites whose origin we can verify (optimally
practice this means HTTPS). via HTTPS, but in some cases because we are on a topologically
restricted network, such as behind a firewall).
o Other users: RTCWEB peers whose origin we can verify o Other users: RTCWEB peers whose origin we can verify
cryptographically (optimally via DTLS-SRTP). cryptographically (optimally via DTLS-SRTP).
Note that merely being authenticated does not make these entities Note that merely being authenticated does not make these entities
trusted. For instance, just because we can verify that trusted. For instance, just because we can verify that
https://www.evil.org/ is owned by Dr. Evil does not mean that we can https://www.evil.org/ is owned by Dr. Evil does not mean that we can
trust Dr. Evil to access our camera and microphone. However, it trust Dr. Evil to access our camera and microphone. However, it
gives the user an opportunity to determine whether he wishes to trust gives the user an opportunity to determine whether he wishes to trust
Dr. Evil or not; after all, if he desires to contact Dr. Evil Dr. Evil or not; after all, if he desires to contact Dr. Evil
(perhaps to arrange for ransom payment), it's safe to temporarily (perhaps to arrange for ransom payment), it's safe to temporarily
skipping to change at page 9, line 21 skipping to change at page 9, line 21
two MediaStreams, one connected to an audio input and one connected two MediaStreams, one connected to an audio input and one connected
to a video input. At this point the first security check is to a video input. At this point the first security check is
required: untrusted origins are not allowed to access the camera and required: untrusted origins are not allowed to access the camera and
microphone. In this case, because Alice is a long-term user of the microphone. In this case, because Alice is a long-term user of the
calling service, she has made a permissions grant (i.e., a setting in calling service, she has made a permissions grant (i.e., a setting in
the browser) to allow the calling service to access her camera and the browser) to allow the calling service to access her camera and
microphone any time it wants. The browser checks this setting when microphone any time it wants. The browser checks this setting when
the camera and microphone requests are made and thus allows them. the camera and microphone requests are made and thus allows them.
In the current W3C API, once some streams have been added, Alice's In the current W3C API, once some streams have been added, Alice's
browser + JS generates a signaling message The format of this data is browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep]
currently undefined. It may be a complete message as defined by ROAP contianing:
[I-D.jennings-rtcweb-signaling] or separate media description and
transport messages as defined in [I-D.ietf-rtcweb-jsep] or may be
assembled piecemeal by the JS. In either case, it will contain:
o Media channel information o Media channel information
o ICE candidates o ICE candidates
o A fingerprint attribute binding the communication to Alice's o A fingerprint attribute binding the communication to Alice's
public key [RFC5763] public key [RFC5763]
[Note that it is currently unclear where JSEP will eventually put Prior to sending out the signaling message, the PeerConnection code
this information, in the SDP or in the transport info.] Prior to contacts the identity service and obtains an assertion binding
sending out the signaling message, the PeerConnection code contacts Alice's identity to her fingerprint. The exact details depend on the
the identity service and obtains an assertion binding Alice's
identity to her fingerprint. The exact details depend on the
identity service (though as discussed in Section 5.6 PeerConnection identity service (though as discussed in Section 5.6 PeerConnection
can be agnostic to them), but for now it's easiest to think of as a can be agnostic to them), but for now it's easiest to think of as a
BrowserID assertion. The assertion may bind other information to the BrowserID assertion. The assertion may bind other information to the
identity besides the fingerprint, but at minimum it needs to bind the identity besides the fingerprint, but at minimum it needs to bind the
fingerprint. fingerprint.
This message is sent to the signaling server, e.g., by XMLHttpRequest This message is sent to the signaling server, e.g., by XMLHttpRequest
[XmlHttpRequest] or by WebSockets [RFC6455] The signaling server [XmlHttpRequest] or by WebSockets [RFC6455] The signaling server
processes the message from Alice's browser, determines that this is a processes the message from Alice's browser, determines that this is a
call to Bob and sends a signaling message to Bob's browser (again, call to Bob and sends a signaling message to Bob's browser (again,
skipping to change at page 11, line 44 skipping to change at page 11, line 36
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. ICE specifies periodic STUN to receive her communications. ICE specifies periodic STUN
keepalizes but only if media is not flowing. Because the consent keepalizes but only if media is not flowing. Because the consent
issue is more difficult here, we require RTCWeb implementations to issue is more difficult here, we require RTCWeb implementations to
periodically send keepalives. As described in Section 5.3, these periodically send keepalives. As described in Section 5.3, these
keepalives MUST be based on the consent freshness mechanism specified keepalives MUST be based on the consent freshness mechanism specified
in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no
new ICEchannels can be established, then the session is terminated. new ICE channels can be established, then the 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 RTCWEB is the origin [RFC6454]. The basic unit of permissions for RTCWEB 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 7 skipping to change at page 12, line 44
refuse all permissions grants for HTTP origins, but it is RECOMMENDED refuse all permissions grants for HTTP origins, but it is RECOMMENDED
that currently they support one-time camera/microphone access. that currently they support one-time camera/microphone access.
In addition, they SHOULD support requests for access to a single In addition, they SHOULD support requests for access to a single
communicating peer. E.g., "Call customerservice@ford.com". Browsers communicating peer. E.g., "Call customerservice@ford.com". Browsers
servicing such requests SHOULD clearly indicate that identity to the servicing such requests SHOULD clearly indicate that identity to the
user when asking for permission. user when asking for permission.
API Requirement: The API MUST provide a mechanism for the requesting API Requirement: The API MUST provide a mechanism for the requesting
JS to indicate which of these forms of permissions it is JS to indicate which of these forms of permissions it is
requesting. This allows the client to know what sort of user requesting. This allows the browser client to know what sort of
interface experience to provide, i.e., to allow the client to user interface experience to provide to the user, including what
clearly indicate to the user what he is agreeing to. In permissions to request from the user and hence what to enforce
particular, browsers might display a non-invasive door hanger later. For instance, browsers might display a non-invasive door
("some features of this site may not work..." when asking for hanger ("some features of this site may not work..." when asking
long-term permissions) but a more invasive UI ("here is your own for long-term permissions) but a more invasive UI ("here is your
video") for single-call permissions. The API MAY grant weaker own video") for single-call permissions. The API MAY grant weaker
permissions than the JS asked for if the user chooses to authorize permissions than the JS asked for if the user chooses to authorize
only those permissions, but if it intends to grant stronger ones only those permissions, but if it intends to grant stronger ones
it SHOULD display the appropriate UI for those permissions and it SHOULD display the appropriate UI for those permissions and
MUST clearly indicate what permissions are being requested. MUST clearly indicate what permissions are being requested.
API Requirement: The API MUST provide a mechanism for the requesting API Requirement: The API MUST provide a mechanism for the requesting
JS to relinquish the ability to see or modify the media (e.g., via JS to relinquish the ability to see or modify the media (e.g., via
MediaStream.record()). Combined with secure authentication of the MediaStream.record()). Combined with secure authentication of the
communicating peer, this allows a user to be sure that the calling communicating peer, this allows a user to be sure that the calling
site is not accessing or modifying their conversion. site is not accessing or modifying their conversion.
skipping to change at page 14, line 12 skipping to change at page 13, line 50
address book (this only works with address book integration, of address book (this only works with address book integration, of
course). course).
Implementations SHOULD also provide a different user interface Implementations SHOULD also provide a different user interface
indication when calls are in progress to users whose identities are indication when calls are in progress to users whose identities are
directly verifiable. Section 5.5 provides more on this. directly verifiable. Section 5.5 provides more on this.
5.3. Communications Consent 5.3. Communications Consent
Browser client implementations of RTCWEB MUST implement ICE. Server Browser client implementations of RTCWEB MUST implement ICE. Server
gateway implementations which operate only at public IP addresses may gateway implementations which operate only at public IP addresses
implement ICE-Lite instead of ICE but MUST implement one of the two. MUST implement either full ICE or ICE-Lite.
Browser implementations MUST verify reachability via ICE prior to Browser implementations MUST verify reachability via ICE prior to
sending any non-ICE packets to a given destination. Implementations sending any non-ICE packets to a given destination. Implementations
MUST NOT provide the ICE transaction ID to JavaScript during the MUST NOT provide the ICE transaction ID to JavaScript during the
lifetime of the transaction (i.e., during the period when the ICE lifetime of the transaction (i.e., during the period when the ICE
stack would accept a new response for that transaction). [Note: stack would accept a new response for that transaction). [Note:
this document takes no position on the split between ICE in JS and this document takes no position on the split between ICE in JS and
ICE in the browser. The above text is written the way it is for ICE in the browser. The above text is written the way it is for
editorial convenience and will be modified appropriately if the WG editorial convenience and will be modified appropriately if the WG
decides on ICE in the JS.] decides on ICE in the JS.] The JS MUST NOT be permitted to control
the local ufrag and password, though it of course knows it.
Implementations MUST send keepalives no less frequently than every 30 While continuing consent is required, that ICE [RFC5245]; Section 10
seconds regardless of whether traffic is flowing or not. If a keepalives STUN Binding Indications are one-way and therefore not
keepalive fails then the implementation MUST either attempt to find a sufficient. The current WG consensus is to use ICE Binding Requests
new valid path via ICE or terminate media for that ICE component. for continuing consent freshness. ICE already requires that
Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding implementations respond to such requests, so this approach is
Indications which are one-way and therefore not sufficient. Instead, maximally compatible. A separate document will profile the ICE
the consent freshness mechanism [I-D.muthu-behave-consent-freshness] timers to be used; see [I-D.muthu-behave-consent-freshness].
MUST be used.
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,
especially for mobile devices. This has negative privacy especially for mobile devices. This has negative privacy
consequences in some circumstances. The API requirements in this consequences in some circumstances. The API requirements in this
section are intended to mitigate this issue. Note that these section are intended to mitigate this issue. Note that these
requirements are NOT intended to protect the user's IP address from a requirements are NOT intended to protect the user's IP address from a
malicious site. In general, the site will learn at least a user's malicious site. In general, the site will learn at least a user's
skipping to change at page 15, line 16 skipping to change at page 15, line 8
suppress ICE negotiation (though perhaps to allow candidate suppress ICE negotiation (though perhaps to allow candidate
gathering) until the user has decided to answer the call [note: gathering) until the user has decided to answer the call [note:
determining when the call has been answered is a question for the determining when the call has been answered is a question for the
JS.] This enables a user to prevent a peer from learning their IP JS.] This enables a user to prevent a peer from learning their IP
address if they elect not to answer a call and also from learning address if they elect not to answer a call and also from learning
whether the user is online. whether the user is online.
API Requirement: The API MUST provide a mechanism for the calling API Requirement: The API MUST provide a mechanism for the calling
application JS to indicate that only TURN candidates are to be application JS to indicate that only TURN candidates are to be
used. This prevents the peer from learning one's IP address at used. This prevents the peer from learning one's IP address at
all. The API MUST provide a mechanism for the calling application all.
to reconfigure an existing call to add non-TURN candidates. Taken
together, these requirements allow ICE negotiation to start API Requirement: The API MUST provide a mechanism for the calling
immediately on incoming call notification, thus reducing post-dial application to reconfigure an existing call to add non-TURN
delay, but also to avoid disclosing the user's IP address until candidates. Taken together, this and the previous requirement
they have decided to answer. They also allow users to completely allow ICE negotiation to start immediately on incoming call
hide their IP address for the duration of the call. Finally, they notification, thus reducing post-dial delay, but also to avoid
allow a mechanism for the user to optimize performance by disclosing the user's IP address until they have decided to
reconfiguring to allow non-TURN candidates during an active call answer. They also allow users to completely hide their IP address
if the user decides they no longer need to hide their IP address for the duration of the call. Finally, they allow a mechanism for
the user to optimize performance by reconfiguring to allow non-
turn candidates during an active call if the user decides they no
longer need to hide their IP address
5.5. Communications Security 5.5. Communications Security
Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP
[RFC5763][RFC5764]. All data channels MUST be secured via DTLS. [RFC5763][RFC5764]. All data channels MUST be secured via DTLS.
DTLS-SRTP MUST be offered for every media channel and MUST be the DTLS-SRTP MUST be offered for every media channel and MUST be the
default; i.e., if an implementation receives an offer for DTLS-SRTP default; i.e., if an implementation receives an offer for DTLS-SRTP
and SDES, DTLS-SRTP MUST be selected. Media traffic MUST NOT be sent and SDES, DTLS-SRTP MUST be selected. Media traffic MUST NOT be sent
over plain (unencrypted) RTP. over plain (unencrypted) RTP.
[OPEN ISSUE: What should the settings be here? MUST?] [OPEN ISSUE: What should the settings be here? MUST?]
Implementations MAY support SDES and RTP for media traffic for Implementations MAY support SDES for media traffic for backward
backward compatibility purposes. compatibility purposes.
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. authentication.
API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the
JS to obtain the negotiated keying material. This requirement JS to obtain the negotiated keying material. This requirement
skipping to change at page 16, line 25 skipping to change at page 16, line 20
* A client MUST provide a user interface through which a user may * A client MUST provide a user interface through which a user may
determine the security characteristics for transmissions of determine the security characteristics for transmissions of
their microphone audio and camera video. their microphone audio and camera video.
* The "security characteristics" MUST include an indication as to * The "security characteristics" MUST include an indication as to
whether the cryptographic keys were delivered out-of-band (from whether the cryptographic keys were delivered out-of-band (from
a server) or were generated as a result of a pairwise a server) or were generated as a result of a pairwise
negotiation. negotiation.
* If the far endpoint was directly verified, either via a third- * If the far endpoint was directly verified, either via a third-
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. the verified information. X.509 identities and Web IdP
identities have similar semantics and should be displayed in a
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" or "Null Cipher".)
* 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
In a number of cases, it is desirable for the endpoint (i.e., the In a number of cases, it is desirable for the endpoint (i.e., the
skipping to change at page 16, line 51 skipping to change at page 16, line 49
side without trusting only the signaling service to which they are side without trusting only the signaling service to which they are
connected. For instance, users may be making a call via a federated connected. For instance, users may be making a call via a federated
system where they wish to get direct authentication of the other system where they wish to get direct authentication of the other
side. Alternately, they may be making a call on a site which they side. Alternately, they may be making a call on a site which they
minimally trust (such as a poker site) but to someone who has an minimally trust (such as a poker site) but to someone who has an
identity on a site they do trust (such as a social network.) identity on a site they do trust (such as a social network.)
Recently, a number of Web-based identity technologies (OAuth, Recently, a number of Web-based identity technologies (OAuth,
BrowserID, Facebook Connect), etc. have been developed. While the BrowserID, Facebook Connect), etc. have been developed. While the
details vary, what these technologies share is that they have a Web- details vary, what these technologies share is that they have a Web-
based (i.e., HTTP/HTTPS identity provider) which attests to your based (i.e., HTTP/HTTPS) identity provider which attests to your
identity. For instance, if I have an account at example.org, I could identity. For instance, if I have an account at example.org, I could
use the example.org identity provider to prove to others that I was use the example.org identity provider to prove to others that I was
alice@example.org. The development of these technologies allows us alice@example.org. The development of these technologies allows us
to separate calling from identity provision: I could call you on to separate calling from identity provision: I could call you on
Poker Galaxy but identify myself as alice@example.org. Poker Galaxy but identify myself as alice@example.org.
Whatever the underlying technology, the general principle is that the Whatever the underlying technology, the general principle is that the
party which is being authenticated is NOT the signaling site but party which is being authenticated is NOT the signaling site but
rather the user (and their browser). Similarly, the relying party is rather the user (and their browser). Similarly, the relying party is
the browser and not the signaling site. Thus, the browser MUST the browser and not the signaling site. Thus, the browser MUST
securely generate the input to the IdP assertion process and MUST securely generate the input to the IdP assertion process and MUST
securely display the results of the verification process to the user securely display the results of the verification process to the user
in a way which cannot be imitated by the calling site. in a way which cannot be imitated by the calling site.
In order to make this work, we must standardize the following items: The mechanisms defined in this document do not require the browser to
o The precise information from the signaling message that must be
cryptographically bound to the user's identity and a mechanism for
carrying assertions in JSEP messages. Section 5.6.3
o The interface to the IdP. Section 5.6.4 specifies a specific
protocol mechanism which allows the use of any identity protocol
without requiring specific further protocol support in the browser
o The JavaScript interfaces which the calling application can use to
specify the IdP to use to generate assertions and to discover what
assertions were received.
The first two items are defined in this document. The final one is
defined in the companion W3C WebRTC API specification [TODO:REF]
The mechanisms in this document do not require the browser to
implement any particular identity protocol or to support any implement any particular identity protocol or to support any
particular IdP. Instead, this document provides a generic interface particular IdP. Instead, this document provides a generic interface
which any IdP can implement. Thus, new IdPs and protocols can be which any IdP can implement. Thus, new IdPs and protocols can be
introduced without change to either the browser or the calling introduced without change to either the browser or the calling
service. This avoids the need to make a commitment to any particular service. This avoids the need to make a commitment to any particular
identity protocol, although browsers may opt to directly implement identity protocol, although browsers may opt to directly implement
some identity protocols in order to provide superior performance or some identity protocols in order to provide superior performance or
UI properties. UI properties.
5.6.1. Trust Relationships: IdPs, APs, and RPs 5.6.1. Trust Relationships: IdPs, APs, and RPs
skipping to change at page 20, line 22 skipping to change at page 20, line 5
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.
5.6.3. Binding Identity Assertions to JSEP Offer/Answer Transactions 5.6.3. Items for Standardization
5.6.3.1. Input to Assertion Generation Process In order to make this work, we must standardize the following items:
o The precise information from the signaling message that must be
cryptographically bound to the user's identity and a mechanism for
carrying assertions in JSEP messages. Section 5.6.4
o The interface to the IdP. Section 5.6.5 specifies a specific
protocol mechanism which allows the use of any identity protocol
without requiring specific further protocol support in the browser
o The JavaScript interfaces which the calling application can use to
specify the IdP to use to generate assertions and to discover what
assertions were received.
The first two items are defined in this document. The final one is
defined in the companion W3C WebRTC API specification [TODO:REF]
5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions
5.6.4.1. Input to Assertion Generation Process
As discussed above, an identity assertion binds the user's identity As discussed above, an identity assertion binds the user's identity
(as asserted by the IdP) to the JSEP offer/exchange transaction and (as asserted by the IdP) to the JSEP offer/exchange transaction and
specifically to the media. In order to achieve this, the specifically to the media. In order to achieve this, the
PeerConnection must provide the DTLS-SRTP fingerprint to be bound to PeerConnection must provide the DTLS-SRTP fingerprint to be bound to
the identity. This is provided in a JSON structure for the identity. This is provided in a JSON structure for
extensibility, as shown below: extensibility, as shown below:
{ {
"fingerprint" : { "fingerprint" :
{ {
"algorithm":"SHA-1", "algorithm":"SHA-1",
"digest":"4A:AD:B9:B1:3F:...:E5:7C:AB" "digest":"4A:AD:B9:B1:3F:...:E5:7C:AB"
} }
} }
The "algorithm" and digest values correspond directly to the The "algorithm" and digest values correspond directly to the
algorithm and digest in the a=fingerprint line of the SDP. algorithm and digest in the a=fingerprint line of the SDP.
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.
5.6.3.2. Carrying Identity Assertions 5.6.4.2. Carrying Identity Assertions
Once an IdP has generated an assertion, the JSEP message. This is Once an IdP has generated an assertion, the JSEP message. This is
done by adding a new a-line to the SDP, of the form a=identity. The 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 version of the sole contents of this value are a base-64-encoded version of the
identity assertion. For example: 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
skipping to change at page 21, line 37 skipping to change at page 21, line 37
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1 a=pcfg:1 t=1
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 session a=fingerprint attribute and therefore can exist either at the session
or media level. Multiple identity attributes may appear at either or media level. Multiple identity attributes may appear at either
level, though implementations are discouraged from doing this unless level, though implementations are discouraged from doing this unless
they have a clear idea of what security claim they intend to be they have a clear idea of what security claim they intend to be
making. making.
5.6.4. IdP Interaction Details 5.6.5. IdP Interaction Details
5.6.4.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
formatted using JSON [RFC4627]. For instance, the PeerConnection formatted using JSON [RFC4627]. For instance, the PeerConnection
would request a signature with the following "SIGN" message: would request a signature with the following "SIGN" message:
{ {
"type":"SIGN", "type":"SIGN",
"id": "1", "id": "1",
"origin":"https://calling-site.example.com", "origin":"https://calling-site.example.com",
"message":"012345678abcdefghijkl" "message":"012345678abcdefghijkl"
} }
All messages MUST contain a "type" field which indicates the general All messages MUST contain a "type" field which indicates the general
meaning of the message. meaning of the message.
All requests from the PeerConnection object MUST contain an "id" All requests from the PeerConnection object MUST contain an "id"
field which MUST be unique for that PeerConnection object. Any field which MUST be unique for that PeerConnection object. Any
responses from the IdP proxy MUST contain the same id in response, responses from the IdP proxy MUST contain the same id in response,
which allows the PeerConnection to correlate requests and responses. which allows the PeerConnection to correlate requests and responses.
All requests from the PeerConnection object MUST contain an "origin" All requests from the PeerConnection object MUST contain a "origin"
field containing the origin of the JS which initiated the PC (i.e., field containing the origin of the JS which initiated the PC (i.e.,
the URL of the calling site). This origin value can be used by the the URL of the calling site). This origin value can be used by the
IdP to make access control decisions. For instance, an IdP might IdP to make access control decisions. For instance, an IdP might
only issue identity assertions for certain calling services in the only issue identity assertions for certain calling services in the
same way that some IdPs require that relying Web sites have an API same way that some IdPs require that relying Web sites have an API
key before learning user identity. key before learning user identity.
Any message-specific data is carried in a "message" field. Depending Any message-specific data is carried in a "message" field. Depending
on the message type, this may either be a string or a richer JSON on the message type, this may either be a string or a richer JSON
object. object.
5.6.4.1.1. Errors 5.6.5.1.1. Errors
If an error occurs, the IdP sends a message of type "ERROR". The If an error occurs, the IdP sends a message of type "ERROR". The
message MAY have an "error" field containing freeform text data which message MAY have an "error" field containing freeform text data which
containing additional information about what happened. For instance: containing additional information about what happened. For instance:
{ {
"type":"ERROR", "type":"ERROR",
"error":"Signature verification failed" "error":"Signature verification failed"
} }
Figure 3: Example error Figure 3: Example error
5.6.4.2. IdP Proxy Setup 5.6.5.2. IdP Proxy Setup
In order to perform an identity transaction, the PeerConnection must In order to perform an identity transaction, the PeerConnection must
first create an IdP proxy. As stated above, the details of this are first create an IdP proxy. While the details of this are specified
specified in the W3C API document. From the perspective of this in the W3C API document, from the perspective of this specification,
specification, however, the relevant facts are: however, the relevant facts are:
o The JS runs in the IdP's security context with the base page o The JS runs in the IdP's security context with the base page
retrieved from the URL specified in Section 5.6.4.2.1 retrieved from the URL specified in Section 5.6.5.2.1
o The usual browser sandbox isolation mechanisms MUST be enforced o The usual browser sandbox isolation mechanisms MUST be enforced
with respect to the IdP proxy. with respect to the IdP proxy.
o JS running in the IdP proxy MUST be able to send and receive o JS running in the IdP proxy MUST be able to send and receive
messages to the PeerConnection and the PC and IdP proxy are able messages to the PeerConnection and the PC and IdP proxy are able
to verify the source and destination of these messages. to verify the source and destination of these messages.
Initially the IdP proxy is in an unready state; the IdP JS must be Initially the IdP proxy is in an unready state; the IdP JS must be
loaded and there may be several round trips to the IdP server, for loaded and there may be several round trips to the IdP server, for
instance to log the user in. When the IdP proxy is ready to receive instance to log the user in. When the IdP proxy is ready to receive
commands, it delivers a "ready" message. As this message is commands, it delivers a "ready" message. As this message is
unsolicited, it simply contains: unsolicited, it simply contains:
{ "type":"READY" } { "type":"READY" }
[[ OPEN ISSUE: if the W3C half of this converges on WebIntents, then
the READY message will not be necessary.]]
Once the PeerConnection object receives the ready message, it can Once the PeerConnection object receives the ready message, it can
send commands to the IdP proxy. send commands to the IdP proxy.
5.6.4.2.1. Determining the IdP URI 5.6.5.2.1. Determining the IdP URI
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 IdP-specific string, but allows an IdP to implement
two protocols in parallel. This value may be the empty string. 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 the well-known URI specified in "/.well-known/ the IdP proxy) from the well-known URI specified in "/.well-known/
idp-proxy/<protocol>" on the IdP's web site. This URI MUST be loaded idp-proxy/<protocol>" on the IdP's web site. This URI MUST be loaded
via HTTPS [RFC2818]. For example, for the IdP "identity.example.com" via HTTPS [RFC2818]. For example, for the IdP "identity.example.com"
and the protocol "example", the URL would be: and the protocol "example", the URL would be:
https://example.com/.well-known/idp-proxy/example https://example.com/.well-known/idp-proxy/example
5.6.4.2.1.1. Authenticating Party 5.6.5.2.1.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
this specification. In general, however, the AP has some actual this specification. In general, however, the AP has some actual
account relationship with the IdP, as this identity is what the IdP account relationship with the IdP, as this identity is what the IdP
is attesting to. Thus, the AP somehow supplies the IdP information is attesting to. Thus, the AP somehow supplies the IdP information
to the browser. Some potential mechanisms include: to the browser. Some potential mechanisms include:
o Provided by the user directly. o Provided by the user directly.
o Selected from some set of IdPs known to the calling site. E.g., a o Selected from some set of IdPs known to the calling site. E.g., a
button that shows "Authenticate via Facebook Connect" button that shows "Authenticate via Facebook Connect"
5.6.4.2.1.2. Relying Party 5.6.5.2.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.4.2.3.1. local policy, as described in Section 5.6.5.2.3.1.
5.6.4.2.2. Requesting Assertions 5.6.5.2.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 contents of this string are "message" field containing a string. The contents of this string are
defined above, but are opaque from the perspective of the IdP. defined above, but are opaque from the perspective of the IdP.
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 JS dictionary dictionary consisting of two fields: which is a JS dictionary 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 field containing the assertion itself. This is assertion: An opaque field containing the assertion itself. This is
only interpretable by the idp or its proxy. only interpretable by the idp or its proxy.
Figure 4 shows an example transaction, with the message "abcde..." Figure 4 shows an example transaction, with the message "abcde..."
being signed and bound to identity "ekr@example.org". In this case, (remember, the messages are opaque at this layer) being signed and
the message has presumably been digitally signed/MACed in some way bound to identity "ekr@example.org". In this case, the message has
that the IdP can later verify it, but this is an implementation presumably been digitally signed/MACed in some way that the IdP can
detail and out of scope of this document. Line breaks are inserted later verify it, but this is an implementation detail and out of
solely for readability. scope of this document. Line breaks are inserted solely for
readability.
PeerConnection -> IdP proxy: PeerConnection -> IdP proxy:
{ {
"type":"SIGN", "type":"SIGN",
"id":1, "id":1,
"message":"abcdefghijklmnopqrstuvwyz" "origin":"https://calling-service.example.com/",
} "message":"abcdefghijklmnopqrstuvwyz"
}
IdPProxy -> PeerConnection:
{
"type":"SUCCESS",
"id":1,
"message": {
"idp":{
"domain": "example.org"
"protocol": "bogus"
},
"assertion":\"{\"identity\":\"bob@example.org\",
\"contents\":\"abcdefghijklmnopqrstuvwyz\",
\"request_origin\":\"rtcweb://peerconnection\",
\"signature\":\"010203040506\"}"
}
}
IdPProxy -> PeerConnection:
{
"type":"SUCCESS",
"id":1,
"message": {
"idp":{
"domain": "example.org"
"protocol": "bogus"
},
"assertion":\"{\"identity\":\"bob@example.org\",
\"contents\":\"abcdefghijklmnopqrstuvwyz\",
\"signature\":\"010203040506\"}"
}
}
Figure 4: Example assertion request Figure 4: Example assertion request
5.6.4.2.3. Verifying Assertions 5.6.5.2.3. 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, this may require one or more round trips to the IdP. For protocol, this may require one or more round trips to the IdP. For
instance, an OAuth-based protocol will likely require using the IdP instance, an OAuth-based protocol will likely require using the IdP
as an oracle, whereas with BrowserID the IdP proxy can likely verify as an oracle, whereas with BrowserID the IdP proxy can likely verify
the signature on the assertion without contacting the IdP, provided the signature on the assertion without contacting the IdP, provided
that it has cached the IdP's public key. 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 dictionary/hash with the following fields: of a dictionary/hash with the following fields:
identity The identity of the AP from the IdP's perspective. Details identity The identity of the AP from the IdP's perspective. Details
of this are provided in Section 5.6.4.2.3.1 of this are provided in Section 5.6.5.2.3.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.
request_origin The original origin of the SIGN request on the AP
side as determined by the origin of the PostMessage call. The IdP
MUST somehow arrange to propagate this information as part of the
assertion. The receiving PeerConnection MUST verify that this
value is "rtcweb://peerconnection" (which implies that
PeerConnection must arrange that its messages to the IdP proxy are
from this origin.) [[ OPEN ISSUE: Can a URI person help make a
better URI.]]
Figure 5 shows an example transaction. Line breaks are inserted Figure 5 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,
"message":\"{\"identity\":\"bob@example.org\",
\"contents\":\"abcdefghijklmnopqrstuvwyz\",
\"signature\":\"010203040506\"}"
}
IdP Proxy -> PeerConnection:
{
"type":"SUCCESS",
"id":2, "id":2,
"message": { "origin":"https://calling-service.example.com/",
"identity" : { "message":\"{\"identity\":\"bob@example.org\",
"name" : "bob@example.org", \"contents\":\"abcdefghijklmnopqrstuvwyz\",
"displayname" : "Bob" \"request_origin\":\"rtcweb://peerconnection\",
}, \"signature\":\"010203040506\"}"
"contents":"abcdefghijklmnopqrstuvwyz" }
}
IdP Proxy -> PeerConnection:
{
"type":"SUCCESS",
"id":2,
"message": {
"identity" : {
"name" : "bob@example.org",
"displayname" : "Bob"
},
"request_origin":"rtcweb://peerconnection",
"contents":"abcdefghijklmnopqrstuvwyz"
} }
}
Figure 5: Example verification request Figure 5: Example verification request
5.6.4.2.3.1. Identity Formats 5.6.5.2.3.1. Identity Formats
Identities passed from the IdP proxy to the PeerConnection are Identities passed from the IdP proxy to the PeerConnection are
structured as JSON dictionaries with one mandatory field: "name". structured as JSON dictionaries with one mandatory field: "name".
This field MUST consist of an RFC822-formatted string representing This field MUST consist of an RFC822-formatted string representing
the user's identity. [[ OPEN ISSUE: Would it be better to have a the user's identity. [[ OPEN ISSUE: Would it be better to have a
typed field? ]] The PeerConnection API MUST check this string as typed field? ]] The PeerConnection API MUST check this string as
follows: follows:
1. If the RHS of the string is equal to the domain name of the IdP 1. If the RHS of the string is equal to the domain name of the IdP
proxy, then the assertion is valid, as the IdP is authoritative proxy, then the assertion is valid, as the IdP is authoritative
skipping to change at page 27, line 10 skipping to change at page 27, line 34
(for instance, Facebook ids are simple numeric values) SHOULD convert (for instance, Facebook ids are simple numeric values) SHOULD convert
them to this form by appending their IdP domain (e.g., them to this form by appending their IdP domain (e.g.,
12345@identity.facebook.com), thus ensuring that they are 12345@identity.facebook.com), thus ensuring that they are
authoritative for the identity. authoritative for the identity.
The IdP proxy MAY also include a "displayname" field which contains a The IdP proxy MAY also include a "displayname" field which contains a
more user-friendly identity assertion. Browsers SHOULD take care in more user-friendly identity assertion. Browsers SHOULD take care in
the UI to distinguish the "name" assertion which is verifiable the UI to distinguish the "name" assertion which is verifiable
directly from the "displayname" which cannot be verified and thus directly from the "displayname" which cannot be verified and thus
relies on trust in the IdP. In future, we may define other fields to relies on trust in the IdP. In future, we may define other fields to
allow the IdP to provide more information to the browser. allow the IdP to provide more information to the browser. [[OPEN
ISSUE: Should this field exist? Is it confusing? ]]
5.7. Security Considerations 5.7. Security Considerations
Much of the security analysis of this problem is contained in Much of the security analysis of this problem is contained in
[I-D.ietf-rtcweb-security] or in the discussion of the particular [I-D.ietf-rtcweb-security] or in the discussion of the particular
issues above. In order to avoid repetition, this section focuses on issues above. In order to avoid repetition, this section focuses on
(a) residual threats that are not addressed by this document and (b) (a) residual threats that are not addressed by this document and (b)
threats produced by failure/misbehavior of one of the components in threats produced by failure/misbehavior of one of the components in
the system. the system.
skipping to change at page 27, line 49 skipping to change at page 28, line 25
requirements in Section 5.5 are designed to provide such a mechanism requirements in Section 5.5 are designed to provide such a mechanism
for motivated/security conscious users, but are not suitable for for motivated/security conscious users, but are not suitable for
general use. The identity service mechanisms in Section 5.6 are more general use. The identity service mechanisms in Section 5.6 are more
suitable for general use. Note, however, that a malicious signaling suitable for general use. Note, however, that a malicious signaling
service can strip off any such identity assertions, though it cannot service can strip off any such identity assertions, though it cannot
forge new ones. Note that all of the third-party security mechanisms forge new ones. Note that all of the third-party security mechanisms
available (whether X.509 certificates or a third-party IdP) rely on available (whether X.509 certificates or a third-party IdP) rely on
the security of the third party--this is of course also true of your the security of the third party--this is of course also true of your
connection to the Web site itself. Users who wish to assure connection to the Web site itself. Users who wish to assure
themselves of security against a malicious identity provider can only themselves of security against a malicious identity provider can only
do so by verifing peer credentials directly, e.g., by checking the do so by verifying peer credentials directly, e.g., by checking the
peer's fingerprint against a value delivered out of band. peer's fingerprint against a value delivered out of band.
5.7.2. Privacy 5.7.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.
skipping to change at page 29, line 7 skipping to change at page 29, line 34
which are behaving badly, and especially to be prepared to remotely which are behaving badly, and especially to be prepared to remotely
throttle the data channel in the absence of plausible audio and video throttle the data channel in the absence of plausible audio and video
(which the attacker cannot control). (which the attacker cannot control).
Another related attack is for the signaling service to swap the ICE Another related attack is for the signaling service to swap the ICE
candidates for the audio and video streams, thus forcing a browser to candidates for the audio and video streams, thus forcing a browser to
send video to the sink that the other victim expects will contain send video to the sink that the other victim expects will contain
audio (perhaps it is only expecting audio!) potentially causing audio (perhaps it is only expecting audio!) potentially causing
overload. Muxing multiple media flows over a single transport makes overload. Muxing multiple media flows over a single transport makes
it harder to individually suppress a single flow by denying ICE it harder to individually suppress a single flow by denying ICE
keepalives. Media-level (RTCP) mechanisms must be used in this case. keepalives. Either media-level (RTCP) mechanisms must be used or the
implementation must deny responses entirely, thus termnating the
call.
Yet another attack, suggested by Magnus Westerlund, is for the Yet another attack, suggested by Magnus Westerlund, is for the
attacker to cross-connect offers and answers as follows. It induces attacker to cross-connect offers and answers as follows. It induces
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. [[ OPEN ISSUE: How do we address this? ]] victim. Implementations can defend themselves from this attack by
only responding to ICE Binding Requests for a limited number of
[TODO: Should we have a mechanism for verifying total expected remote ufrags (this is the reason for the requirement that the JS not
bandwidth] be able to control the ufrag and password).
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 primarily even in the face of the third-party consent are possible even in the face of the third-party identity
identity mechanism as long as major parts of the signaling messages mechanism as long as major parts of the signaling messages are not
are not signed. On the other hand, signing the entire message signed. On the other hand, signing the entire message severely
severely restricts the capabilities of the calling application, so restricts the capabilities of the calling application, so there are
there are difficult tradeoffs here. difficult tradeoffs here.
5.7.4. IdP Authentication Mechanism 5.7.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.
skipping to change at page 29, line 48 skipping to change at page 30, line 28
5.7.4.1. PeerConnection Origin Check 5.7.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 a page tied to a Web attacker. Thus, while an be produced by a page tied to a Web attacker. Thus, while an
attacker can instantiate the IdP proxy, they cannot send messages attacker can instantiate the IdP proxy, they cannot send messages
from an appropriate origin and so cannot create acceptable from an appropriate origin and so cannot create acceptable
assertions. [[OPEN ISSUE: Where is this enforced? ]] assertions. This origin check is enforced on 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
RTCWEB. The IdP simply needs to gather the origin information (from
the posted message) and attach it to the assertion.
5.7.4.2. IdP Well-known URI 5.7.4.2. IdP Well-known URI
As described in Section 5.6.4.2.1 the IdP proxy HTML/JS landing page As described in Section 5.6.5.2.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 5.7.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
skipping to change at page 31, line 33 skipping to change at page 32, line 16
third-party cookie blocking for the IdP proxy. third-party cookie blocking for the IdP proxy.
6. Acknowledgements 6. Acknowledgements
Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Hadriel Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Hadriel
Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus
Westerland. Westerland.
7. Changes since -03 7. Changes since -03
The following changes have been made since the -02 draft. Version -04 was a version control mistake. Please ignore.
o Editorial changes The following changes have been made since the -04 draft.
8. Changes since -02 o Move origin check from IdP to RP per discussion in YVR.
o Clarified treatment of X.509-level identities.
o Editorial cleanup.
8. Changes since -03
9. 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 Editorial improvements
9. References 10. References
9.1. Normative References
10.1. Normative References
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-03 (work in progress), draft-ietf-rtcweb-security-03 (work in progress),
June 2012. June 2012.
[I-D.muthu-behave-consent-freshness] [I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for
Consent Freshness and Session Liveness", Consent Freshness and Session Liveness",
draft-muthu-behave-consent-freshness-01 (work in draft-muthu-behave-consent-freshness-01 (work in
skipping to change at page 32, line 45 skipping to change at page 33, line 37
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. December 2011.
9.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-01 (work Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work
in progress), June 2012. in progress), June 2012.
[I-D.jennings-rtcweb-signaling] [I-D.jennings-rtcweb-signaling]
Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/ Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/
Answer Protocol (ROAP)", Answer Protocol (ROAP)",
draft-jennings-rtcweb-signaling-01 (work in progress), draft-jennings-rtcweb-signaling-01 (work in progress),
 End of changes. 63 change blocks. 
176 lines changed or deleted 216 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/