[secdir] secdir review of draft-ietf-opsawg-automated-network-configuration-04

Rob Austein <sra@hactrn.net> Wed, 15 August 2012 16:43 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 958F621E80F2; Wed, 15 Aug 2012 09:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jdYRmkTRvPAC; Wed, 15 Aug 2012 09:43:08 -0700 (PDT)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id C3B1E21E80EE; Wed, 15 Aug 2012 09:43:07 -0700 (PDT)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 817189B447; Wed, 15 Aug 2012 16:43:04 +0000 (UTC)
Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5762A171B6; Wed, 15 Aug 2012 12:43:04 -0400 (EDT)
Date: Wed, 15 Aug 2012 12:43:04 -0400
From: Rob Austein <sra@hactrn.net>
To: draft-ietf-opsawg-automated-network-configuration.all@tools.ietf.org
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20120815164304.5762A171B6@thrintun.hactrn.net>
Cc: Internet Engineering Steering Group <iesg@ietf.org>, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-opsawg-automated-network-configuration-04
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: Wed, 15 Aug 2012 16:43:08 -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 draft is a problem statement, targeted for Informational status,
discussing issues surrounding automated techniques for configuration
(initial and ongoing) of large numbers of devices, both within a
single organization and when crossing organizational boundaries.  The
draft goes into some detail about security issues involved in such
configuration, and emphasizes the difficulty and importance of getting
this stuff right.  The Security Considerations section seems adequate,
and the authors deserve credit for resisting the temptation of just
sprinkling IPsec pixie dust all over a fairly hard problem space.

I have no serious security concerns with this document.

Minor notes, in case for whatever reason the authors need to make
other changes:

- The discussion of DNS-based mechanisms for finding the configuration
  server probably should mention DNSSEC, at least in passing.  At
  least in theory, if done properly, DNSSEC would allow the device a
  reasonable level of confidence that it has at least obtained the
  correct IP address for the configuration server.  This does not, of
  course, remove the need for mutual authentication when establishing
  the secure channel, so the lack of mention of DNSSEC in the current
  text is not a critical omission.

- The discussion of UUIDs and shared secrets is a bit confusing.
  While I agree with the basic premise (that the combination of UUIDs
  and shared secrets may be usable in certain cases but has serious
  scaling issues), the discussion does not really cover the inherent
  weakness of authentication using such techniques.  If one twists
  one's head into the right shape, this is indeed a scaling problem of
  sorts ("Three can keep a secret, if two of them are dead"), but it
  would be better to be explicit about the weakness of authentication
  when all you have are UUIDs and a shared secret.