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

Vincent Roca <vincent.roca@inria.fr> Fri, 02 August 2013 17:32 UTC

Return-Path: <vincent.roca@inria.fr>
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 75B8D11E80EE; Fri, 2 Aug 2013 10:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.205
X-Spam-Level:
X-Spam-Status: No, score=-110.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Hh4syBkg8yZL; Fri, 2 Aug 2013 10:32:39 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CE11E80E8; Fri, 2 Aug 2013 10:32:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,802,1367964000"; d="scan'208";a="28326851"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.147]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 02 Aug 2013 19:32:36 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 2 Aug 2013 14:32:06 +0200
Message-Id: <F7B404A0-9D49-4BC7-A284-B0F0DC984DA8@inria.fr>
To: IESG <iesg@ietf.org>, draft-ietf-avtcore-idms.all@tools.ietf.org, secdir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Subject: [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, 02 Aug 2013 17:32:44 -0000

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