[secdir] Secdir review of draft-ohba-pana-pemk-03

Russ Mundy <mundy@sparta.com> Wed, 06 January 2010 07:15 UTC

Return-Path: <mundy@tislabs.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 126C43A680C; Tue, 5 Jan 2010 23:15:33 -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 NZ--edytJ45N; Tue, 5 Jan 2010 23:15:32 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7CED63A659A; Tue, 5 Jan 2010 23:15:31 -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 o067FSIB014053; Wed, 6 Jan 2010 01:15:28 -0600
Received: from worf.ads.sparta.com (worf.sparta.com [157.185.61.21]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o067FSom026101; Wed, 6 Jan 2010 01:15:28 -0600
Received: from calvin.home.tislabs.com ([69.250.64.147]) by worf.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 01:15:27 -0600
Received: from calvin.home.tislabs.com (localhost [127.0.0.1]) by calvin.home.tislabs.com (Postfix) with ESMTP id 21C5B17B380F; Wed, 6 Jan 2010 02:15:53 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, jari.arkko@piuha.net, yoshihiro.ohba@toshiba.co.jp, alper.yegin@yegin.org
From: Russ Mundy <mundy@sparta.com>
Date: Wed, 06 Jan 2010 02:15:53 -0500
Sender: mundy@tislabs.com
Message-Id: <20100106071553.21C5B17B380F@calvin.home.tislabs.com>
X-OriginalArrivalTime: 06 Jan 2010 07:15:28.0420 (UTC) FILETIME=[063F3E40:01CA8EA0]
Cc: mundy@sparta.com
Subject: [secdir] Secdir review of draft-ohba-pana-pemk-03
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: Wed, 06 Jan 2010 07:15:33 -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.

* There are some sections where additional information would make the
  document more clear and complete:

** Section 1. I suggest including Figure 1 from RFC5193 between the
   first and second paragraphs of this section to illustrate the
   relationship of the components being described.  (Although a
   reference to the figure might be sufficient, 5193 is Informational
   so including the diagram would avoid a potentially normative
   reference.)

** Section 2.4 defines the lifetime of the PEMK with respect to the
   MSK.  I believe this means the lifetime of the exact MSK from which
   the particular PEMK is derived.  If this is the intent, I suggest
   adding the following to the end of the current sentence: "from
   which it is derived."

** Since the PEMK does have a specified lifetime, it seems as though
   there should be some information provided about what occurs at the
   end of that lifetime.  If this information is in other related
   specifications then these should be referenced.  

** Similarly, since the PEMK is defined to be a pre-shared key,
   providing information (or reference(s)) to what protocols are
   required to put the PEMK in place would make the specification more
   clear (is the EAP security mechanism required to provide for
   this?).

* Some terminology does not seem consistent with other referenced
  specifications:

** Although the Master Session Key (MSK) provides the basis for the
   PEMK, there is no definition of MSK in this specification and the
   terminology sections of RFCs referenced in the introduction
   (RFC3748 and RFC5191) have different definitions for MSK in their
   terminology sections.

** Making Use of more terminology from RFC5191 would make it easier to
   relate this specification to related RFCs.  For instance, use of
   "PANA Session", "Session Lifetime" and "PANA Security Association
   (PANA SA)" in Sections 2.2, 2.3 & 2.4 might make the sections more
   clear.  It also appears that the Key Name of PEMK (section 2.1)
   should have some relationship to a "PANA Session" or "Session
   Identifier" but it's not clear if or what relationship is
   intended.  The specification should state the relationship (or
   absence of a relationship) or implementers will make different
   (probably incompatible) choices in their implementations.

** To make the scope more clear, I would suggest changing the first
   sentence of section 2.2 to read: "One PEMK is used between one PaC
   and one EP."

I would suggest adding a terminology section to this specification
that referenced the terminology sections of RFC3748 and RFC5191 since
they are both standards track documents.


Regards,

Russ Mundy