Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations)

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Feb 2018 20:06:12 +0000

Hi,

I have to admit that I am not very good at addressing Ekr's comments on the Security Considerations (and his comment on STUN pacing) in a good way, so I really need some help from others.

---

>   something incorrect about the results of the connectivity checks.
>   The possible false conclusions an attacker can try and cause are:
> IMPORTANT: This section would be a lot stronger if it was factored by attacker capabilities as well. As-is it is very hard to understand.

In some cases the attacker only needs to be able to capture the binding request, and discard it.

In other cases the attacker also needs to have access to the security credentials, in order to generate/modify messages.

Or, did you have something else in mind?

---

>   possible attack.  Fortunately, this attack is mitigated completely
>   through the STUN short-term credential mechanism.  The attacker needs
>   to inject a fake response, and in order for this response to be 
>
> This text is a bit confusing. If you can generate a drop, then you can mount this attack.

Not sure I understand.

---

>   invalid attack, this attack is mitigated by the STUN short-term
>   credential mechanism in conjunction with a secure candidate exchange.
>
> This also isn't quite correct. Consider the case where A is behind a filtering element (e.g., a firewall) and 
> shares a broadcast network with the attacker. The attacker then captures an outgoing message that would 
> have been filtered and tunnels it to B, and then tunnels the response back. This can cause B and A to think
> they have a valid path when they do not. It seems like this attack is described several paragraphs down, but 
> in sort of a confusing way.

Ok, I see what you mean.

Perhaps we should just remove the "Fortunately, this attack..." sentence?

Then, the rest of the paragraph could be separate paragraph, and modified as:

OLD:

   "The attacker needs
   to inject a fake response, and in order for this response to be
   processed, the attacker needs the password.  If the candidate
   exchange signaling is secured, the attacker will not have the
   password and its response will be discarded."

NEW:

   "Due to the STUN short-term credential mechanism, in order for the attacker 
    to inject a fake response, and in order for this response to be processed, the 
    attacker needs the password.  If the candidate exchange signaling is secured, 
    the attacker will not have the password and its response will be discarded."

---

>19.4.1.  STUN Amplification Attack
>It's probably worth noting that this form of attack is a lot worse when WebRTC is involved.

Why is that?

---
 
(Appendix B.1 - not security related)

>   rate at which they will create new bindings.  Experiments have shown
>   that once every 5 ms is well supported.  This is why Ta has a lower
>   bound of 5 ms.  Furthermore, transmission of these packets on the 
>
> Citation needed.

I don't really have any. This was the outcome of long WG discussions...

---

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Feb 2018 16:05:26 -0800

On Thu, Feb 22, 2018 at 12:06 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I have to admit that I am not very good at addressing Ekr's comments on
> the Security Considerations (and his comment on STUN pacing) in a good way,
> so I really need some help from others.
>
> ---
>
> > IMPORTANT: This section would be a lot stronger if it was factored by
> attacker capabilities as well. As-is it is very hard to understand.
>
> In other cases the attacker also needs to have access to the security
> credentials, in order to generate/modify messages.
>

It seems to me that there are (at least) the following classes of attacker

- Off-path attackers
- On-path attackers
- Attackers who control an endpoint (legitimate callers)
- Attackers who control an endpoint via WebRTC.

> > This text is a bit confusing. If you can generate a drop, then you can

If you want to simulate check failure, you only need to be able to drop
packets.

> processed, the

My point is that an on-path attacker can actually simulate success for
paths that would fail, and that the credentials don't help.

> >It's probably worth noting that this form of attack is a lot worse when

Because the attacker can force endpoints to make calls for him and can
supply any candidates he chooses

> I don't really have any. This was the outcome of long WG discussions...

Well, you can't really claim "Experiments have shown" if you can't cite
those experiemnts

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Feb 2018 09:48:57 +0000

Hi,

> - Attackers who control an endpoint via WebRTC.

What about the following modification:

OLD:

   "An attacker might attempt to disrupt the STUN connectivity checks.
   Ultimately, all of these attacks fool an ICE agent into thinking
   something incorrect about the results of the connectivity checks.
   The possible false conclusions an attacker can try and cause are:"

NEW:

   "An attacker might attempt to disrupt the STUN connectivity checks.
   Ultimately, all of these attacks fool an ICE agent into thinking
   something incorrect about the results of the connectivity checks.
   Depending on the type of attack, the attacker needs to have different
   capabilities. In some cases the attacker needs to be on the path of the
   connectivity checks. In other cases the attacker does not need to be on
   the path, as long as it is able to generate STUN connectivity checks.
   While attacks on connectivity checks are typically performed by network
   entities, if an attacker is able to control an endpoint it can might be able
   to trigger connectivity check attacks. The possible false conclusions an attacker 
   can try and cause are:"
 
---

> If you want to simulate check failure, you only need to be able to drop packets. 

Aaah... now I get it. I only had the case in mind where the attacker generates a fake response.
 
So, I suggest the following changes:

OLD:

   "To force the false invalid result, the attacker has to wait for the
   connectivity check from one of the agents to be sent.  When it is,
   the attacker needs to inject a fake response with an unrecoverable
   error response, such as a 400."

NEW:

   "To force the false invalid result, the attacker has to wait for the
   connectivity check from one of the agents to be sent.  When it is,
   the attacker needs to inject a fake response with an unrecoverable
   error response (such as a 400), or drop the response so that it never
   reaches the agent."

...and:

OLD:

   "Fortunately, this attack is mitigated completely

NEW:

   "The ability for the attacker to generate a fake response is mitigated
   through the STUN short-term credential mechanism. In order for this 
   response to be processed, the attacker needs the password.  If the candidate
   exchange signaling is secured, the attacker will not have the
   password and its response will be discarded."

---

>>   "The attacker needs to inject a fake response, and in order for this response to be
>>    processed, the attacker needs the password.  If the candidate exchange signaling is secured, 
> My point is that an on-path attacker can actually simulate success for paths that would fail, and that the credentials don't help.

What about the following:

OLD:

   "Forcing the fake valid result works in a similar way.  The agent
   needs to wait for the Binding request from each agent, and inject a
   fake success response.  The attacker won't need to worry about
   disrupting the actual response since, if the candidate is not valid,
   it presumably wouldn't be received anyway.  However, like the fake
   invalid attack, this attack is mitigated by the STUN short-term
   credential mechanism in conjunction with a secure candidate exchange."

NEW:

   "Forcing the fake valid result works in a similar way.  The agent
   needs to wait for the Binding request from each agent, and inject a
   fake success response, or route (e.g., using a tunnelling mechanism) a 
   success response that  normally would be dropped or rejected by the 
   network to the agent. Again, due to the STUN short-term credential 
   mechanism, in order for the attacker to inject a valid success response, the
   attacker needs the password."
 
---

> Because the attacker can force endpoints to make calls for him and can supply any candidates he chooses

To the following text:

   "The attacker sends an a large number of candidates, say, 50.  The
   responding agent receives the candidate information, and starts its
   checks, which are directed at the target, and consequently, never
   generate a response."

...I could append the following:

   "In the case of WebRTC the user might not even be aware that this attack is ongoing, since it might be triggered in the background by malicious 
    JavaScript code that the user has fetched."

---

>> Well, you can't really claim "Experiments have shown" if you can't cite those experiemnts

RFC 5245 had the same text, but with 20ms.

I see a couple of alternatives:

Alt #1. Modify the text and say something like:

OLD:

"Experiments have shown that once every 5 ms is well supported.  This is why Ta has a lower bound of 5 ms."

NEW:

"Discussions in the IETF ICE WG during the work on this specification concluded that, that once every 5
ms is will supported. This is why Ta has a lover bound of 5 ms." 

Does that help? It doesn't really provide a citation, but at least it gives some guidance where the number comes from.

Alt #2. Remove the text.

---

Regards,

Christer