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

From: "Glen Zorn" <[email-masked]>
Date: Fri, 17 Dec 2010 13:11:43 +0700

I think that Relative Expiration Time should be included in the hash in the
token and in the Token Verification Request message.  Even though it's of
little use to the server, including would prove that the client received the
Port Mapping Response message that the server sent (as opposed to one which
was modified in flight) and would mitigate a rather insidious MITM attack.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 17 Dec 2010 07:52:43 -0800

The man in the middle can also modify other fields. In that case, the validation will fail. Putting the relative expiration does not get us anything AFAICT.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Friday, December 17, 2010 1:12 AM
> To: [email-masked]
> Subject: [AVT] Comment on Section 5 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 18 Dec 2010 11:37:47 +0700

Ali C. Begen (abegen) [mailto:[email-masked]] writes:

> The man in the middle can also modify other fields. 

Yes.

> In that case, the validation will fail. 

But if the relative expiration time is modified, the validation will _not_
fail as the protocol is presently specified.  Suppose that a MITM is able to
consistently change the relative expiration time from, say, 3600 to 3.  As I
understand it, this modification will go unnoticed by both client and
server.  But the client is supposed to get a new token "request a new Token
well before the expiration time" (Section 4.2).  This implies that the
client (all, or nearly all clients in this case) will be requesting new
token basically constantly, something that is not prohibited by the spec.
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.

> Putting the relative expiration does not get us
> anything AFAICT.
> 
> -acbegen
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 18 Dec 2010 11:03:22 -0800

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Friday, December 17, 2010 11:38 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
> 

So, if the attacker reduces the relative exp time, the client will ask for a new token more frequently. If the original token was valid for 2 hours, but the attacker changed it to 2 mins, nothing will break but the client will ask for a new token in 2 mins instead of 2 hours.

This will naturally increase the load on the server. 

> token basically constantly, something that is not prohibited by the spec.

Correct.

> over it.  Further, AFAICT, the attack is undetectable except through traffic

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). So, I am not sure whether this is something we need to worry about. Maybe protecting the whole packet makes more sense if there is such a threat.
 
-acbegen

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 19 Dec 2010 08:55:39 +0700

Ali C. Begen (abegen) [mailto://[email-masked]] writes:

> 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.

> So, I am not sure whether
> this is something we need to worry about. Maybe protecting the whole
> packet makes more sense if there is such a threat.
> 
> -acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 19 Dec 2010 06:39:05 -0800

> Sent: Saturday, December 18, 2010 8:56 PM

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