[secdir] Review of draft-ietf-emu-eaptunnel-req-08

Russ Mundy <mundy@sparta.com> Thu, 02 December 2010 00:26 UTC

Return-Path: <mundy@sparta.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA413A6830; Wed, 1 Dec 2010 16:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpPT8JyhBKrx; Wed, 1 Dec 2010 16:26:52 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B60723A6812; Wed, 1 Dec 2010 16:26:51 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id oB20S38W014701; Wed, 1 Dec 2010 18:28:03 -0600
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id oB20S37u006880; Wed, 1 Dec 2010 18:28:03 -0600
Received: from socks1.tislabs.com ([192.94.214.32]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Dec 2010 19:28:03 -0500
From: Russ Mundy <mundy@sparta.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Wed, 01 Dec 2010 19:28:02 -0500
Message-Id: <74C2196A-9DEA-40FF-860B-BDD47857F1CE@sparta.com>
To: secdir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-OriginalArrivalTime: 02 Dec 2010 00:28:03.0275 (UTC) FILETIME=[C81FA1B0:01CB91B7]
Cc: draft-ietf-emu-eaptunnel-req.all@tools.ietf.org, iesg@ietf.org, Russ Mundy <mundy@sparta.com>
Subject: [secdir] Review of draft-ietf-emu-eaptunnel-req-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 02 Dec 2010 00:26:55 -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.

I need to start my comments by saying that I do not have a background
in the details EAP, tunnels and TLS so I approached the document
review as someone who was a potential designer of a solution that the
document might provide.  The broad problem that I encountered with the
document is that it is unclear how it relates to other EAP, TLS and
other tunnel specifications.  Since there are essentially no
illustrations or text describing the various parts and how they are
related nor was I able to locate any other document providing
architectural descriptions, my conclusion is that the document seems
to be for people that already are very familiar with other
specifications/documents related to the multiple technology pieces
described in the document.  In short, there is not sufficient
architectural context for the document to be widely useful.

- Publication of the current document (without the architectural
  context) might provide some value to the Internet community
  but I would recommend that the IESG sees that more architectural
  context gets put in some document in the near future. Without such
  architectural direction, documents such as this one will not be used
  as expected either because they won't be found or won't be understood.


A couple of more specific comments:

- In section 2., the redifinition of MUST, MUST NOT, SHOULD, SHOULD
  NOT, and MAY for _this_ document does not seem appropriate.  The
  document should use the standard definitions for these terms or find
  different words for the definitions (conventions).

- Section 4.4 has a normative reference to an I-D which expired in May
  of 2009.  This needs to be corrected prior to publications.


Russ Mundy