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

"Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl> Fri, 09 August 2013 06:37 UTC

Return-Path: <ray.vanbrandenburg@tno.nl>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8267621F9CAE; Thu, 8 Aug 2013 23:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.362
X-Spam-Level:
X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4NZJlwkHqWV; Thu, 8 Aug 2013 23:37:36 -0700 (PDT)
Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5D21F9E9D; Thu, 8 Aug 2013 23:37:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,844,1367964000"; d="scan'208";a="12307206"
Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 09 Aug 2013 08:37:34 +0200
Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.03.0123.003; Fri, 9 Aug 2013 08:37:33 +0200
From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: Vincent Roca <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, "draft-ietf-avtcore-idms.all@tools.ietf.org" <draft-ietf-avtcore-idms.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-ietf-avtcore-idms-12
Thread-Index: AQHOj6Zfew5dacJNyUKMrFyD2GwMxZmMc9vg
Date: Fri, 9 Aug 2013 06:37:33 +0000
Message-ID: <FCC100FC8D6B034CB88CD8173B2DA1581F439A1F@EXC-MBX03.tsn.tno.nl>
References: <F7B404A0-9D49-4BC7-A284-B0F0DC984DA8@inria.fr>
In-Reply-To: <F7B404A0-9D49-4BC7-A284-B0F0DC984DA8@inria.fr>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.221.225.153]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 09 Aug 2013 04:39:00 -0700
Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-idms-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2013 06:37:41 -0000

Hi Vincent,

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

Best regards,

Ray

> -----Original Message-----
> From: Vincent Roca [mailto:vincent.roca@inria.fr]
> Sent: vrijdag 2 augustus 2013 14:32
> To: IESG; draft-ietf-avtcore-idms.all@tools.ietf.org; secdir@ietf.org
> 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