Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS and COMMENT)

[Sean Turner <[e-mail]>]

I didn’t get all the way through the comments, but I got a pretty start.  If there’s 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 <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-rtcweb-security-arch-18: Discuss
> 
> 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.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
> 
> 
> 
> ----------------------------------------------------------------------
> 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’ll 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’ll 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’m 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’t 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
> 
> (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
> 
>   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
> 
> 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’ll drop preferably.  Fixed in the “comment" 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.  [...]
> 
> 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’t 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
> 
>   Once the ICE checks have completed [more specifically, once some ICE
>   checks have completed], [...]
> 
> nit: that's not really more specific.  Maybe "Once the requisite ICE
> checks have completed”?

Sounds good.  Fixed in the comments PR.

> Section 5
> 
> I see that the 4566 <base64> includes the pad characters, though
> sometimes we will mention explicitly whether they are or are not
> included.
> 
>   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.
> 
> leading whitespace, too, right?

Yes :). Fixed in the comments PR.

> Section 5.1
> 
>   This section defines the SDP Offer/Answer [RFC6454] considerations
>   for the SDP 'identity' attribute.
> 
> 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
> 
> I feel like we need some text here about the (non?)trustworthiness of
> the IdP.
> 
> Section 5.1.4
> 
> 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?
> 
>                  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.
> 
> nit: is this "each media section"/"every media section" redundant?
> 
> Section 6.1
> 
>   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.
> 
> 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.
> 
> Section 6.2
> 
>   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.
> 
> Just to check: this last sentence applies for one-time requets, too?
> 
>                                           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.  [...]
> 
> 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".
> 
>   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()).  [...]
> 
> Do we need to say anything about that state transition being visible to
> the peer, here?
> 
>   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.]
> 
> nit: s/windows/window/?
> 
>   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).
> 
> Is there anything to say about why clients might not opt to do so (and
> what such approval might look like)?
> 
> (My comments about "verified user" including the IdP in some way will
> apply here as well.)
> 
> Section 6.3
> 
>   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
> 
> Is the "the current WG consensus" language going to age well?
> 
>   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].
> 
> Is there a WIP draft for this separate document?
> 
> Section 6.4
> 
>   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.
> 
> nit: maybe make it more clear that this only applies for incoming calls?
> 
> Section 6.5
> 
>                                                           Media traffic
>   MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
>   implementations MUST NOT negotiate cipher suites with NULL encryption
>   modes.  [...]
> 
> 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?)
> 
> [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note]
> 
>   Implementations MUST NOT implement DTLS renegotiation and MUST reject
>   it with a "no_renegotiation" alert if offered.
> 
> "MUST NOT implement" isn't really something that 2119 language can
> enforce; "MUST NOT use" is the best we can get.
> 
>   Endpoints MUST NOT implement TLS False Start [RFC7918].
> 
> (7918 doesn't claim to be applicable to DTLS anyway)
> 
> 
>   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.)
> 
> nit: might be appropriate to note why we care about a super-cookie (and
> what it is)
> 
>      *  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.
> 
> I'm not sure I see anywhere that we allow the usage of null ciphers.
> 
> Section 7
> 
>   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
>   [e-mail].  [...]
> 
> I agree with Alissa that the first person is not needed here.
> 
> Section 7.1
> 
>   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.
> 
> This probably needs some qualifier, given recent developments with CAA
> and similar mechanisms.
> 
>   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
> 
> The RP still needs to establish somehow that the IdP in use is in fact
> an authoritative IdP, though!
> 
> Section 7.2
> 
>   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
> 
> A reference to that W3C API spec might be handy.
> 
> Section 7.3
> 
>   There are two parts to this work:
> 
>   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.
> 
> 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.
> 
> Section 7.4
> 
> 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
> 
> I'm a little confused what this "encoded in a JSON string" is supposed
> to mean.
> 
>   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.
> 
> The IdP probably wants to know enough about its structure to not turn
> into a signing oracle for other protocols, though.

It’s as specified in the webrtc-api :)

> Section 7.4.1
> 
> (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention
> that.)

True but it doesn’t 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.
> 
> leading whitespace, too, right?

Yes :) Added in the comments PR.

> Section 7.5.2
> 
> (Still need to say how it's know than authoritative assertions are in
> fact authoritative for what they claim.)
> 
> Section 7.6
> 
>   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.
> 
> (IdP still doesn't want to become a signing oracle.)
> 
>   For use in signaling, the assertion is serialized into JSON,
>   Base64-encoded [RFC4648], and used as the value of the "identity"
>   attribute.
> 
> nit: it's unclear that "serialized into JSON" adds any value, since the
> thing is defined to be a JSON object.
> 
> Section 7.7
> 
> 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).
> 
> Section 8
> 
>   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.
> 
> IMPORTANT: Do we need a freshness property for the assertion?  Some of
> these schemes do not provide freshness.
> 
>   Figure 6 shows an example response formatted as JSON for illustrative
>   purposes.
> 
> (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
> 
>   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:
> 
> 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’s “and” after the first sub-bullet I’ll add “both”.

>   Any "@" or "%" characters in the "user" portion of the identity MUST
>   be escaped according to the "Percent-Encoding" rules defined in
> 
> We just said in the first paragraph that "user" has "any character
> except '@'", so this is a bit redundant.

I dropped “except ‘@‘ from the 1st para.  Somebody will tell me if I did this wrong, but there is some kind of x1

> Section 9.1
> 
>            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.
> 
> I suppose an "untrustworthy" IdP is basically a malicious one, though
> there are perhaps some subtleties that could be distinguished here.
> 
>   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.
> 
> 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?
> 
> Section 9.2
> 
>   Otherwise, the other side will learn linkable information.
> 
> nit: "linkable information that would allow them to correlate the
> browser across multiple calls”.

Added in the comments PR.

> Section 9.3
> 
>   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.
> 
> 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?
> 
>              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.
> 
> nit: "must be used to suppress the misbehaving flow", I think.
> 
> Section 9.4.3
> 
>   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.
> 
> I don't see an "origin" field in the signature request; is this supposed
> to be the "domain”?

Changed it to “domain” to match the structure.  Also, instead of "signature request” I change it to “assertion request” to match the earlier heading title.

> Section 9.4.5.1
> 
> nit: it might be friendlier to the reader to prefix this with "When
> popup blocking is in use, “.

Added in comments PR.

> Section 13.2
> 
> It's perhaps debatable that JSEP is only an informative reference.

Moved it to normative in the comments PR.