Subject: Re: [AVT] Comment on Section 5 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 14:26:35 +0100

Hi,

I would say that adding gives you nothing, even if detected. They you
get token failure, and anyway request a new token. Thus detecting it or
not the server will anyway eat the increased load.

I don't see that one can mitigate this attack without integrity checking
the token response message

Cheers

Magnus

Ali C. Begen (abegen) skrev 2010-12-19 15:39:
> 
> 
>> -----Original Message-----
>> From: Glen Zorn [mailto:[email-masked]]
>> Sent: Saturday, December 18, 2010 8:56 PM
>> To: Ali C. Begen (abegen)
>> Cc: [email-masked]
>> Subject: RE: [AVT] Comment on Section 5 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
>>
>> Ali C. Begen (abegen) [mailto://[email-masked]] writes:
>>
>>
>>>> SHA1 isn't free, or even particularly cheap; to me, this has DoS
>>> written all
>>>> over it.  Further, AFAICT, the attack is undetectable except through
>>> traffic
>>>> monitoring.
>>>
>>> If there is a concern that this may overload the server, then, yes,
>>> getting this into the token will fix it. However, if I were the
>>> attacker, I would rather mess with the token or other fields, so that
>>> both the service would fail and the client would try getting a new token
>>> right away (even without waiting for 2 mins).
>>
>> OK, but again, the difference between that and what I'm describing is that
>> the latter is AFAICT indistinguishable (by the parties involved) from the
>> normal operation of the protocol, while the former is easily recognizable as
>> an attack.
> 
> I think there is an interesting point here, which is the following:
> 
> If an attacker messes with the relative exp time value, this can still go unnoticed very easily if the attacker "fixes" its value on the reverse path. For example, the attacker reduces the value from 2 hours to 2 mins. The client will think that the token is valid only for two minutes, and will request a new token before the 2-min deadline expires. In the meantime, if the token is used by the client, the attacker can revert 2 minutes to 2 hours in the Token Verification Request messages and make everything look perfect from server's viewpoint.
> 
> Two seconds later, the client will request a new Token. This will go unnoticed by the server no matter whether we include this field in the token or not. Here, the cost, if any, will be on the server (for extra token generations). This attack AFAIK can only be avoided if the RTCP messages are protected or maybe the server is monitored for redundant token requests from a particular client.
> 
> Oppositely, if the attacker changes the value from 2 hours to 4 hours and the client uses the token after 2 hours, this will cause a failure message from the server. But, again the server may not necessarily notice this attack as the attacker can undo its changes on the reverse path. In this case, the server will assume the client is trying to use expired tokens. Here, the cost (which is delay) is to the client not the server. I think this also requires protected RTCP messages.
> 
> So, I think we can mention this and say that if there is such a risk (MITM), monitoring activity on the server or protecting RTCP messages may help.
> 
> -acbegen
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 15 Jan 2011 11:42:36 +0700

> the token response message

That would depend upon your definition of "mitigate", I suppose.  If you
take it to mean "fully & completely foil" the attack then you are correct,
but if you take the word at its more usual meaning of "lessen or to try to
lessen the seriousness or extent of" the attack, then the attack can be
mitigated (if detected) at little cost.  Note that in my description I
didn't assume perfect behavior on the part of the attacker, just some
consistency, while Ali's reworking does assume that the attacker behaves
perfectly & is in the path for every packet; I would say that Ali's version
is not only much harder to defeat but also much more difficult to pull off.
"Perfect security or none at all" is a dangerous false dichotomy...

...