Last Call Review of draft-ietf-opsawg-automated-network-configuration-
review-ietf-opsawg-automated-network-configuration-secdir-lc-austein-2012-08-15-00

Request Review of draft-ietf-opsawg-automated-network-configuration
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-08-14
Requested 2012-08-01
Authors Tina Tsou, Jürgen Schönwälder, Yang Shi, Tom Taylor, GuoLiang Yang
Draft last updated 2012-08-15
Completed reviews Genart Last Call review of -?? by Vijay Gurbani
Secdir Last Call review of -?? by Rob Austein
Assignment Reviewer Rob Austein
State Completed
Review review-ietf-opsawg-automated-network-configuration-secdir-lc-austein-2012-08-15
Review result Ready with Nits
Review completed: 2012-08-15

Review
review-ietf-opsawg-automated-network-configuration-secdir-lc-austein-2012-08-15

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.