Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)
draft-ietf-hokey-emsk-hierarchy-07

[Ballot discuss]
Update: To resolve Pasi's Discuss and to reconciliate eap-keying and
this document, this document should say "Updates: eap-keying" in the
header. Note that eap-keying has just been approved.

First: I am in favor of creating this hieararchy of keys, and I believe
it will find other (acceptable) uses beyond HOKEY. I do not believe
the mere creation of the hieararchy will lead to the kind of issues
discussed during the IETF Last Call.

My issues:

1. The document says:

  o  The initial authenticated key exchange MAY specify a favored KDF.
      For example an EAP method may define a preferred KDF to use in its
      specification.  If the initial authenticated key exchange
      specifies a KDF then this MUST override the default KDF.
  o  A system MAY specify a separate default KDF if all participants
      within the system have the knowledge of which KDF to use.  If
      specified this MUST take precedence over key exchange defined KDF.

  I find the former approach OK, but the latter one would lead to
  severe interoperability issues, without an indicated way to
  negotiate this between the participants. You cannot assume all
  nodes in your network support OS version 1.2.3 from manufacturer
  X.

2. The document says:

  The system MAY use the MSK transmitted to the NAS in any way it
  chooses.  This is required for backward compatibility.  New usage
  definitions following this specification MUST NOT use the MSK.  If
  more than one usage uses the MSK, then the cryptographic separation
  is not achieved.  Implementations MUST prevent such combinations.

  I agree with the above, but it also seems to be making a statement
  about the free use of the MSK. I do not believe it is correct for
  this document to make that statement (rather, it should be RFC 3748
  or eap-keying or even link layer specifications).

  Please change this to "The system MAY use the MSK transmitted to the
  NAS in any way it chooses in accordance with [RFC 3748, eap-keying]
  and other relevant specifications.

3. The document defines "label-string@specorg" labels and associated
  key derivations for any organization.

  I do not believe this is wise. I would much rather see a limited
  number of experimental labels created, and have RFC Required IANA
  rule for any other usage. Otherwise, I do believe we will see these
  keys misused for applications that should not depend on EAP.

4. I do not believe the applicability note reflects the concerns
  raised in the IETF Last Call discussion. It needs expansion.
  I may volunteer to produce text for this if you think it would
  be useful (but not this week).

[Ballot discuss]
This document depends on EAP features that are not
specified in RFC 3748, but only in draft-ietf-eap-keying.
This needs to be a normative reference.

[Ballot discuss]
This draft defines a capability which seems potentially very useful for routing protocols, and for signaling protocols used between routers.

However, in order for a security mechanism to be useful for routing and for signaling protocols used between routers, there are (at least in general) two issues that need to be handled: One is how to bootstrap operation in the case that Routing has not come up yet, the other is how to operate the protocol between multiple routers that are directly connected over some form of multicast or point to multipoint service.

I think that the first of these issues is already covered by the introduction to RFC3748, which states: "EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP". Thus bootstrapping is not an issue in this case (at least not for router operation).

However, I didn't see in either draft-ietf-hokey-emsk-hierarchy nor in RFC3748 description of how the protocol would work between multiple systems directly connected via a multicast service. As an example, both OSPF and IS-IS when operating over a broadcast LAN allow one router to transmit a single packet which is received by multiple routers.

To me it appears that fixing this limitation is something that would require a significant amount of work. It also appears to me that draft-ietf-hokey-emsk-hierarchy is potentially very useful in some environments where operation between multiple systems over a multicast service is not needed. To me is therefore seems more reasonable to simply call attention to this limitation, rather than hold up the document waiting for this to be corrected. I would therefore suggest the following text (or something similar) be added, which I expect would be a new section prior to the existing IANA considerations section:

  x. Routing Considerations

  Many or most routing protocols, as well as signaling protocols that
  operate between routers, make use of underlying multicast services
  (such that one protocol packet will be transmitted by a single router
  but received by multiple routers, using an underlying multicast or
  point to multipoint service).

  As such, the protocol described in this document, as currently
  defined, is not in general applicable to routing and signaling
  protocols.

[Ballot discuss]
First: I am in favor of creating this hieararchy of keys, and I believe
it will find other (acceptable) uses beyond HOKEY. I do not believe
the mere creation of the hieararchy will lead to the kind of issues
discussed during the IETF Last Call.

My issues:

1. The document says:

  o  The initial authenticated key exchange MAY specify a favored KDF.
      For example an EAP method may define a preferred KDF to use in its
      specification.  If the initial authenticated key exchange
      specifies a KDF then this MUST override the default KDF.
  o  A system MAY specify a separate default KDF if all participants
      within the system have the knowledge of which KDF to use.  If
      specified this MUST take precedence over key exchange defined KDF.

  I find the former approach OK, but the latter one would lead to
  severe interoperability issues, without an indicated way to
  negotiate this between the participants. You cannot assume all
  nodes in your network support OS version 1.2.3 from manufacturer
  X.

2. The document says:

  The system MAY use the MSK transmitted to the NAS in any way it
  chooses.  This is required for backward compatibility.  New usage
  definitions following this specification MUST NOT use the MSK.  If
  more than one usage uses the MSK, then the cryptographic separation
  is not achieved.  Implementations MUST prevent such combinations.

  I agree with the above, but it also seems to be making a statement
  about the free use of the MSK. I do not believe it is correct for
  this document to make that statement (rather, it should be RFC 3748
  or eap-keying or even link layer specifications).

  Please change this to "The system MAY use the MSK transmitted to the
  NAS in any way it chooses in accordance with [RFC 3748, eap-keying]
  and other relevant specifications.

3. The document defines "label-string@specorg" labels and associated
  key derivations for any organization.

  I do not believe this is wise. I would much rather see a limited
  number of experimental labels created, and have RFC Required IANA
  rule for any other usage. Otherwise, I do believe we will see these
  keys misused for applications that should not depend on EAP.

4. I do not believe the applicability note reflects the concerns
  raised in the IETF Last Call discussion. It needs expansion.
  I may volunteer to produce text for this if you think it would
  be useful (but not this week).

IANA Last Call comments:

ACTION 1:

Upon approval of this document, the IANA will create the registry
"USRK key labels" at
http://www.iana.org/assignments/TBD

Registry Name: Usage Specific Root Keys (USRK) key labels
Reference: [RFC-ietf-hokey-emsk-hierarchy-04.txt]
Range Registration Procedures
----------------------------------- -----------------------
label-string IETF Consensus
label-string@ietf.org IETF Consensus
label-string@specorg (not ietf.org) Specification Required

Label Description Reference
------------- ---------------------------------- ---------
EMSK Extended Master Session Key (EMSK)
[RFC-ietf-hokey-emsk-hierarchy-04.txt]
dsrk@ietf.org Domain Specific Root Key (DSRK)
[RFC-ietf-hokey-emsk-hierarchy-04.txt]

QUESTION: Should we break this registry up into two separate
registries, label-string and label-string@specorg?


ACTION 2:

Upon approval of this document, the IANA will create the registry
"EMSK PRF numbers" at
http://www.iana.org/assignments/TBD

Registry Name: EMSK PRF numbers
Reference: [RFC-ietf-hokey-emsk-hierarchy-04.txt]
Registration Procedures: IETF Consensus

Value Description Reference
------- ----------------------------- ---------
0 Reserved [RFC-hokey-emsk-hierarchy-04]
1 HMAC-SHA-256 PRF+ (Default) [RFC-hokey-emsk-hierarchy-04]
2-220 Unassigned [RFC-hokey-emsk-hierarchy-04]
221-255 Reserved for Private Use [RFC-hokey-emsk-hierarchy-04]

Document Shepherd write-up for:

  Specification for the Derivation of Root Keys from an Extended Master
  Session Key (EMSK)

  http://tools.ietf.org/html/draft-ietf-hokey-emsk-hierarchy

(1.a)  Who is the Document Shepherd for this document?  Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?

  Charles Clancy is the document shepherd for this document and has
  personally reviewed the document and believes that it is ready to be
  forwarded to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members and
from key non-WG members?  Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

  They document has received adequate review from the working group
  during WGLC.  The Document Shepherd has no concerns with respect to
  the depth or breadth of the reviews that have been performed.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization
or XML?

  No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document been
filed? If so, please include a reference to the disclosure and summarize
the WG discussion and conclusion on this issue.

  The Document Shepherd is unaware of any specific concerns or issues
  with the document.  No IPR disclosures related to
  draft-ietf-hokey-emsk-hierarchy have been submitted.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  The document represents a reasonably strong consensus with the active
  members of the working group in favor of the document moving forward. 
  Significant discussion was involved to converge on the keying
  hierarchy described in this document.  Since being submitted as a WG
  document, 3 formal issues were posted to the tracker and resolved.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

  No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/).

  Yes.

  There are two nits, but both are unavoidable:
    - Normative reference to NIST standard for SHA-256; no RFC available
      to reference instead
    - Informative reference to obsolete RFC 822, but this is for
      historical/comparative purposes

Boilerplate checks are not enough; this check needs to be thorough. Has
the document met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

  Yes.

(1.h) Has the document split its references into normative and
informative?

  Yes.

Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

  No.

If such normative references exist, what is the strategy for their
completion?

  N/A

Are there normative references that are downward references, as
described in [RFC3967]?

  According to id-nits, normative reference to the NIST SHA-256
  standards is a possible downref, but this is currently unavoidable.

If so, list these downward references to support the Area Director in
the Last Call procedure for them [RFC3967].

  The document has split references with no downward or dependent
  references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed Expert
during the IESG Evaluation?

  The IANA Considerations section requests creation of new IANA
  registries for EMSK key labels and PRF types.  The EMSK key labels
  are allocated based on IETF CONSENSUS (per RFC 2434), and are
  fully described in the IANA Considerations section.  The same is
  true for the PRF numbers.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

  Not applicable.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  An Extended Master Session Key (EMSK) is a cryptographic key
  generated from an Extensible Authentication Protocol (EAP) exchange
  reserved solely for the purpose of deriving master keys for one or
  more purposes identified as usage definitions.  This memo specifies a
  mechanism for avoiding conflicts between root keys by deriving
  cryptographically separate keys from the EMSK.  This document also
  describes a usage for domain specific root keys made available to and
  used within specific key management domains.

Working Group Summary

  The document represents rough consensus of the working group.

Document Quality

  This document has been reviewed extensively and the Document Shepherd
  believes it to be of high quality.

Personnel

  Charles Clancy is the document shepherd.  The responsible Area
  Director is Tim Polk.