Subject: [secdir] Secdir review of draft-ietf-avtcore-idms-12

From: Vincent Roca <[email-masked]>
Date: Fri, 2 Aug 2013 14:32:06 +0200

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

--

One minor comment first: It is said that
   "Differences in playout time exceeding configured limits (e.g. more than
    ten seconds) could be an indication of such inconsistent information."
But it could as well be caused by a misbehaving receiver (e.g. with an
intermittent connection) who should better be removed from the destination
set altogether. So I wouldn't speak of "inconsistent information", but rather
"out of bound information" since this situation is "consistent" with the real
situation.

Then, using "configured limits" is necessary, sure, but not sufficient. What if
an attacker periodically reports values that are just below this configured
limit? They should be accepted whereas they will negatively impact the session.
And you cannot reduce indefinitely the configured limits.

A third comment. The document only mentions devices (in the example)
that report erroneous information. The problem is broader than that. The
attacker may also be on the route between a legitimate destination to the
source, and be able to alter the report message. Or the attacker may be 
able to forge a packet with erroneous information, masquerading as a
legitimate receiver. So it would be great to broaden the problem statement
with that in mind.

And then it quickly leads to the idea of message integrity verification (to
combat packet modification) and source authentication (to combat
masquerading). You should say something on it.

Of course, the same comments apply for the messages sent on the other
direction, from source to destinations.

A reference to SRTP is missing. Please add.

Finally, since everything depends on precise time synchronization, it should
be highlighted that having a secure time synchronization service is absolutely
required. Otherwise this is another potential means to attack the session.

Cheers,

   Vincent

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 9 Aug 2013 06:37:33 +0000

Hi Vincent,

Thanks for your very thorough review. You will find my comments inline.

Best regards,

Ray

> -----Original Message-----
> From: Vincent Roca [mailto:[email-masked]]
> Sent: vrijdag 2 augustus 2013 14:32
> To: IESG; [email-masked]; [email-masked]
> Cc: Vincent Roca
> Subject: Secdir review of draft-ietf-avtcore-idms-12
> 
> Hello,
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> --
> 
> intermittent connection) who should better be removed from the
> destination set altogether. So I wouldn't speak of "inconsistent information",
> but rather "out of bound information" since this situation is "consistent" with
> the real situation.

Good point. I will change it to 'out of bound'.

> And you cannot reduce indefinitely the configured limits.

As indicated in the text, it's not just the SCs which checks for 'out-of-bound' info. It's the MSAS as well. If the MSAS includes a configured limit of let's say 10 seconds, it can use this as a threshold. Once any receiver is more than 10 seconds delayed from the rest, the MSAS could ignore that receivers reports when deriving the target playout time. 

> 
> A third comment. The document only mentions devices (in the example) that
> report erroneous information. The problem is broader than that. The
> source, and be able to alter the report message. Or the attacker may be able
> to forge a packet with erroneous information, masquerading as a legitimate
> receiver. So it would be great to broaden the problem statement with that in
> mind.
 
While you're absolutely right, I'm not sure we need to try and solve that problem here. Once there is a man-in-the-middle who is able to include falsified RTCP packets in the stream, there are a lot worse things it could accomplish than messing up the IDMS. I think in such cases, one should just use SRTP/SRTCP. 

> masquerading). You should say something on it.

See my earlier point. Although message integrity and source authentication is potentially an issue, I don't think we need to solve it here. That said, I think you're right that it would be good to mention these issues when mentioning SRTP. 

> A reference to SRTP is missing. Please add.> 

Thanks. Will do.

> required. Otherwise this is another potential means to attack the session.

Good point, we didn't think of that. I will add a note to the security considerations mentioning that the same security vulnerabilities apply to the clock sync part as well. 

>    Vincent

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Aug 2013 14:03:27 +0200

Vincent and Ray,

>> A reference to SRTP is missing. Please add.> 

I think referencing SRTP here is to narrow. I think the appropriate
thing to point out is the need for source authentication and message
integrity and then point to the need for a security solution that
provide this. SRTP is a transport security solution, without
key-management. So pointing at this to resolve this issue is
insufficient and also not deployable. I think a better reference now
that it exist and is getting closer to publication might be:

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options/

Cheers

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: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 14 Aug 2013 08:59:32 +0000

Hi Magnus,

Thanks for the heads-up. I think the document you mentioned is exactly what we're looking for. 

I will include a reference in the next iteration, which I will post after the 2nd WGLC has concluded. 

Ray