Subject: [rtcweb] Detailed Review of draft-ietf-rtcweb-security-03

From: Jim McEachern <[email-masked]>
Date: Thu, 12 Jul 2012 12:57:42 -0700 (PDT)

I agreed to provide a detailed review of the security drafts before Vancouver. Here are my comments on draft-ietf-rtcweb-security-03.

Section
3: the browser threat model. One of the key concepts that I took from the discussion on the mailing list was the idea that in the standard Web threat model, when you download malicious code you mainly hurt yourself. I know this is not completely true, but with WebRTC, malicious code can do significantly more harm to others by sending real time media to them. Some requirements, like user consent, follow explicitly from this.  This idea does not seem to be discussed at all in the threat model, though later sections (e.g. section 4.2) discuss the requirements that follow from this. If you agree that it would be worth articulating this idea explicitly, I am willing to propose draft text for this section - let me know.
 
Section
3.0: says "Thus, when analyzing HTTP connections, we must assume that
traffic is going to the attacker.". Should this be "... going to /
coming from the attacker"? 
 
Section
4.1: says "without some access restrictions on local devices,
...". This makes it sound like the restrictions are being applied to the
local devices rather than restrictions being applied to the ability of the
WS/JS to access resources on the local devices.
 
 Section 4.1 final paragraph.  Says: "By contrast, consent to send
network traffic is about preventing the user’s
browser from being used to attack its local network."
Why the mention of "its local network". Don't we want to stop all attacks?

Section
4.1.2 starts: " Now that we have seen another use case, ...". Might
make more sense to start with "The use cases outlined in section 4.1.1 allow us to start reasoning about security requirements." 
 
Nit: Section
4.1.2 second paragraph - instead of "this creates" use
"this would create"
 
Section
4.1.2:"Individual
Consent-  Ask the user for permission for each
call."
 
The word
"individual" has multiple meanings - e.g. the individual person, rather than the individual call. It might be less ambiguous to
call this category "per-use" or "per-call" consent.
 
Section
4.1.2: second last paragraph has the following sentence:
"Callee-oriented
consent provided by the calling site notwork well because a malicious site can claim
that the user is callingany user of his choice."
 
This
sentence need a word before "not" - perhaps "does" not or
"will" not.
 
Section
4.2: is it worth stating explicitly that it is the browser that must enforce the
requirement to not send traffic, other than the consent handshake, until the
target has explicitly consented?
 
4.2.1.
ICE
The first
paragraph uses the term "site" for most of the paragraph, but near the
end refers to the "Web application". I believe that using the term
"Web application" throughout the paragraph (instead of "site) would make the meaning
much clearer.  If you agree, then the change will also have to be applied to some of the following paragraphs.

The next
paragraph says " Obviously, some ICE-based mechanism will work here, but
it has been observed that because ICE keepalives are indications, they will not
work here, so some other mechanism is needed."  This seems to be saying that ICE will work,
but it won't work...  Perhaps this could
be reworded to get something like this: 
"Obviously,
ICE-based mechanisms could be used to indicate a degree of continuing consent,
but it has been observed that because ICE keepalives are indications, they will
not provide the necessary level of explicit consent required here, so some
other mechanism is needed."
 
Section
4.2.3 Backward Compatibility: the first paragraph includes this sentence...
"The
message/reply pair must be generated in such a way that an
   attacker who controls the Web application
cannot forge them,
   generally by having the message contain some
secret value that must
   be incorporated..."
 
The
intent would be clearer if this read "... some secret value, known only to
the browsers, that must be incorporated..."
 
Nit: Second
bullet is:
- Use or
RTCP as an implicit reachability check.
Should
this be "Use of RTCP..." - i.e. change "or" to "of".

Third
paragraph, describing the STUN approach, is confusing, although the next
paragraph mostly clarifies. It might be clearer if you deleted the last two
sentences of the third paragraph, and merged it with the fourth.  This would give you:
 
In the
STUN approach, the RTC-Web endpoint is able to verify that the
   recipient is running some kind of STUN
endpoint but unless the STUN
   responder is integrated with the ICE
username/password establishment
   system, the RTC-Web endpoint cannot verify
that the recipient
   consents to this particular call. If the
systems are tightly integrated (i.e., the STUN endpoint
   responds with responses authenticated with
ICE credentials) then this
   issue does not exist.  However, such a design is very close to an
   ICE-Lite implementation (indeed, arguably is
one).  An intermediate
   approach would be to have a STUN extension
that indicated that one
   was responding to RTC-Web checks but not
computing integrity checks
   based on the ICE credentials.  This would allow the use of standalone STUN
servers without the risk of confusing them with legacy STUN
   servers.  If a non-ICE legacy solution is needed, then this is
   probably the best choice.
 
Final
paragraph says "...where two people briefly share an IP..." I think
something is missing after IP. An IP connection? An IP session? 
 
Section
4.2.4 Location Privacy: includes the following sentence: 
"In
order to avoid tracking, implementations may wish to
   suppress the start of ICE negotiation until
the callee has answered."
 
This will
not "avoid tracking", it only prevents people from being able to
determine the IP address before the callee answers. The meaning could be clarified by changing "avoid tracking" to "prevent callers from
learning a callees IP address even if the callee does not answer the call".  Alternatively you could elaborate somewhat by
expanding "tracking" to say "silently tracking a person by
initiating calls, but disconnecting as soon as you receive the IP address from
ICE, but before the callee is alerted"
 
Nit: 4.3
Communications Security.  
First
paragraph contains the following: "However, we must examine this
technology to the RTC-Web context, where the threat model is somewhat
different." 
Should
read "... Examine this technology in the RTC-Web context..."
 
Nit: Fifth paragraph: "Retrospective compromise of calling service.
      The calling service is is non-malicious
during a call but
      subsequently is compromised and wishes to
attack an older call."
Repeat of
the word "is" in the sentence.

Jim

---

From: Jim McEachern <[email-masked]>
Date: Mon, 16 Jul 2012 10:54:14 -0700 (PDT)

I have completed a thorough review of RTCWEB
Security Architecturedraft-ietf-rtcweb-security-arch-02, and have the following comments.

Section
3.1 Authenticated Entities contains the following description:
"Calling
services:  Web sites whose origin we can
verify (optimallyvia HTTPS)."
Question.
Is there any practical way to verify the origin of the web site other than via
HTTPS?  If not, then the word "optimally" could be removed.

Nit:
"...camera an microphone" => "...camera and microphone".
 
Section
4.1 The sixth paragraph has the following sentence, starting at the bottom of
page 8 and continuing onto page 9:
"In
this case, Alice has provided an identity assertion andso Bob’s browser contacts Alice’s identity provider (again, this isdone in a generic way so the browser has no
specific knowledge of the IdP) to verity the assertion."
 
This
should read ... to "verify" the assertion.
 
Section 4.4. Communications and Consent Freshness, the second paragraph reads:
"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.  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.  If a keepalive fails and no new ICE
   channels can be established, then the
session is terminated."
 
However,
draft-ietf-rtcweb-security-03, section 4.2.1 states:
"There
also needs to be some mechanism for the browser to verify that
   the target of the traffic continues to wish
to receive it.
   Obviously, some ICE-based mechanism will
work here, but it has been
   observed that because ICE keepalives are
indications, they will not
   work here, so some other mechanism is
needed."
 
So unless
I am missing something, the current text in draft-ietf-rtcweb-security-arch-02 proposes to use the
solution that  draft-ietf-rtcweb-security-03
said would not work.  Section
5.3 also states the problem with ICE keepalives is that they are one-way, (while draft-ietf-rtcweb-security-03, section 4.2.1 states that it is because they are "indications") and
that we therefore must use the consent freshness mechanism [I-D.muthu-behave-consent-freshness].
Consistent language and requirements in these various sections would be
helpful.
The following proposals may address this: 

- in draft-ietf-rtcweb-security-03, section 4.2.1 change "indications" to "one-way indications".
- in Section 4.4. Communications and Consent Freshness, the second paragraph, add a sentence between the second last sentence, and the last sentence. The end of this paragraph would then read: "Because the consentissue is more difficult here, we require
RTCWeb implementations toperiodically send keepalives.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 ICEchannels can be established, then the
session is terminated."
 
Section
5.2 Device Permissions Model, bottom of page 11, the first API requirement
states:
"API
Requirement:  The API MUST provide a
mechanism for the requesting
      JS to indicate which of these forms of
permissions it is
      requesting.  This allows the client to know what sort of
user
      interface experience to provide. "
 
Comment: I guess
it is implied by this, but it might be worth explicitly stating that one of the motivations behind the "user interface
experience"is allowing the browser to know
what permissions to ask the user for, and what permissions to enforce later.
 
5.3.  Communications Consent, bottom of page 12
says:
   "Browser client implementations of
RTCWEB MUST implement ICE.  Server
   gateway implementations which operate only
at public IP addresses may
   implement ICE-Lite...."
 
Question: What is
the intent here for server gateway implementations? Do we mean that server
gateway implementations ... may implement ICE-Lite instead of full ICE, but
MUST implement one of them? I assume that is the intent, but I think the
current wording does not technically say that. I think the current wording
could reasonably be interpreted as saying that server gateway implementations
technically don't have to implement either.
 
5.4.  IP Location Privacy
The
second API requirement might be clearer if it was split into two separate
requirements, the first dealing with the requirement to be able to force TURN-only candidates, and the second providing
an ability to reconfigure to add non-turn candidates.
 
In addition, the
explanation in the second requirement seems incomplete, as it only discusses
some of the benefits. It could be expanded, and put as a separate paragraph after the requirements.  Here is
text that you might consider for this paragraph, building on what is
already there:
Proposed expanded text: "Taken
together, these requirements allow ICE negotiation to start immediately on
incoming call notification, thus reducing post-dial delay, but also to avoid
disclosing the user’s IP address until they have
decided to answer. They also allow users to completely hide their IP address
for the duration of the call. Finally, they allow a mechanism for the user to
optimize performance by reconfiguring to allow non-turn candidates during an active call if
the user decides they no longer need to hide their IP address." 
 
The
second API requirement in section 5.5 on page 14 is a repeat of the first
requirement, and should be deleted.  Specifically:
"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
      is intended to allow for
unlinkability."
 
In
section 5.5, in the list of properties that are likely to require drill-down, at the top of page 15,
the first bullet is not listed in the format of a requirement, while the others are. It currently is:
"*
The cryptographic algorithms in use (For example:  "AES-CBC" or
         "Null Cipher".)"
This
could be changed to:
 "*  The
"security characteristics" MUST indicate the cryptographic algorithms
in use (For example:  "AES-CBC"
or "Null Cipher".)"
 
Nit:
5.6.  Web-Based Peer Authentication,
second paragraph has mis-placed brackets.
  (i.e., HTTP/HTTPS identity provider), should
be (i.e., HTTP/HTTPS) identity provider...
 
6.1.  Communications Security, end of second
paragraph, at the bottom of page 16, has the following sentence:
"Users
who wish to assure
   themselves of security against a malicious
identity provider MUST
   verify peer credentials directly, e.g., by
checking the peer’s
   fingerprint against a value delivered out of
band."
Question:
are we really putting MUST requirements on the user? Would it be more accurate
to change "MUST verify" to "can only do so by
verifying..."?

Jim

Jim