Internet DRAFT - draft-roach-perc-webrtc
draft-roach-perc-webrtc
Network Working Group A. Roach
Internet-Draft Mozilla
Intended status: Informational March 10, 2017
Expires: September 11, 2017
Using Privacy Enhanced Real-time Conferencing (PERC) in a WebRTC Context
draft-roach-perc-webrtc-00
Abstract
The Privacy-Enhanced Realtime Conferencing (PERC) architecture
defines a system by which multiparty conferences can be handled by a
conference server that is "semi-trusted": that is, it is trusted to
correctly handle media packets, but it is not trusted with the actual
contents of the media streams. In order to use this architecture
within WebRTC, we must describe how information is conveyed among
various network functions. This document describes the information
to be conveyed and how it is transferred.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Roach Expires September 11, 2017 [Page 1]
Internet-Draft PERC in WebRTC March 2017
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Key Distributor Co-Located with Browser . . . . . . . . . 3
4.1.1. Conference Establishment . . . . . . . . . . . . . . 5
4.1.2. Owner Sends Offer to Conference . . . . . . . . . . . 7
4.1.3. Conference Processes Owner Offer . . . . . . . . . . 9
4.1.4. Owner Processes Answer . . . . . . . . . . . . . . . 10
4.1.5. Owner sets up media connection . . . . . . . . . . . 11
4.1.6. Participant Joins Conference . . . . . . . . . . . . 11
4.1.7. Conference Processes Participant Offer . . . . . . . 13
4.1.8. Participant Processes Answer . . . . . . . . . . . . 14
4.1.9. Participant sets up media connection . . . . . . . . 15
4.2. Key Distributor Separate From Browser . . . . . . . . . . 16
5. New Mechanisms Required . . . . . . . . . . . . . . . . . . . 16
5.1. New Key Distributor DOM Object . . . . . . . . . . . . . 16
5.2. New "sign" Tunnel Message . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The Privacy-Enhanced Realtime Conferencing (PERC) architecture
[I-D.ietf-perc-private-media-framework] defines a system by which
multiparty conferences can be handled by a conference server that is
"semi-trusted": that is, it is trusted to correctly handle media
packets, but it is not trusted with the actual contents of the media
streams. In order to use this architecture within WebRTC
[W3C.WD-webrtc-20170313], we must describe how information is
conveyed among various network functions. This document describes
the information to be conveyed and how it is transferred.
Note that the current document is a fairly high-level thumbnail
sketch of information flow. It will be expanded with further detail
once we have consensus on the general direction for the mechanism.
Roach Expires September 11, 2017 [Page 2]
Internet-Draft PERC in WebRTC March 2017
2. Terminology
This document also uses a number of terms defined in section 2 of
[I-D.ietf-perc-private-media-framework]. Of particular note, the
definitions for "Media Distributor (MD)" and "Key Distributor (KD)"
are provided by that document.
3. Goals
A key goal of the mechanisms described in this document is that it
should work with a minimal set of changes to web browsers that
already implement WebRTC. In particular: PERC requires the use of
strong identity assertions in order to provide any value whatsoever.
WebRTC already contains an identity mechanism
[I-D.ietf-rtcweb-security-arch]; we do not seek to introduce a second
one. Regarding identity, this document assumes:
o From a WebRTC perspective, the remote identity presented to each
conference participant will be the identity of the Key Distributor
(KD). Whether this is identical to the PeerConnection identity
presented by the conference owner is a matter of policy for the
conference application. (Note that this is an emergent property
of the system rather than a design decision, since the DTLS
associations used to key the SRTP terminate at the KD in the PERC
architecture.)
o The KD will validate the identity of each user as they join the
conference. The roster of current users must be available to at
least one of the participants through a means that can be trusted
as being authentically generated by the KD.
We also seek to support a system that allows for the Key Distributor
(KD) to be co-located with an endpoint as a primary goal, and for the
KD to be located on a dedicated server as an important secondary
goal.
4. Data Flows
4.1. Key Distributor Co-Located with Browser
When the KD is co-located with the browser, the browser that serves
the role of KD must join the conference before any other media can be
exchanged. It is up to the application to determine whether this is
simply the first participant to join, or a specific participant who
has an administrative relationship with the conference instance. For
concision, we will use the term "conference owner" to refer to the
browser serving in this role, even though its assignment may be
arbitrary.
Roach Expires September 11, 2017 [Page 3]
Internet-Draft PERC in WebRTC March 2017
We further posit that browsers that serve as KDs will have specific
objects available as part of their Document Object Model (DOM).
These objects will give applications the ability to instantiate and
control such KDs, but without actually being able to obtain access to
the keying material itself. The definition of the interface for such
objects is not defined in this document more than necessary. We
envision a companion document, submitted to the W3C, to describe this
API in detail.
The following callflows illustrate the information exchanged among
these entities:
Identity Service: This is the server that acts as in Identity
Provider (IdP), as that term is defined in
[I-D.ietf-rtcweb-security-arch]. Note that the Owner and the
Participant may use different Identity Services to vouch for their
identities.
Owner Browser: This is the web browser execution environment for the
web browser that is acting as the KD.
Owner PeerConnection: This is the RTCPeerConnection object created
and used by conferencing web application running in the Owner
Browser. It is shown separately from the Owner Browser to clearly
indicate those tasks which are performed directly by the
RTCPeerConnection without the ability for the conferencing web
application to intervene.
KD: This is the Key Distributor function created and used by the
conferencing web application running in the Owner Browser. It is
shown separately from the Owner Browser to clearly indicate those
tasks which are performed directly by the Key Distributor without
the ability for the conferencing web application to intervene.
HTTP Server: This is the HTTP server that handles the signaling for
the conference.
MD: This is the media distributor that handles the media the
conference. Note that the interface between the HTTP Server and
the MD is an implementation detail for the developer of the
conference server. The messages exchanged between them are
intended to illustrate the information required to be exchanged
between them to have a properly functioning PERC conference.
Participant Browser: This is the web browser execution environment
for a web browser that is not acting as the KD.
Roach Expires September 11, 2017 [Page 4]
Internet-Draft PERC in WebRTC March 2017
Participant PeerConnection: This is the RTCPeerConnection object
created and used by conferencing web application running in the
Participant Browser. It is shown separately from the Participant
Browser to clearly indicate those tasks which are performed
directly by the RTCPeerConnection without the ability for the
conferencing web application to intervene.
The following sub sections step through an illustrative call flow
that demonstrates how the information needed to create a PERC
conference in a WebRTC environment is exchanged among the
aforementioned functions. The call flows occur in the order shown by
these sections - division into sections is done primarily to limit
the number of elements in any diagram to no more than four, since the
limitations of the internet-draft format makes wider diagrams
impossible.
4.1.1. Conference Establishment
Roach Expires September 11, 2017 [Page 5]
Internet-Draft PERC in WebRTC March 2017
Owner KD HTTP Server MD
Browser | | |
| | | |
| | | |
|(1) GET /perc/room-identifier | |
|-------------------------------------->| |
|(2) 200 OK (with app) | |
|<--------------------------------------| |
|(3) new KD(); | | |
|------------------>| | |
|(4) kd.setIdentity(id1); | |
|------------------>| | |
|(5) kd.getFingerprint(); | |
|------------------>| | |
|(6) fingerprint | | |
|<------------------| | |
|(7) POST /start-conf (KD fingerprint) | |
|-------------------------------------->| |
| | |(8) New Conference |
| | | (KD fingerprint)|
| | |------------------>|
| | |(9) ack |
| | |<------------------|
|(10) 200 (MD name and port) | |
|<--------------------------------------| |
|(11) kd.connect(mdName,port) | |
|------------------>| | |
| |(12) TLS setup | |
| |-------------------------------------->|
| | | |
| |KD checks that MD cert matches name |
| | | |
| MD checks that the client fingerprint matches |
| | | |
| |(13) Profiles | |
| |<--------------------------------------|
|(14) resolve connect promise | |
|<------------------| | |
| | | |
1. The conference owner loads the conference application. Although
not required, information sufficient to identify the conference
is frequently sent as part of the URL.
2. The HTTP server returns the conferencing web application.
Roach Expires September 11, 2017 [Page 6]
Internet-Draft PERC in WebRTC March 2017
3. The conferencing web application instantiates a new Key
Distributor (KD) object. Upon instantiation, this KD creates a
new certificate.
4. The conferencing web app sets the owner's identity on the KD.
5. The application asks for the certificate's fingerprint...
6. ...which the KD provides
7. The application initiates the conference, including the KD cert
fingerprint as part of the initiation message.
8. The HTTP server passes the KD fingerprint along to the Media
Distributor (MD). This is used later by the MD to ensure that
the correct KD is connecting to it.
9. The MD acknowledges creation of a new conference. This
acknowledgement contains the hostname and port that the MD is
listening on for the KD to connect to.
10. The web server responds to the conferencing web app with the
hostname of the MD as well as the port it is listening on for
the KD to connect.
11. The application passes along the MD name and port to the KD
object.
12. The KD initiates a TLS connection to the MD. This connection
uses the protocol defined in [I-D.ietf-perc-dtls-tunnel]. The
KD verifies that the certificate presented by the MD matches the
name it used to connect to it, and that it chains up to a
trusted certificate authority. The MD verifies that the client
cert provided by the KD matches the fingerprint that it received
earlier from the HTTP server.
13. The MD returns its list of supported profiles, as described in
[I-D.ietf-perc-dtls-tunnel].
14. The KD object indicates to the conferencing app that the KD-MD
connection has been successfully established.
4.1.2. Owner Sends Offer to Conference
Roach Expires September 11, 2017 [Page 7]
Internet-Draft PERC in WebRTC March 2017
Identity Owner Owner HTTP
Service Browser PeerConnection Server
| | | |
| | | |
| |(1) new PC(); | |
| |------------------>| |
| |(2) setIdentity(id1); |
| |------------------>| |
| |(3) createOffer(); | |
| |------------------>| |
|(4) GET /.well-known/idp-proxy/default | |
|<--------------------------------------| |
|(5) 200 | | |
|-------------------------------------->| |
|(6) XHR POST /sign (offer) | |
|<--------------------------------------| |
|(7) 200 (signed offer) | |
|-------------------------------------->| |
| |(8) resolve createOffer() promise |
| |<------------------| |
| |(9) POST /perc/offer?room-identifier |
| |(with signed offer)| |
| |-------------------------------------->|
| | | |
1. The conferencing web application creates a new WebRTC
RTCPeerConnection (PC) object to allow sending and receiving
media.
2. The conferencing web app sets the owner's identity on the PC...
3. ...and requests an offer to be created.
4. As described in [I-D.ietf-rtcweb-security-arch], the PC requests
the IDP proxy code from the Identity Service...
5. ...which it returns.
6. Upon being executed, the idp-proxy code sends the offer to the
Identity service...
7. ...which verifies user's identity, the signs the offer, and
returns the signed offer to the PC.
8. The PC then returns the signed offer to the conferencing web app.
9. The conferencing web app sends the signed offer to the HTTP
server to begin establishing the media connection.
Roach Expires September 11, 2017 [Page 8]
Internet-Draft PERC in WebRTC March 2017
4.1.3. Conference Processes Owner Offer
Identity KD HTTP MD
Service Server
| | | |
| | |(1) signed offer |
| | |------------------>|
| | | |
| |(2) sign(offer, answer) |
| |<--------------------------------------|
|(3) GET /.well-known/idp-proxy/default | |
|<------------------| | |
|(4) 200 (with public key) | |
|------------------>| | |
|(5) GET /.well-known/idp-proxy/default | |
|<------------------| | |
|(6) 200 | | |
|------------------>| | |
|(7) XHR POST /sign (MD answer) | |
|<------------------| | |
|(8) 200 (signed MD answer) | |
|------------------>| | |
| |(9) signed answer, KD identity |
| |-------------------------------------->|
| | |(10) signed answer |
| | |<------------------|
| | | |
In this section of the flow, the MD sends generates an answer. It
sends this answer to the KD so that it can sign it with an assertion
of the KD's identity. It also sends the corresponding offer to the
KD so that the KD can validate that the authenticated party who
generated the offer is authorized to join the conference, and to
allow the KD to add that user to its own notion of the current
conference roster.
1. The HTTP server sends the signed offer to the MD to allow it to
start setting up the media connection.
2. The MD creates an answer to the received offer, and sends both
offer and answer over the MD-KD tunnel connection.
3. Similar to the PC validation procedure described in
[I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
code from the Identity Service based on the identity in the
offer...
Roach Expires September 11, 2017 [Page 9]
Internet-Draft PERC in WebRTC March 2017
4. ...which it returns. The KD uses the IDP proxy code to validate
the identity of the party that generated the offer.
5. Similar to the PC signing procedure described in
[I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
code from the Identity Service...
6. ...which it returns.
7. Upon being executed, the idp-proxy code sends the MD answer to
the Identity Service...
8. ...which verifies KD's identity, the signs the MD answer, and
returns the signed MD answer to the KD.
9. The KD sends the signed MD answer back to the MD.
10. The MD sends the signed answer to the HTTP server.
4.1.4. Owner Processes Answer
Identity Owner Owner HTTP
Service Browser PeerConnection Server
| | | |
| | | |
| | | |
| |(1) 200 (signed answer) |
| |<--------------------------------------|
| |(2) setRemoteDescription(answer) |
| |------------------>| |
|(3) GET /.well-known/idp-proxy/default | |
|<--------------------------------------| |
|(4) 200 (with public key) | |
|-------------------------------------->| |
|PC validates signature with public key from Identity Service
| | | |
| | | |
1. To complete the offer/answer exchange, the HTTP server returns
the signed answer (asserting the KD's identity) to the owner's
conference web app.
2. The conference web app sets the remote description on the PC to
the received answer
3. Using the identity validation procedure described in
[I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy
Roach Expires September 11, 2017 [Page 10]
Internet-Draft PERC in WebRTC March 2017
code from the Identity Service based on the identity in the
answer...
4. ...which it returns. The PC uses the IDP proxy code to validate
the identity of the party that generated the answer.
4.1.5. Owner sets up media connection
Note: ICE/ICE Lite is not shown in this flow, but is assumed to have
taken place.
Owner KD MD
PeerConnection
| | |
| | |
|(1) DTLS setup | |
|-------------------------------------->|
| |(2) Tunnel(DTLS setup)
| |<------------------|
|(3) Double encrypted media |
|.......................................|
| | |
| | |
1. The PC, using the addressing information present in the answer,
negotiates a DTLS association towards the MD. We make an
assumption that the SDP generated by the MD contains a port
number that is unique to the conference, allowing it to correlate
the incoming DTLS messages to the correct KD.
2. The MD uses the tunneling protocol defined in
[I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages
between the PC and the KD. These DTLS setup messages make use of
the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to
establish end-to-end keys for the media.
3. Using the mechanism described in [I-D.ietf-perc-double], the PC
now begins to send and received SRTP-encrypted media to and from
the MD.
4.1.6. Participant Joins Conference
After the conference has been established as described in the
preceding sections, each new participant triggers a flow that closely
mirrors the owner PC's interaction with the conference. These steps
are shown in the following sections.
Roach Expires September 11, 2017 [Page 11]
Internet-Draft PERC in WebRTC March 2017
HTTP Participant Participant Identity
Server Browser PeerConnection Service
| | | |
|(1) GET /perc/room-identifier | |
|<------------------| | |
|(2) 200 OK (with app) | |
|------------------>| | |
| |(3) new PC(); | |
| |------------------>| |
| |(4) setIdentity(id2); |
| |------------------>| |
| |(5) createOffer(); | |
| |------------------>| |
| | |(6) GET |
| | |/.well-known/idp-proxy/default
| | |------------------>|
| | |(7) 200 |
| | |<------------------|
| | |(8) XHR POST /sign (offer)
| | |------------------>|
| | |(9) 200 (signed offer)
| | |<------------------|
| |(10) resolve createOffer() promise |
| |<------------------| |
|(11) POST /perc/offer?room-identifier (signed offer) |
|<------------------| | |
| | | |
1. The conference owner loads the conference application. Although
not required, information sufficient to identify the conference
is frequently sent as part of the URL.
2. The HTTP server returns the conferencing web application.
3. The conferencing web application creates a new WebRTC
RTCPeerConnection (PC) object to allow sending and receiving
media.
4. The conferencing web app sets the owner's identity on the PC...
5. ...and requests an offer to be created.
6. As described in [I-D.ietf-rtcweb-security-arch], the PC requests
the IDP proxy code from the Identity Service...
7. ...which it returns.
Roach Expires September 11, 2017 [Page 12]
Internet-Draft PERC in WebRTC March 2017
8. Upon being executed, the idp-proxy code sends the offer to the
Identity service...
9. ...which verifies user's identity, the signs the offer, and
returns the signed offer to the PC.
10. The PC then returns the signed offer to the conferencing web
app.
11. The conferencing web app sends the signed offer to the HTTP
server to begin establishing the media connection.
4.1.7. Conference Processes Participant Offer
Identity KD HTTP MD
Service Server
| | | |
| | |(1) offer |
| | |------------------>|
| |(2) sign(offer, answer) |
| |<--------------------------------------|
|(3) GET /.well-known/idp-proxy/default | |
|<------------------| | |
|(4) 200 (with public key) | |
|------------------>| | |
|(5) GET /.well-known/idp-proxy/default | |
|<------------------| | |
|(6) 200 | | |
|------------------>| | |
|(7) XHR POST /sign (MD answer) | |
|<------------------| | |
|(8) 200 (signed MD answer) | |
|------------------>| | |
| |(9) signed answer, KD identity |
| |-------------------------------------->|
| | |(10) signed answer |
| | |<------------------|
| | | |
This flow is identical to conference processing of the owner's offer.
It is included here for completeness.
1. The HTTP server sends the signed offer to the MD to allow it to
start setting up the media connection.
2. The MD creates an answer to the received offer, and sends both
offer and answer over the MD-KD tunnel connection.
Roach Expires September 11, 2017 [Page 13]
Internet-Draft PERC in WebRTC March 2017
3. Similar to the PC validation procedure described in
[I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
code from the Identity Service based on the identity in the
offer...
4. ...which it returns. The KD uses the IDP proxy code to validate
the identity of the party that generated the offer.
5. Similar to the PC signing procedure described in
[I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
code from the Identity Service...
6. ...which it returns.
7. Upon being executed, the idp-proxy code sends the MD answer to
the Identity Service...
8. ...which verifies KD's identity, the signs the MD answer, and
returns the signed MD answer to the KD.
9. The KD sends the signed MD answer back to the MD.
10. The MD sends the signed answer to the HTTP server.
4.1.8. Participant Processes Answer
Identity HTTP Participant Participant
Service Server Browser PeerConnection
| | | |
| | | |
| | | |
| |(1) 200 (signed answer) |
| |------------------>| |
| | |(2) setRemoteDescription
| | | (answer) |
| | |------------------>|
|(3) GET /.well-known/idp-proxy/default | |
|<----------------------------------------------------------|
|(4) 200 (with public key) | |
|---------------------------------------------------------->|
|PC validates signature with public key from Identity Service
| | | |
This flow is identical to owner's processing of the conference's
answer. It is included here for completeness.
Roach Expires September 11, 2017 [Page 14]
Internet-Draft PERC in WebRTC March 2017
1. To complete the offer/answer exchange, the HTTP server returns
the signed answer (asserting the KD's identity) to the owner's
conference web app.
2. The conference web app sets the remote description on the PC to
the received answer
3. Using the identity validation procedure described in
[I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy
code from the Identity Service based on the identity in the
answer...
4. ...which it returns. The PC uses the IDP proxy code to validate
the identity of the party that generated the answer.
4.1.9. Participant sets up media connection
KD MDD Participant
PeerConnection
| | |
| |(1) DTLS setup |
| |<------------------|
|(2) Tunnel(DTLS setup) |
|<------------------| |
| |(3) Double encrypted media
| |...................|
| | |
This flow is identical to the owner's establishment of encrypted
media. It is included here for completeness.
1. The PC, using the addressing information present in the answer,
negotiates a DTLS association towards the MD. We make an
assumption that the SDP generated by the MD contains a port
number that is unique to the conference, allowing it to correlate
the incoming DTLS messages to the correct KD.
2. The MD uses the tunneling protocol defined in
[I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages
between the PC and the KD. These DTLS setup messages make use of
the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to
establish end-to-end keys for the media.
3. Using the mechanism described in [I-D.ietf-perc-double], the PC
now begins to send and received SRTP-encrypted media to and from
the MD.
Roach Expires September 11, 2017 [Page 15]
Internet-Draft PERC in WebRTC March 2017
4.2. Key Distributor Separate From Browser
This configuration introduces a couple of challenges. It is not
explored in depth in this version of the document; however, we
highlight the following two issues:
o Because identity in WebRTC is inherently based on evaluation of
Javascript, and because the KD must validate identities to perform
its intended purpose, the KD will be required to include a
Javascript execution environment.
o Because the KD is the only trusted node that inherently has access
to the list of active conference participants, we must introduce
additional mechanisms that allow it to convey this information to
conference participants in a way that can be authenticated.
5. New Mechanisms Required
Based on the foregoing message flows, we need to add a small number
of new mechanisms to the overall system.
5.1. New Key Distributor DOM Object
Although the formal definition of the Key Distributor DOM object will
be provided by a W3C document, the foregoing message flows imply that
we will need an interface that looks roughly like the following.
This interface is expressed using the syntax defined by
[W3C.CR-WebIDL-1-20160308], and refers to a number of structures
defined in [W3C.WD-webrtc-20170313].
interface RTCKeyDistributor : EventTarget {
void setIdentityProvider(DOMString provider,
optional RTCIdentityProviderOptions options);
Promise<DOMString> getIdentityAssertion();
readonly attribute Promise<RTCIdentityAssertion> peerIdentity;
readonly attribute DOMString? idpLoginUrl;
readonly attribute DOMString? idpErrorInfo;
Promise<RTCCertificate> getCertificate();
Promise<void> connect(DOMString mdHost, unsigned short mdPort);
attribute EventHandler onfingerprintfailure;
}
Roach Expires September 11, 2017 [Page 16]
Internet-Draft PERC in WebRTC March 2017
5.2. New "sign" Tunnel Message
We also need to add new "sign_answer" and "sign_answer_ack" MsgTypes
to the protocol defined in [I-D.ietf-perc-dtls-tunnel]. These are
used by the MD to request that the KD sign its answer.
The "SignAnswer" message is defined as follows:
struct {
opaque offer<1..2^24-1>;
opaque answer<1..2^24-1>;
} SignAnswer;
The "SignAnswerAck" message is defined as follows:
struct {
opaque answer<1..2^24-1>;
} SignAnswerAck;
6. Security Considerations
This section will be fleshed out further after the working group has
general agreement about the direction this mechanism should take.
The means by which the KD determines that the offer being presented
in the "sign" message corresponds to the current conference and has
not been replayed has not yet been analyzed.
We need to ensure that MD answers signed by the KD cannot be used by
the MD as offers in other contexts, as doing so would allow the MD to
impersonate the KD's identity.
7. IANA Considerations
This document requires no actions from IANA.
8. References
8.1. Normative References
[I-D.ietf-perc-double]
Jennings, C., Jones, P., and A. Roach, "SRTP Double
Encryption Procedures", draft-ietf-perc-double-02 (work in
progress), October 2016.
Roach Expires September 11, 2017 [Page 17]
Internet-Draft PERC in WebRTC March 2017
[I-D.ietf-perc-dtls-tunnel]
Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
between a Media Distributor and Key Distributor to
Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00
(work in progress), March 2017.
[I-D.ietf-perc-srtp-ekt-diet]
Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
"Encrypted Key Transport for Secure RTP", draft-ietf-perc-
srtp-ekt-diet-02 (work in progress), October 2016.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-12 (work in progress), June 2016.
[W3C.CR-WebIDL-1-20160308]
McCormack, C. and B. Zbarsky, "WebIDL Level 1", World Wide
Web Consortium CR CR-WebIDL-1-20160308, March 2016,
<http://www.w3.org/TR/2016/CR-WebIDL-1-20160308>.
[W3C.WD-webrtc-20170313]
Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A.,
and B. Aboba, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc-
20170313, March 2017, <https://www.w3.org/TR/2017/WD-
webrtc-20170313>.
8.2. Informative References
[I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-02
(work in progress), October 2016.
Author's Address
Adam Roach
Mozilla
\
Dallas
US
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com
Roach Expires September 11, 2017 [Page 18]