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

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi Vincent,

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

Best regards,

Ray

> -----Original Message-----
> From: Vincent Roca [mailto:[e-mail]]
> Sent: vrijdag 2 augustus 2013 14:32
> To: IESG; [e-mail]; [e-mail]
> 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.
> 
> --
> 
> 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.

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

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

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

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

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. 

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

Thanks. Will do.

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

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. 

> 
> 
> Cheers,
> 
> 
>    Vincent

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