Skip to main content

Last Call Review of draft-ohba-pana-pemk-

Request Review of draft-ohba-pana-pemk
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-01-05
Requested 2009-12-09
Authors Alper E. Yegin , Yoshihiro Ohba
I-D last updated 2010-01-09
Completed reviews Secdir Last Call review of -?? by Russ Mundy
Assignment Reviewer Russ Mundy
State Completed Snapshot
Review review-ohba-pana-pemk-secdir-lc-mundy-2010-01-09
Completed 2010-01-09
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

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

* Some terminology does not seem consistent with other referenced

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


Russ Mundy