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

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Fri, 08 January 2010 07:36 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
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 DF5BF3A67D3; Thu, 7 Jan 2010 23:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 U8O2NGOnfh3j; Thu, 7 Jan 2010 23:36:23 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 5F2C13A63EB; Thu, 7 Jan 2010 23:36:23 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id o087aJiT026054; Fri, 8 Jan 2010 16:36:19 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id o087aJsK018208; Fri, 8 Jan 2010 16:36:19 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA18194; Fri, 8 Jan 2010 16:36:19 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id o087aHNF017107; Fri, 8 Jan 2010 16:36:18 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o087aErQ018097; Fri, 8 Jan 2010 16:36:16 +0900 (JST)
Received: from [133.196.17.30] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KVX00HXN3SF4150@mail.po.toshiba.co.jp>; Fri, 08 Jan 2010 16:36:15 +0900 (JST)
Date: Fri, 08 Jan 2010 16:36:13 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <20100106071553.21C5B17B380F@calvin.home.tislabs.com>
To: Russ Mundy <mundy@sparta.com>
Message-id: <4B46E06D.4070607@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
References: <20100106071553.21C5B17B380F@calvin.home.tislabs.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
X-Mailman-Approved-At: Fri, 08 Jan 2010 00:22:14 -0800
Cc: alper.yegin@yegin.org, jari.arkko@piuha.net, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Fri, 08 Jan 2010 07:36:25 -0000

Thank you for your review of the draft.  Please see my 
response below.

Russ Mundy wrote:
> 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.)

OK.

> 
> ** 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."

OK.

> 
> ** 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.  

To address this issue, we have added the following text: "At 
the end of the lifetime, the PEMK and its associated states 
MUST be deleted."

> 
> ** 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?).

We provide a guideline for distributing PEMK from PAA to EP 
in Section 3.2.  There was a fair amount of discussion in 
the PANA WG, and AFAIK it was decided not to specify a 
specific key distribution protocol in this document.

> 
> * 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.

Yes, the two documents do not use the same text for MSK 
definition, but they mean the same key and this should not 
be a problem.  We will follow your below suggestion of use 
of more terms from RFFC 5191.

> 
> ** 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.  

OK.

>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.
>

Session identifier is included in the key name as SID.  We 
added the following sentence to address your comment.

"Inclusion of the EPID, SID and KID provides uniqueness of 
PEMK names among multiple PaC-EP pairs under a given PAA."

> ** 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."

OK.

> 
> 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.
> 

Terminology section has been added.  All reused terms are 
from RFC5191 now.

Those changes are incorporated in to version 04, together 
with the changes based on Pasi and Alexey's comments.

Thank you,
Yoshihiro Ohba


> 
> Regards,
> 
> Russ Mundy
> 
> 
>