[secdir] Review of draft-ietf-clue-framework-24

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 02 December 2015 16:35 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E77591B2BB2; Wed, 2 Dec 2015 08:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VPLTs5AYqs6j; Wed, 2 Dec 2015 08:34:59 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA021B2BA5; Wed, 2 Dec 2015 08:34:55 -0800 (PST)
Received: by lfdl133 with SMTP id l133so57690147lfd.2; Wed, 02 Dec 2015 08:34:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=V+Xst/BWT5kpFHp3Lb5RPZhW2tG1qDBFTiYoi8D8ZuE=; b=vtqXihUCNb0td2CcaY7nlbkBEeZuck3Kdpm3ijbYhNAAaU9CDxL1D32df/EpKsZVZI nanNKngOoBf4OvzfxZUV3uxiZIxzK/NC4+8AqJujC8dZHKWhPtjuBa9hneuvxSCMhDvS J+KxyJIgcxmckjeOkbYtzX94evHUm9rzo74zR5Zps1QCLwMvtdL0PXFAzjd6325mHo2c VW2Q7pgmRUD2rVqKP3ybG6KwDO5lU8Uf4/aX/GAzf+m8KbvsRZrWYraJ8B78h5f6TJl0 AmQmRvvcDXcWbbXGdk2Z8JilSvjRlwJ7d61eUI97VdLggQpoGB+9u/RPeedAdon3oYxa sq8Q==
MIME-Version: 1.0
X-Received: by with SMTP id er13mr3460675lbc.133.1449074094103; Wed, 02 Dec 2015 08:34:54 -0800 (PST)
Sender: hallam@gmail.com
Received: by with HTTP; Wed, 2 Dec 2015 08:34:53 -0800 (PST)
Date: Wed, 2 Dec 2015 11:34:53 -0500
X-Google-Sender-Auth: YIRYIA5wuBpb3UolCoBadKlzHg8
Message-ID: <CAMm+Lwiq-MNf4NWKn7OBS+xg5PWnLXLRMP_tqxsbGEsYV+bzrA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: draft-ietf-clue-framework.all@ietf.org, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: multipart/alternative; boundary=001a1133f450a1e24e0525ecda98
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/b7wLPeRSS3er1gKRrqyDzVMY8BQ>
Subject: [secdir] Review of draft-ietf-clue-framework-24
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 02 Dec 2015 16:35:02 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This standards track document describes what is essentially an enhanced
data model for negotiating telepresence configurations in cases where a
given party may have multiple capture devices offering multiple streams.
Choice of streams may be constrained by device capabilities. A camera may
offer a closeup of the speaker or a wide view of the panel but not be
capable of providing both.

Security considerations.

One context issue I am having here is understanding what the relation of
this document is to the others it is referencing. For example, there is a
normative reference to draft-ietf-clue-protocol-06
<https://tools.ietf.org/html/draft-ietf-clue-protocol-06>. Is that to be
considered by the IESG at this point? If so it does not have a security

If the point is to publish the framework doc as an RFC so as to set the
context for further discussions of the protocol, this is OK. But otherwise
there is a normative reference to a document that doesn't have a security
considerations section and desperately needs one.

This is a big problem as the Security Considerations section in framework
is pointing forward to 'authorization mechanisms' that are presumably to be
described in protocol.

Given this situation, these comments may be taken as input to the framework
doc or the documents to be written using framework as the architecture.

As a general matter, it would be easier to analyze security if terms such
as 'confidentiality' and 'integrity' were used. This is particular the case
when the specification in question is dealing with audio and video. for
example the phrase "an endpoint attempting to listen to sessions in which it
is not authorized to participate" is almost certainly intended to cover
video as well which is seen and not heard.

Looking at the considerations in this way gives us the following

   Disclosure of media streams to an unauthorized endpoint.
   Disclosure of metadata to capture devices.
   Failure to terminate access to media streams at completion of a session.

   Modification of media stream data
   Introduction of spurious media streams.

   Denial of Service against capture devices
   Denial of service against output devices

I think this approach would be helpful when it comes to writing the
protocol authorization sections.

As a general rule, the term 'endpoint' is now meaningless and should not be
used. Yes, end-to-end security is a good thing. But you show me which are
the 'endpoints' here.

End to end is Alice's brain to Bob's brain.

Between that we have mouth/face -> cameras/ mics -> capture host(s) ->
inter-network -> output host(s) -> displays/speakers -> eyes/ears.

An attacker may target any of those modules and any of the interfaces
between them. Using the term 'endpoint' is ambiguous.

The metadata disclosure problem can be quite insidious. Let us say we are
using CLUE to collect media streams from a home security grid. I have 11
cameras on the perimeter pointing in and another 7 on the residence
pointing out and one on my desk. The one on my desk can be considered to be
trustworthy, if someone has compromised that, I am screwed. But that isn't
the case for the perimeter net which is cobbled together from Raspberry Pis
and cheapo cameras. That net is placed in a location I know is vulnerable.

Lets say we have an intrusion. First thing I do is to fire up a conference
call with my security contractor. I don't want someone to be able to
compromise one of my perimeter cameras in a way that tips them off to the
fact the intrusion has been detected.

Introduction of spurious streams might be one of the best ways to attack a
conferencing system. If I can see the main speaker and the audio is a
little fuzzy, attacker introduces an additional stream with filtering that
makes it more attractive to whatever AI is managing the conference. Now the
attacker can literally put words in people's mouths. Could be fun for
politicians giving town halls.