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

[Yoshihiro Ohba <[e-mail]>]

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