[secdir] Secdir review of draft-ietf-anima-reference-model-06

Radia Perlman <radiaperlman@gmail.com> Wed, 22 August 2018 04:29 UTC

Return-Path: <radiaperlman@gmail.com>
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 837A8130DF9; Tue, 21 Aug 2018 21:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysBuRuN7VfBc; Tue, 21 Aug 2018 21:29:48 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 A9125130DE7; Tue, 21 Aug 2018 21:29:47 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id c7-v6so448858lfe.0; Tue, 21 Aug 2018 21:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iaC6FgStpfZO0SNATmKH9p5uuM+fqeAfAc/6R5Pu4KI=; b=G+Rj7QhJpdZDpgKq2sZ/qo/ph9YxbfK96ZcyOlN4Es6FUPECg+MzS7ZXNz+4H0771i 3HpiWKrlZwwd037DldobqCv4xWVPBeAvPyF6+NjBBmmNKYUfusubeVEQF6PHjyM7k3cE cq+hscfcs8NL/jWRfGb1HHvkHDRt3VzNoRzHYKbhGGUfhIgKpnJRM8GNjb+4nIUz55EJ dN4FD+31+SVZefJ3zlr9dU9euhigdg5BLtaGzDKQ6Gs5IIJQUlB6NXEIGq96Osf5xDbF gPN4KbgcJeKFRXO6utuOXmZwQ6HMr2+TJANgxIWipc1LK7cCE/1fP8NrlZpO8DkgicZg V/GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iaC6FgStpfZO0SNATmKH9p5uuM+fqeAfAc/6R5Pu4KI=; b=UeCcs7+pYY339hZwjyy1JocGQknieYktHSl312WnuH6HgsJv7/O22tvvkEz8BHAVdC Zc7onGvh6Ar6JC+tPItac9opQGQiKHtjbD6rVnNikimoBIq5bJP1pC0hiMyyze0W5TY+ ihWA5oh3glpldgVqST2Z5wvihfAUaTWGjrhzAL228i6LSL1RqkXcXmWesVdCjgZJqQ/X 8PJmP4OrFrArahoYjv3AsEk/uv0MX7YTI7sPUB56bGNXQeaQplsrFPGiDZItNF3bo2N4 N00GPWnQA22thEBTKNZZnSudfBhJN0SB1DCdCYuvu7CDpJWwVcuRgpBHmuhj+/hzkPFD kPjQ==
X-Gm-Message-State: APzg51BVrPCWptdNM+Bf5Ap8k8YRsUxkZOT6B9O+t7R75JAA7+/cBxXt Umf8c61xdrvwtSKOGw9J76Ivd7W/T0LWXcdnBGsPA7iQ
X-Google-Smtp-Source: ANB0VdbrnaGXt4wCdti0x2gc5dxrZXs7QG5C3z66ICO6A60wdwHst+pIfZvcCPRkrTQzEBraVTSy3vvXpafqCXzPpbI=
X-Received: by 2002:a19:730d:: with SMTP id o13-v6mr3178597lfc.130.1534912185832; Tue, 21 Aug 2018 21:29:45 -0700 (PDT)
MIME-Version: 1.0
From: Radia Perlman <radiaperlman@gmail.com>
Date: Tue, 21 Aug 2018 21:29:34 -0700
Message-ID: <CAFOuuo4bFw8r2j2UiWwc1GdtwT865q_MnuouD4BtJQCevs+f4w@mail.gmail.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-anima-reference-model.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="000000000000991a600573fe9785"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8iynHg0xwspOrcsI7hdhuOqdLU4>
Subject: [secdir] Secdir review of draft-ietf-anima-reference-model-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
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, 22 Aug 2018 04:29:50 -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.

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.



This document is an overview document (intended as informational)
introducing a large collection of I-Ds (intended as Proposed) describing
autonomic networking. Aimed at the Internet of Things with devices with
very little in the way of user interface other than over the network, the
design goal is to be maximally auto-configuring. Security is bootstrapped
using private keys and certificates installed by the manufacturer, where to
first goal is to join new devices to some sort of domain.



The most suspicious thing from a security standpoint is that it appears all
of the devices in a domain implicitly trust one another. This means that
bringing in the proverbial light bulb into your house could compromise your
whole house if the light bulb had a Trojan horse installed or some sort of
bug that allowed it to be compromised. There is some mention of addressing
this issue in the future, but unless I’m misunderstanding the approach this
seems like a very dangerous thing to deploy even initially. It makes much
more sense for each installed device to first become manageable by a single
other device in the domain. That first management device could cautiously
expand trust further.



The dangers are well summarized in Section 9 (Security Considerations).
Section 9.2 includes this text:



The above threats are in principle comparable to other solutions: In

the presence of design, implementation or operational errors,

security is no longer guaranteed. However, the distributed nature of

AN, specifically the Autonomic Control Plane, increases the threat

surface significantly. For example, a compromised device may have

full IP reachability to all other devices inside the ACP, and can use

all AN methods and protocols.



For the next phase of the ANIMA work it is therefore recommended to

introduce a sub-domain security model, to reduce the attack surface

and not expose a full domain to a potential intruder. Furthermore,

additional security mechanisms on the ASA level should be considered

for high-risk autonomic functions.