[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, 02 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
- [secdir] Secdir review of draft-ietf-avtcore-idms… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-avtcore-… Brandenburg, R. (Ray) van
- Re: [secdir] Secdir review of draft-ietf-avtcore-… Magnus Westerlund
- Re: [secdir] Secdir review of draft-ietf-avtcore-… Brandenburg, R. (Ray) van