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

"Brandenburg, R. (Ray) van" <> Fri, 09 August 2013 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8267621F9CAE; Thu, 8 Aug 2013 23:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.362
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w4NZJlwkHqWV; Thu, 8 Aug 2013 23:37:36 -0700 (PDT)
Received: from ( []) by (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 ([]) by with ESMTP; 09 Aug 2013 08:37:34 +0200
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 9 Aug 2013 08:37:33 +0200
From: "Brandenburg, R. (Ray) van" <>
To: Vincent Roca <>, IESG <>, "" <>, "" <>
Thread-Topic: Secdir review of draft-ietf-avtcore-idms-12
Thread-Index: AQHOj6Zfew5dacJNyUKMrFyD2GwMxZmMc9vg
Date: Fri, 9 Aug 2013 06:37:33 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, nl-NL
Content-Language: en-US
x-originating-ip: []
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,


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