Draft: draft-ietf-rtcweb-security-arch

Commentary: I 've found a few typos and fixed some sentences that did n't quite make sense . I do n't think the meaning has been changed in any significant way .
Paragraph (version A):
For simplicity, assume the topology in fig.proposal.idp.  Alice and
Bob are both users of a common calling service; they both have
approved the calling service to make calls (we defer the discussion
of device access permissions till later).  They are both connected to
the calling service via HTTPS and so know the origin with some level
of confidence.  They also have accounts with some identity provider.
This sort of identity service is becoming increasingly common in the
Web environment in technologies such (BrowserID, Federated Google
Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often
provided as a side effect service of a user's ordinary accounts with
some service.  In this example, we show Alice and Bob using a
separate identity service, though the identity service may be the
same entity as the calling service or there may be no identity
service at all.
Paragraph (version B):
For simplicity, assume the topology in fig.proposal.idp.  Alice and
Bob are both users of a common calling service; they both have
approved the calling service to make calls (we defer the discussion
of device access permissions till later).  They are both connected to
the calling service via HTTPS and so know the origin with some level
of confidence.  They also have accounts with some identity provider.
This sort of identity service is becoming increasingly common in the
Web environment (with technologies such as BrowserID, Federated
Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is
often provided as a side effect service of a user's ordinary accounts
with some service.  In this example, we show Alice and Bob using a
separate identity service, though the identity service may be the
same entity as the calling service or there may be no identity
service at all.
Paragraph (version A):
The one remaining security property we need to establish is "consent
freshness", i.e., allowing Alice to verify that Bob is still prepared
to receive her communications so that Alice does not continue to send
large traffic volumes to entities which went abruptly offline.  ICE
specifies periodic STUN keepalizes but only if media is not flowing.
Because the consent issue is more difficult here, we require RTCWeb
implementations to periodically send keepalives.  As described in
Section 5.3, these keepalives MUST be based on the consent freshness
mechanism specified in I-D.muthu-behave-consent-freshness.  If a
keepalive fails and no new ICE channels can be established, then the
session is terminated.
Paragraph (version B):
The one remaining security property we need to establish is "consent
freshness", i.e., allowing Alice to verify that Bob is still prepared
to receive her communications so that Alice does not continue to send
large traffic volumes to entities which went abruptly offline.  ICE
specifies periodic STUN keepalives but only if media is not flowing.
Because the consent issue is more difficult here, we require WebRTC
implementations to periodically send keepalives.  As described in
Section 5.3, these keepalives MUST be based on the consent freshness
mechanism specified in I-D.muthu-behave-consent-freshness.  If a
keepalive fails and no new ICE channels can be established, then the
session is terminated.
Paragraph (version A):
While continuing consent is required, that ICE RFC5245; Section 10
keepalives STUN Binding Indications are one-way and therefore not
sufficient.  The current WG consensus is to use ICE Binding Requests
for continuing consent freshness.  ICE already requires that
implementations respond to such requests, so this approach is
maximally compatible.  A separate document will profile the ICE
timers to be used; see I-D.muthu-behave-consent-freshness.
Paragraph (version B):
While continuing consent is required, the ICE RFC5245; Section 10
keepalives use STUN Binding Indications which are one-way and
therefore not sufficient.  The current WG consensus is to use ICE
Binding Requests for continuing consent freshness.  ICE already
requires that implementations respond to such requests, so this
approach is maximally compatible.  A separate document will profile
the ICE timers to be used; see I-D.muthu-behave-consent-freshness.
Paragraph (version A):
Recently, a number of Web-based identity technologies (OAuth,
BrowserID, Facebook Connect), etc. have been developed.  While the
details vary, what these technologies share is that they have a Web-
based (i.e., HTTP/HTTPS) identity provider which attests to your
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
alice@example.org.  The development of these technologies allows us
to separate calling from identity provision: I could call you on
Poker Galaxy but identify myself as alice@example.org.
Paragraph (version B):
Recently, a number of Web-based identity technologies (OAuth,
BrowserID, Facebook Connect etc.) have been developed.  While the
details vary, what these technologies share is that they have a Web-
based (i.e., HTTP/HTTPS) identity provider which attests to your
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
alice@example.org.  The development of these technologies allows us
to separate calling from identity provision: I could call you on
Poker Galaxy but identify myself as alice@example.org.
Paragraph (version B):
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.  This is specified in
sec.jsep-binding.
Paragraph (version A):
The specific IdP protocol which the IdP is using.  This is a
completely opaque IdP-specific string, but allows an IdP to
implement two protocols in parallel.  This value may be the empty
string.
Paragraph (version B):
The specific IdP protocol which the IdP is using.  This is a
completely opaque IdP-specific string, but allows an IdP to
implement multiple protocols in parallel.  This value may be the
empty string.
Paragraph (version A):
Consider the case of a call center which accepts calls via RTCWeb.
Paragraph (version B):
Consider the case of a call center which accepts calls via WebRTC.
Paragraph (version A):
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
own IFRAME, loading the IdP proxy HTML/JS, and requesting a
signature.  In order to prevent this attack, we require that all
signatures be tied to a specific origin ("rtcweb://...") which cannot
be produced by content JavaScript.  Thus, while an attacker can
instantiate the IdP proxy, they cannot send messages from an
appropriate origin and so cannot create acceptable assertions.  I.e.,
the assertion request must have come from the browser.  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 WebRTC.  The IdP
simply needs to gather the origin information (from the posted
message) and attach it to the assertion.
Paragraph (version B):
Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by
the browser, so nothing stops a Web attacker from creating their own
IFRAME, loading the IdP proxy HTML/JS, and requesting a signature.
In order to prevent this attack, we require that all signatures be
tied to a specific origin ("rtcweb://...") which cannot be produced
by content JavaScript.  Thus, while an attacker can instantiate the
IdP proxy, they cannot send messages from an appropriate origin and
so cannot create acceptable assertions.  I.e., the assertion request
must have come from the browser.  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 WebRTC.  The IdP simply needs to gather the
origin information (from the posted message) and attach it to the
assertion.