draft-ietf-rtcweb-security-arch-07.txt   draft-ietf-rtcweb-security-arch-08.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track July 14, 2013 Intended status: Standards Track January 22, 2014
Expires: January 15, 2014 Expires: July 26, 2014
WebRTC Security Architecture WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-07 draft-ietf-rtcweb-security-arch-08
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 for
Legal
THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON
AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 15, 2014. This Internet-Draft will expire on July 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 7 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6
3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 7 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 10 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 9
4.2. Media Consent Verification . . . . . . . . . . . . . . . . 12 4.2. Media Consent Verification . . . . . . . . . . . . . . . . 11
4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 13 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Communications and Consent Freshness . . . . . . . . . . . 13 4.4. Communications and Consent Freshness . . . . . . . . . . . 12
5. Detailed Technical Description . . . . . . . . . . . . . . . . 14 5. Detailed Technical Description . . . . . . . . . . . . . . . . 13
5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 14 5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 13
5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 14 5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 13
5.3. Communications Consent . . . . . . . . . . . . . . . . . . 16 5.3. Communications Consent . . . . . . . . . . . . . . . . . . 15
5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 16
5.5. Communications Security . . . . . . . . . . . . . . . . . 18 5.5. Communications Security . . . . . . . . . . . . . . . . . 17
5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 19 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 18
5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 20 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 19
5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 22 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 21
5.6.3. Items for Standardization . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 23 Transactions . . . . . . . . . . . . . . . . . . . . . 22
5.6.4.1. Input to Assertion Generation Process . . . . . . 23 5.6.4.1. Input to Assertion Generation Process . . . . . . 22
5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 24 5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 23
5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 25 5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 24
5.6.5.1. General Message Structure . . . . . . . . . . . . 25 5.6.5.1. General Message Structure . . . . . . . . . . . . 24
5.6.5.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 26 5.6.5.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 25
5.7. Security Considerations . . . . . . . . . . . . . . . . . 30 5.7. Security Considerations . . . . . . . . . . . . . . . . . 29
5.7.1. Communications Security . . . . . . . . . . . . . . . 30 5.7.1. Communications Security . . . . . . . . . . . . . . . 29
5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 31 5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 30
5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 32 5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 31
5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 33 5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 32
5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 33 5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 32
5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 34 5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 33
5.7.4.3. Privacy of IdP-generated identities and the 5.7.4.3. Privacy of IdP-generated identities and the
hosting site . . . . . . . . . . . . . . . . . . . 34 hosting site . . . . . . . . . . . . . . . . . . . 33
5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 35 5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 34
5.7.4.5. Web Security Feature Interactions . . . . . . . . 35 5.7.4.5. Web Security Feature Interactions . . . . . . . . 34
5.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 35 5.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 34
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 36 7.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 35
7.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 36 7.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 35
7.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36 7.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
7.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36 7.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
7.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 37 7.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 Appendix A. Example IdP Bindings to Specific Protocols . . . . . 38
Appendix A. Example IdP Bindings to Specific Protocols . . . . . 39 A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
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 10, line 5 skipping to change at page 9, line 5
Figure 3: A call with IdP-based identity Figure 3: A call with IdP-based identity
Figure 4 shows essentially the same calling scenario but with a call Figure 4 shows essentially the same calling scenario but with a call
between two separate domains (i.e., a federated case), as in between two separate domains (i.e., a federated case), as in
Figure 2. As mentioned above, the domains communicate by some Figure 2. As mentioned above, the domains communicate by some
unspecified protocol and providing separate signaling and identity unspecified protocol and providing separate signaling and identity
allows for calls to be authenticated regardless of the details of the allows for calls to be authenticated regardless of the details of the
inter-domain protocol. inter-domain protocol.
+----------------+ Unspecified +----------------+ +----------------+ Unspecified +----------------+
| | protocol | | | | protocol | |
| Signaling |<----------------->| Signaling | | Signaling |<----------------->| Signaling |
| Server | (SIP, XMPP, ...) | Server | | Server | (SIP, XMPP, ...) | Server |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
^ ^ ^ ^
| | | |
HTTPS | | HTTPS HTTPS | | HTTPS
| | | |
| | | |
v v v v
JS API JS API JS API JS API
+-----------+ +-----------+ +-----------+ +-----------+
| | Media | | | | Media | |
Alice | Browser |<--------------------------->| Browser | Bob Alice | Browser |<--------------------------->| Browser | Bob
| | DTLS+SRTP | | | | DTLS+SRTP | |
+-----------+ +-----------+ +-----------+ +-----------+
^ ^--+ +--^ ^ ^ ^--+ +--^ ^
| | | | | | | |
v | | v v | | v
+-----------+ | | +-----------+ +-----------+ | | +-----------+
| |<-------------------------+ | | | |<-------------------------+ | |
| IdP1 | | | IdP2 | | IdP1 | | | IdP2 |
| | +------------------------>| | | | +------------------------>| |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 4: A federated call with IdP-based identity Figure 4: A federated call with IdP-based identity
4.1. Initial Signaling 4.1. Initial Signaling
For simplicity, assume the topology in Figure 3. Alice and Bob are For simplicity, assume the topology in Figure 3. Alice and Bob are
both users of a common calling service; they both have approved the both users of a common calling service; they both have approved the
calling service to make calls (we defer the discussion of device calling service to make calls (we defer the discussion of device
access permissions till later). They are both connected to the access permissions till later). They are both connected to the
calling service via HTTPS and so know the origin with some level of calling service via HTTPS and so know the origin with some level of
skipping to change at page 18, line 26 skipping to change at page 17, line 26
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. DTLS-SRTP MUST be offered for
every media channel and MUST be the default; i.e., if an every media channel. WebRTC implements MUST NOT offer SDES or select
implementation receives an offer for DTLS-SRTP and SDES, DTLS-SRTP it if offered.
MUST be selected.
All data channels MUST be secured via DTLS. All data channels MUST be secured via DTLS.
[OPEN ISSUE: What should the settings be here? MUST?] [[OPEN ISSUE: Are these the right cipher suites?]] All
Implementations MAY support SDES for media traffic for backward implementations MUST implement the following two cipher suites:
compatibility purposes. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and the DTLS-SRTP protection
profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD favor
cipher suites which support PFS over non-PFS cipher suites.
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 24, line 29 skipping to change at page 23, line 29
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.4.2. Carrying Identity Assertions 5.6.4.2. Carrying Identity Assertions
Once an IdP has generated an assertion, it is attached to the JSEP Once an IdP has generated an assertion, it is attached to the JSEP
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
version of the identity assertion. For example: version of the 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=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 \ ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n\
dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v \ dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v\
cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs \ cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs\
XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg== XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg==
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 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 it is RECOMMENDED that implementations not do this, level, though it is RECOMMENDED that implementations not do this,
because it becomes very unclear what security claim that they are because it becomes very unclear what security claim that they are
making and the UI guidelines above become unclear. Browsers MAY 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
skipping to change at page 28, line 9 skipping to change at page 27, line 9
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
bound to identity "ekr@example.org". In this case, the message has bound to identity "ekr@example.org". In this case, the message has
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,
"origin":"https://calling-service.example.com/",
"message":"abcdefghijklmnopqrstuvwyz"
}
IdPProxy -> PeerConnection:
{
"type":"SUCCESS",
"id":1, "id":1,
"message": { "origin":"https://calling-service.example.com/",
"idp":{ "message":"abcdefghijklmnopqrstuvwyz"
"domain": "example.org" }
"protocol": "bogus"
}, IdPProxy -> PeerConnection:
"assertion":\"{\"identity\":\"bob@example.org\", {
\"contents\":\"abcdefghijklmnopqrstuvwyz\", "type":"SUCCESS",
\"request_origin\":\"rtcweb://peerconnection\", "id":1,
\"signature\":\"010203040506\"}" "message": {
} "idp":{
} "domain": "example.org"
"protocol": "bogus"
},
"assertion": "{\"identity\":\"bob@example.org\",
\"contents\":\"abcdefghijklmnopqrstuvwyz\",
\"request_origin\":\"rtcweb://peerconnection\",
\"signature\":\"010203040506\"}"
}
}
Figure 6: Example assertion request Figure 6: Example assertion request
The message structure is serialized, base64-encoded, and placed in an The message structure is serialized, base64-encoded, and placed in an
a=identity attribute. a=identity attribute.
5.6.5.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
skipping to change at page 29, line 26 skipping to change at page 28, line 26
assertion. The receiving PeerConnection MUST verify that this assertion. The receiving PeerConnection MUST verify that this
value is "rtcweb://peerconnection" (which implies that value is "rtcweb://peerconnection" (which implies that
PeerConnection must arrange that its messages to the IdP proxy are PeerConnection must arrange that its messages to the IdP proxy are
from this origin.) See Section 5.7.4.1 for the security purpose from this origin.) See Section 5.7.4.1 for the security purpose
of this field. [[ OPEN ISSUE: Can a URI person help make a better of this field. [[ OPEN ISSUE: Can a URI person help make a better
URI.]] URI.]]
Figure 7 shows an example transaction. Line breaks are inserted Figure 7 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\",
\"request_origin\":\"rtcweb://peerconnection\", \"request_origin\":\"rtcweb://peerconnection\",
\"signature\":\"010203040506\"}" \"signature\":\"010203040506\"}"
} }
IdP Proxy -> PeerConnection: IdP Proxy -> PeerConnection:
{ {
"type":"SUCCESS", "type":"SUCCESS",
"id":2, "id":2,
"message": { "message": {
"identity" : { "identity" : {
"name" : "bob@example.org", "name" : "bob@example.org",
"displayname" : "Bob" "displayname" : "Bob"
}, },
"request_origin":"rtcweb://peerconnection", "request_origin":"rtcweb://peerconnection",
"contents":"abcdefghijklmnopqrstuvwyz" "contents":"abcdefghijklmnopqrstuvwyz"
} }
} }
Figure 7: Example verification request Figure 7: Example verification request
5.6.5.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:
skipping to change at page 37, line 27 skipping to change at page 36, line 27
8.1. Normative References 8.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-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for WebRTC",
draft-ietf-rtcweb-security-04 (work in progress), draft-ietf-rtcweb-security-05 (work in progress),
January 2013. July 2013.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets for RTCWEB", Encapsulation of SCTP Packets",
draft-ietf-tsvwg-sctp-dtls-encaps-00 (work in progress), draft-ietf-tsvwg-sctp-dtls-encaps-02 (work in progress),
February 2013. October 2013.
[I-D.muthu-behave-consent-freshness] [I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., R, R., and H. Kaplan, "STUN Usage Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
for Consent Freshness", for Consent Freshness",
draft-muthu-behave-consent-freshness-03 (work in draft-muthu-behave-consent-freshness-04 (work in
progress), February 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.
skipping to change at page 38, line 51 skipping to change at page 37, line 51
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 8.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-03 (work Establishment Protocol", draft-ietf-rtcweb-jsep-05 (work
in progress), February 2013. in progress), October 2013.
[I-D.jennings-rtcweb-signaling]
Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/
Answer Protocol (ROAP)",
draft-jennings-rtcweb-signaling-01 (work in progress),
October 2011.
[I-D.kaufman-rtcweb-security-ui]
Kaufman, M., "Client Security User Interface Requirements
for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
progress), June 2011.
[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.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
skipping to change at page 41, line 22 skipping to change at page 40, line 20
The offer might look something like: The offer might look something like:
{ {
"type":"OFFER", "type":"OFFER",
"sdp": "sdp":
"v=0\n "v=0\n
o=- 2890844526 2890842807 IN IP4 192.0.2.1\n o=- 2890844526 2890842807 IN IP4 192.0.2.1\n
s= \n s= \n
c=IN IP4 192.0.2.1\n c=IN IP4 192.0.2.1\n
t=2873397496 2873404696\n t=2873397496 2873404696\n
m=audio 49170 RTP/AVP 0\n a=fingerprint:SHA-1 ...\n
a=fingerprint: SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n
a=identity [[base-64 encoding of... a=identity [[base-64 encoding of identity assertion:
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n", {
"identity":{ "idp":{ // Standardized
"idp":{ // Standardized "domain":"browserid.org",
"domain":"browserid.org", "method":"default"
"method":"default" },
}, // Assertion contents are browserid-specific
"assertion": // Contents are browserid-specific "assertion": "{
"\"assertion\": { \"assertion\": {
\"digest\":\"<hash of the contents from the browser>\", \"digest\":\"<hash of the SIGN message>\",
\"audience\": \"[TBD]\" \"audience\": \"<audience>\"
\"valid-until\": 1308859352261, \"valid-until\": 1308859352261,
}, },
\"certificate\": { \"certificate\": {
\"email\": \"rescorla@example.org\", \"email\": \"rescorla@example.org\",
\"public-key\": \"<ekrs-public-key>\", \"public-key\": \"<ekrs-public-key>\",
\"valid-until\": 1308860561861, \"valid-until\": 1308860561861,
}" // certificate is signed by example.org \"signature\": \"<signature from example.org>\"
}]]" },
} \"content\": \"<content of the SIGN message>\"
}"
}
]]\n
m=audio 49170 RTP/AVP 0\n
..."
}
Note that while the IdP here is specified as "browserid.org", the Note that while the IdP here is specified as "browserid.org", the
actual certificate is signed by example.org. This is because actual certificate is signed by example.org. This is because
BrowserID is a combined authoritative/third-party system in which BrowserID is a combined authoritative/third-party system in which
browserid.org delegates the right to be authoritative (what BrowserID browserid.org delegates the right to be authoritative (what BrowserID
calls primary) to individual domains. calls primary) to individual domains.
On Bob's side, he receives the signed assertion as part of the call On Bob's side, he receives the signed assertion as part of the call
setup message and a similar procedure happens to verify it. setup message and a similar procedure happens to verify it.
 End of changes. 24 change blocks. 
203 lines changed or deleted 189 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/