Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <155192582265.13773.4546017380973569678.idtracker@ietfa.amsl.com>
Date: Sun, 14 Apr 2019 13:02:39 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-rtcweb-security-arch@ietf.org,
 rtcweb-chairs@ietf.org, rtcweb@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <746BFA74-9B05-4754-B610-ED24BF0EC049@sn3rd.com>
References: <155192582265.13773.4546017380973569678.idtracker@ietfa.amsl.com>
To: Datatracker on behalf of Benjamin Kaduk <noreply@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/kYEiypx5Y3iROhIHLuGoJ8PEsQc>
Subject: Re: [rtcweb] Benjamin Kaduk's Discuss on
 draft-ietf-rtcweb-security-arch-18: (with DISCUSS and COMMENT)
Precedence: list

I didn=E2=80=99t get all the way through the comments, but I got a =
pretty start.  If there=E2=80=99s something else we need to discuss I =
can organize a time to get folks on a call.

> On Mar 6, 2019, at 21:30, Datatracker on behalf of Benjamin Kaduk =
<noreply@ietf.org> wrote:
>=20
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-rtcweb-security-arch-18: Discuss
>=20
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut =
this
> introductory paragraph, however.)
>=20
>=20
> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------

I filed an issue here for these:
https://github.com/rtcweb-wg/security-arch/issues/89

> The question of when an IdP is trustworthy, whether at all (even for
> "authoritative" IdPs) or for a specific user, is a pretty core topic =
for
> the identity assertion scheme presented here.  These topics do get
> explained in localized sections of the document, but there seem to be
> other portions of the text that do not really acknowledge the risks.
> I've tried to note these in the COMMENT section (though having =
finished
> reading the document, perhaps I am overzealous about determination =
that
> an authoritative IdP is indeed authoritative).

Thanks for the parenthetical ;). We=E2=80=99ll pick through them and see =
what we can do.

> I also think that we need to be more careful about having the IdP know
> the semantics of what it's signing (or otherwise attesting to), so =
that
> it does not turn into a signing oracle, etc..

I am trying to figure out what we could include to address this.  I have =
to tell you my first thought is that the IdP is just doing its job, =
i.e., it signs assertions that an authenticated party wants signed.

> The "Modifying the Session" treatment for the SDP "identity" attribute
> seems incompletely specified.

I am hoping you might expand here a bit on what you think might be =
needed.  We had the SDP directorate review and they (Christer) gave it =
the thumbs up.

> I'm a bit unclear about how the port in the IdP URI's Authority =
(Section
> 7.5) would get discovered.  If it can be remotely supplied, there may =
be
> risks in just trusting blindly whatever value is received.

Ted started a thread on this here:
https://mailarchive.ietf.org/arch/msg/rtcweb/8dtCkSeXWUsb_y2SRyFlbQ5r93w
We=E2=80=99ll see where it lands.

> It seems like there are some unstated privacy considerations in =
allowing
> the IdP proxy to automatically generate an assertion (that reveals the
> user's identity) at the request of javascript from the calling
> application, as described in Section 7.7.

I=E2=80=99m struggling to think what more might be said because the AP =
is asking the IdP to vouch for its identity so the IdP is literally =
doing what the AP asked it to do.

> Section 9.4 talks about how the IdP is attesting to the binding of the
> user identified in the assertion with the key fingerprints, but in
> Sections 7.4 and 7.6 we claim that this assertion is "opaque to the
> IdP"; these statements appear to be in conflict with each other.

I think that all three sections are consistent wrt to the IdP binding =
the user identified in the assertion with the key fingerprints.  Section =
7.4 and 7.6 are just saying that the IdP doesn=E2=80=99t need to know =
what it is signing.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

I filed an issue for this here:
https://github.com/rtcweb-wg/security-arch/issues/90

> Section 3
>=20
> (My comment about TCB and the other browser from the companion =
document
> is probably relevant here, too.)

I am hoping the text that we put in the -security draft address this =
concern.

> Section 4.1
>=20
>   This message is sent to the signaling server, e.g., by =
XMLHttpRequest
>   [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS
>   [RFC5246].  The signaling server processes the message from Alice's
>=20
> This is the optimistic "best security" case, and we already say we're
> talking to the signaling server over HTTPS, so it should be safe to =
just
> say "over TLS" and drop the "preferably".  (Also, s/5246/8446.)

Sure I=E2=80=99ll drop preferably.  Fixed in the =E2=80=9Ccomment" PR:
https://github.com/rtcweb-wg/security-arch/pull/91

>   call and to Alice's identity.  In this case, Alice has provided an
>   identity assertion and so Bob's browser contacts Alice's identity
>   provider (again, this is done in a generic way so the browser has no
>   specific knowledge of the IdP) to verify the assertion.  This allows
>   the browser to display a trusted element in the browser chrome
>   indicating that a call is coming in from Alice.  [...]
>=20
> I think I'm confused.  We're displaying trusted browser chrome based =
on
> an assertion from some IdP that we have no relationship with and no
> reason to trust?

Don=E2=80=99t forget this part from earlier in the Section:

  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.

> Section 4.3
>=20
>   Once the ICE checks have completed [more specifically, once some ICE
>   checks have completed], [...]
>=20
> nit: that's not really more specific.  Maybe "Once the requisite ICE
> checks have completed=E2=80=9D?

Sounds good.  Fixed in the comments PR.

> Section 5
>=20
> I see that the 4566 <base64> includes the pad characters, though
> sometimes we will mention explicitly whether they are or are not
> included.
>=20
>   Note that long lines in the example are folded to meet the column
>   width constraints of this document; the backslash ("\") at the end =
of
>   a line and the carriage return that follows shall be ignored.
>=20
> leading whitespace, too, right?

Yes :). Fixed in the comments PR.

> Section 5.1
>=20
>   This section defines the SDP Offer/Answer [RFC6454] considerations
>   for the SDP 'identity' attribute.
>=20
> 6454 is "the Web Origin Concept"; presumably this is supposed to be
> 4566 (or 3264?).

good catch.  Fixed in the comments PR

> Section 5.1.3
>=20
> I feel like we need some text here about the (non?)trustworthiness of
> the IdP.
>=20
> Section 5.1.4
>=20
> I'm a bit confused at what's going on here.  Is "MAY send the same"
> supposed to prevent changing it?  If I don't send it, does that =
identity
> continue to apply to the existing DTLS connections but not any new =
ones
> generated by the session modification?  Am I allowed to send a =
different
> one?
>=20
>                  Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1
>   requires that each media section use the same set of fingerprints =
for
>   every media section.
>=20
> nit: is this "each media section"/"every media section" redundant?
>=20
> Section 6.1
>=20
>   Also note that the security architecture depends on the keying
>   material not being available to move between origins.  But, it is
>   assumed that the identity assertion can be passed to anyone that the
>   page cares to.
>=20
> There may be some (weak) privacy considerations if this is literally
> anyone, since it would allow some observers (with weird
> abilities/restrictions) to associate "real" identities with keys in a
> way that they couldn't otherwise do.
>=20
> Section 6.2
>=20
>   Because HTTP origins cannot be securely established against network
>   attackers, implementations MUST NOT allow the setting of permanent
>   access permissions for HTTP origins.  Implementations MUST refuse =
all
>   permissions grants for HTTP origins.
>=20
> Just to check: this last sentence applies for one-time requets, too?
>=20
>                                           The semantics of this =
request
>   are that the media stream from the camera and microphone will only =
be
>   routed through a connection which has been cryptographically =
verified
>   (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
>   handshake) as being associated with the stated identity.  [...]
>=20
> Does this need to be an exhaustive list or can we leave it open-ended?
> Also, it may be appropriate to mention some concept of "IdP trusted to
> authenticate the stated identity".
>=20
>   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
>      MediaStream.record()).  [...]
>=20
> Do we need to say anything about that state transition being visible =
to
> the peer, here?
>=20
>   UI Requirement:  If the UI indication of camera/microphone use are
>      [...]
>      camera and microphone input when the indication is hidden.  =
[Note:
>      this may not be necessary in systems that are non-windows-based
>      but that have good notifications support, such as phones.]
>=20
> nit: s/windows/window/?
>=20
>   Clients MAY permit the formation of data channels without any direct
>   user approval.  Because sites can always tunnel data through the
>   server, further restrictions on the data channel do not provide any
>   additional security.  (though see Section 6.3 for a related issue).
>=20
> Is there anything to say about why clients might not opt to do so (and
> what such approval might look like)?
>=20
> (My comments about "verified user" including the IdP in some way will
> apply here as well.)
>=20
> Section 6.3
>=20
>   While continuing consent is required, the ICE [RFC8445]; Section 10
>   keepalives use STUN Binding Indications which are one-way and
>   therefore not sufficient.  The current WG consensus is to use ICE
>=20
> Is the "the current WG consensus" language going to age well?
>=20
>   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 [RFC7675].
>=20
> Is there a WIP draft for this separate document?
>=20
> Section 6.4
>=20
>   API Requirement:  The API MUST provide a mechanism to allow the JS =
to
>      suppress ICE negotiation (though perhaps to allow candidate
>      gathering) until the user has decided to answer the call [note:
>      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
>      address if they elect not to answer a call and also from learning
>      whether the user is online.
>=20
> nit: maybe make it more clear that this only applies for incoming =
calls?
>=20
> Section 6.5
>=20
>                                                           Media =
traffic
>   MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
>   implementations MUST NOT negotiate cipher suites with NULL =
encryption
>   modes.  [...]
>=20
> It's not clear to me that the "that is" reflects a strict equivalence;
> would "in particular" be more appropriate?
> (Also, "cipher suite" is a DTLS term, but do we want to disambiguate
> explicitly?)
>=20
> [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note]
>=20
>   Implementations MUST NOT implement DTLS renegotiation and MUST =
reject
>   it with a "no_renegotiation" alert if offered.
>=20
> "MUST NOT implement" isn't really something that 2119 language can
> enforce; "MUST NOT use" is the best we can get.
>=20
>   Endpoints MUST NOT implement TLS False Start [RFC7918].
>=20
> (7918 doesn't claim to be applicable to DTLS anyway)
>=20
>=20
>   API Requirement:  Unless the user specifically configures an =
external
>      key pair, different key pairs MUST be used for each origin.  =
(This
>      avoids creating a super-cookie.)
>=20
> nit: might be appropriate to note why we care about a super-cookie =
(and
> what it is)
>=20
>      *  The "security characteristics" MUST indicate the cryptographic
>         algorithms in use (For example: "AES-CBC".)  However, if Null
>         ciphers are used, that MUST be presented to the user at the
>         top-level UI.
>=20
> I'm not sure I see anywhere that we allow the usage of null ciphers.
>=20
> Section 7
>=20
>   Recently, a number of Web-based identity technologies (OAuth,
>   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.  [...]
>=20
> I agree with Alissa that the first person is not needed here.
>=20
> Section 7.1
>=20
>   Third-Party:   IdPs which don't have control of their section of the
>      [...]
>      identity space.  Probably the best-known example of a third-party
>      identity provider is SSL/TLS certificates, where there are a =
large
>      number of CAs all of whom can attest to any domain name.
>=20
> This probably needs some qualifier, given recent developments with CAA
> and similar mechanisms.
>=20
>   If an AP is authenticating via an authoritative IdP, then the RP =
does
>   not need to explicitly configure trust in the IdP at all.  The
>=20
> The RP still needs to establish somehow that the IdP in use is in fact
> an authoritative IdP, though!
>=20
> Section 7.2
>=20
>   In order to provide security without trusting the calling site, the
>   PeerConnection component of the browser must interact directly with
>   the IdP.  The details of the mechanism are described in the W3C API
>   specification, but the general idea is that the PeerConnection
>=20
> A reference to that W3C API spec might be handy.
>=20
> Section 7.3
>=20
>   There are two parts to this work:
>=20
>   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.  This is specified in
>      Section 7.4.
>=20
> nit: the grammar is a bit weird here, as the "information from the
> signaling message" isn't really a part of this work, but rather the
> specification for what information that is.
>=20
> Section 7.4
>=20
> The indentation of the line with "}, {" is a bit confusing.

I tweaked it a bit in the comments PR.

>   This object is encoded in a JSON [RFC8259] string for passing to the
>   IdP.  The identity assertion returned by the IdP, which is encoded =
in
>=20
> I'm a little confused what this "encoded in a JSON string" is supposed
> to mean.
>=20
>   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 merely
>   treats it as an opaque value to be attested to.  Thus, new =
parameters
>   can be added to the assertion without modifying the IdP.
>=20
> The IdP probably wants to know enough about its structure to not turn
> into a signing oracle for other protocols, though.

It=E2=80=99s as specified in the webrtc-api :)

> Section 7.4.1
>=20
> (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention
> that.)

True but it doesn=E2=80=99t really hurt to leave it.

> It's a little surprising to see sha-1 fingerprint in use (since
> "examples are recommendations"), though I didn't find anything that
> would actually formally deprecate such usage yet.

Can somebody please generate a SHA-256 example for me?

>   Note that long lines in the example are folded to meet the column
>   width constraints of this document; the backslash ("\") at the end =
of
>   a line and the carriage return that follows shall be ignored.
>=20
> leading whitespace, too, right?

Yes :) Added in the comments PR.

> Section 7.5.2
>=20
> (Still need to say how it's know than authoritative assertions are in
> fact authoritative for what they claim.)
>=20
> Section 7.6
>=20
>   The input to identity assertion is the JSON-encoded object described
>   in Section 7.4 that contains the set of certificate fingerprints the
>   browser intends to use.  This string is treated as opaque from the
>   perspective of the IdP.
>=20
> (IdP still doesn't want to become a signing oracle.)
>=20
>   For use in signaling, the assertion is serialized into JSON,
>   Base64-encoded [RFC4648], and used as the value of the "identity"
>   attribute.
>=20
> nit: it's unclear that "serialized into JSON" adds any value, since =
the
> thing is defined to be a JSON object.
>=20
> Section 7.7
>=20
> I think that the framing of HTTP Basic (7617) here is not great.
> RFC 7235 might be a better link for HTTP Authentication in general, =
and
> of course there are mechanisms that don't include sending the password
> in plaintext, like SCRAM (RFC7804).
>=20
> Section 8
>=20
>   The IdP proxy verifies the assertion.  Depending on the identity
>   protocol, the proxy might contact the IdP server or other servers.
>   For instance, an OAuth-based protocol will likely require using the
>   IdP as an oracle, whereas with a signature-based scheme might be =
able
>   to verify the assertion without contacting the IdP, provided that it
>   has cached the relevant public key.
>=20
> IMPORTANT: Do we need a freshness property for the assertion?  Some of
> these schemes do not provide freshness.
>=20
>   Figure 6 shows an example response formatted as JSON for =
illustrative
>   purposes.
>=20
> (Doesn't the W3C API spec need to say how the response is formatted?  =
Is
> the JSON formatting actually "illustrative" then, or is this just an
> example output?)

he webrtc-api spec says its JSON so:

 Figure 6 shows an example response, which is JSON-formatted.

> Section 8.1
>=20
>   2.  If the domain portion of the string is not equal to the domain
>       name of the IdP proxy, then the PeerConnection object MUST =
reject
>       the assertion unless:
>=20
> Reading closely, I think this is supposed to be "unless either", but
> it's easy to assume it should be read as "unless both", so I think
> clarification is in order.

since it=E2=80=99s =E2=80=9Cand=E2=80=9D after the first sub-bullet =
I=E2=80=99ll add =E2=80=9Cboth=E2=80=9D.

>   Any "@" or "%" characters in the "user" portion of the identity MUST
>   be escaped according to the "Percent-Encoding" rules defined in
>=20
> We just said in the first paragraph that "user" has "any character
> except '@'", so this is a bit redundant.

I dropped =E2=80=9Cexcept =E2=80=98@=E2=80=98 from the 1st para.  =
Somebody will tell me if I did this wrong, but there is some kind of x1

> Section 9.1
>=20
>            Users who wish to assure themselves of security against a
>   malicious identity provider can only do so by verifying peer
>   credentials directly, e.g., by checking the peer's fingerprint
>   against a value delivered out of band.
>=20
> I suppose an "untrustworthy" IdP is basically a malicious one, though
> there are perhaps some subtleties that could be distinguished here.
>=20
>   In order to protect against malicious content JavaScript, that
>   JavaScript MUST NOT be allowed to have direct access to---or perform
>   computations with---DTLS keys.  For instance, if content JS were =
able
>   to compute digital signatures, then it would be possible for content
>   JS to get an identity assertion for a browser's generated key and
>   then use that assertion plus a signature by the key to authenticate =
a
>   call protected under an ephemeral Diffie-Hellman (DH) key controlled
>   by the content JS, thus violating the security guarantees otherwise
>   provided by the IdP mechanism.
>=20
> I don't think I fully understand the scenario described in this last
> sentence.  Is "compute digital signatures" supposed to be with some
> specific secret key, and/or is "a browser's generated key" one that is
> covered under the fingerprint in the IdP assertion?
>=20
> Section 9.2
>=20
>   Otherwise, the other side will learn linkable information.
>=20
> nit: "linkable information that would allow them to correlate the
> browser across multiple calls=E2=80=9D.

Added in the comments PR.

> Section 9.3
>=20
>   Consider the case of a call center which accepts calls via WebRTC.
>   An attacker proxies the call center's front-end and arranges for
>   multiple clients to initiate calls to the call center.  Note that
>   this requires user consent in many cases but because the data =
channel
>   does not need consent, he can use that directly.
>=20
> I think I'm missing a step here.  How is the attacker using the data
> channel directly when the point is to get the multiple browsers to =
send
> the data on the data channel?
>=20
>              Muxing multiple media flows over a single transport makes
>   it harder to individually suppress a single flow by denying ICE
>   keepalives.  Either media-level (RTCP) mechanisms must be used or =
the
>   implementation must deny responses entirely, thus terminating the
>   call.
>=20
> nit: "must be used to suppress the misbehaving flow", I think.
>=20
> Section 9.4.3
>=20
>   The "origin" field of the signature request can be used to check =
that
>   the user has agreed to disclose their identity to the calling site;
>   because it is supplied by the PeerConnection it can be trusted to be
>   correct.
>=20
> I don't see an "origin" field in the signature request; is this =
supposed
> to be the "domain=E2=80=9D?

Changed it to =E2=80=9Cdomain=E2=80=9D to match the structure.  Also, =
instead of "signature request=E2=80=9D I change it to =E2=80=9Cassertion =
request=E2=80=9D to match the earlier heading title.

> Section 9.4.5.1
>=20
> nit: it might be friendlier to the reader to prefix this with "When
> popup blocking is in use, =E2=80=9C.

Added in comments PR.

> Section 13.2
>=20
> It's perhaps debatable that JSEP is only an informative reference.

Moved it to normative in the comments PR.