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

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Feb 2018 10:51:34 +0000

Hi,

Based on Ekr¹s comments on the Security Considerations and Annex B, I have
created the following pull request:

https://github.com/ice-wg/rfc5245bis/pull/61

Regards,

Christer

On 25/02/18 11:48, "Ice on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>
>>>>   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.
>>>
>> 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.
>
>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:"
> 
>---
>
>>>>   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.
>>
>> 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
>   through the STUN short-term credential mechanism.  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:
>
>   "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."
>
>---
>
>>>>   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."
>>
>> 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."
> 
>---
>
>>>>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?
>>
>> 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."
>
>---
>
>>>> (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...
>>>
>>> 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
>
>_______________________________________________
>Ice mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ice