Extensible Authentication Protocol (EAP) Key Management Framework
draft-ietf-eap-keying-22

[Ballot discuss]
>The backend authentication server is trusted
>to refrain from deriving these same keys or acting as a man-in-the-
>middle even though it has access to the EAP keying material that is
>needed to do so. 

Don't several fast handoff schemes depend on the backend
authentication server or some other party handing out such keys to
appropriate parties?  If so, this needs to be reworded.

IN section 2 and really in most of the document I think it would be
much more clear what is going on if the document made it clear that
while EAP keying material cannot be exported, keys derived from EAP
keying material may be exported within appropriate key scopes.




>An EAP authenticator MUST NOT share any keying material with
>another EAP authenticator, since if one EAP authenticator were
>compromised, this would enable the compromise of keying material on
>another authenticator. 

This text needs to be fixed to allow 802.11r style key hierarchies.
Previous text gets this correct.

[Ballot discuss]
In addition to the following points I'm holding a discuss until
draft-housley-aaa-key-mgmt is approved: changes ind that draft are
very likely to affect this draft.  I expect that approval before
Prague.


>The backend authentication server is trusted
>to refrain from deriving these same keys or acting as a man-in-the-
>middle even though it has access to the EAP keying material that is
>needed to do so. 

Don't several fast handoff schemes depend on the backend
authentication server or some other party handing out such keys to
appropriate parties?  If so, this needs to be reworded.

IN section 2 and really in most of the document I think it would be
much more clear what is going on if the document made it clear that
while EAP keying material cannot be exported, keys derived from EAP
keying material may be exported within appropriate key scopes.



In section 2.2:
>Where the backend server FQDN differs from the subjectAltName in the
>certificate, the AAA client may not be able to successfully determine
>whether it is talking to the correct backend authentication server.

Why does the AAA client even examine the certificate used within the
EAP method?


>An EAP authenticator MUST NOT share any keying material with
>another EAP authenticator, since if one EAP authenticator were
>compromised, this would enable the compromise of keying material on
>another authenticator. 

This text needs to be fixed to allow 802.11r style key hierarchies.
Previous text gets this correct.


From a security directorate review by David Harrington:

>The single largest issue I have with this document is its use of
>RFC2119 keywords, especially in lowercase. It is very difficult to
>tell which specifications are required for interoperability, which
>because the authors want to see a particular way of doing things, and
>which are simply not requirements at all, but RFC2119 language is used
>anyway. This point really needs work!

I would also appreciate a response to the rest of David's points as last call comments.

[Ballot discuss]
In Section 3.1, Secure Association Protocol entry (e)
The two paragraphs are in conflict.  Paragraph 1 states that if the TSKs are "derived from a portion of the exported EAP keying material [this could] expose the underlying ciphersuite to attack."  Paragraph 2 describes how nonces or counters are "mixed with the exported keying material in order to generate fresh ... session keys."

This conflict needs to be resolved.

Section 2.1 "AAA"
Other entries in this section refer to requirements in specifications, but this entry begins with "Existing implementations ..."  Please clarify whether this reflects the details of the RADIUS/EAP and Diameter EAP specifications as well.

Editorial:

Section 1.2

Consider adding a definition for "Handoff".  This term first appears in the title for section 4 and is never defined in the document.

Section 1.4, paragraphs two and three open with the exact same sentence, and the second sentence is almost the same.  Please review and delete the redundant text.

Section 1.6 begins "Certain basic characteristics, known as "EAP Invariants", hold true for EAP implementations on all media:"

Given that "media independence" is the second member of the list, perhaps "on all media" is unecessary in the opening clause?  Consider deleting "on all media".

[Ballot discuss]
In Section 3.1, Secure Association Protocol entry (e)
The two paragraphs are in conflict.  Paragraph 1 states that if the TSKs are "derived from a portion of the exported EAP keying material [this could] expose the underlying ciphersuite to attack."  Paragraph 2 describes how nonces or counters are "mixed with the exported keying material in order to generate fresh ... session keys."

This conflict needs to be resolved.

Section 2.1 "AAA"
Other entries in this section refer to requirements in specifications, but this entry begins with "Existing implementations ..."  Please clarify whether this reflects the details of the RADIUS/EAP and Diameter EAP specifications as well.

Editorial:

Section 1.2

Consider adding a definition for "Handoff".  This term first appears in the title for section 4 and is never defined in the document.

Section 1.4, paragraphs two and three open with the exact same sentence, and the second sentence is almost the same.  Please review and delete the redundant text.

Section 1.6 begins "Certain basic characteristics, known as "EAP Invariants", hold true for EAP implementations on all media:"

Given that "media independence" is the second member of the list, perhaps "on all media" is unecessary in the opening clause?  Consider deleting "on all media".

[Ballot discuss]
In addition to the following points I'm holding a discuss until
draft-housley-aaa-key-mgmt is approved: changes ind that draft are
very likely to affect this draft.  I expect that approval before
Prague.


>The backend authentication server is trusted
>to refrain from deriving these same keys or acting as a man-in-the-
>middle even though it has access to the EAP keying material that is
>needed to do so. 

Don't several fast handoff schemes depend on the backend
authentication server or some other party handing out such keys to
appropriate parties?  If so, this needs to be reworded.

IN section 2 and really in most of the document I think it would be
much more clear what is going on if the document made it clear that
while EAP keying material cannot be exported, keys derived from EAP
keying material may be exported within appropriate key scopes.


I don't understand how the backend authentication server authorizes
the peer's lower layer identity in section 2.2.1.

In section 2.2:
>Where the backend server FQDN differs from the subjectAltName in the
>certificate, the AAA client may not be able to successfully determine
>whether it is talking to the correct backend authentication server.

Why does the AAA client even examine the certificate used within the
EAP method?


>An EAP authenticator MUST NOT share any keying material with
>another EAP authenticator, since if one EAP authenticator were
>compromised, this would enable the compromise of keying material on
>another authenticator. 

This text needs to be fixed to allow 802.11r style key hierarchies.
Previous text gets this correct.

PROTO Write-up

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

Document Shepherd: Bernard Aboba
I have personally reviewed the document.

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

Yes. This document has been through two WG last calls.

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

The document has been reviewed by the EAP WG, as well as by participants
in other SDOs such as IEEE 802.11. However, the topic is complex, so that
review by the Security Directorate during IETF last call would be appropriate.

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

No concerns.

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

There is solid consensus behind this document. At various points,
more than 18 people have posted review comments relating to the document.

The issues raised and the resolutions are available for inspection at
http://www.drizzle.com/~aboba/EAP/.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise 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/). 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. An output of the run on this revision of the ID by the online nits
checker:

idnits 2.00.3

(The RFC status file is not from today - attempting to download a newer one...
- Success fetching RFC status file.)

tmp/draft-ietf-eap-keying-18.txt:

Checking nits according to http://www.ietf.org/ID-Checklist.html:
No ID-Checklist nits found.

Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
* Missing expiration date. The document expiration date should appear on
the first and last page.

Miscellaneous warnings:
None.

Experimental warnings:
(Checking references for intended status: Proposed Standard)

- Obsolete Reference: RFC 2409

Summary: 1 nit, 1 warning

(1.h) Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state? If such normative references exist, what
is the strategy for their completion? Are there normative references that are
downward references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure for them [RFC3967].

The document splits normative and informative references.
There are no normative references to IDs.

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

This document has no actions for IANA.

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

This document does not contain sections written in a formal language.

(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

This document specifies the EAP key hierarchy and provides a framework
for the transport and usage of keying material generated by EAP
authentication algorithms, known as "methods". It also provides
a system-level security analysis, according to the principles described in
"Guidance for AAA Key Management".

- Working Group Summary

Much of the WG discussion of this document centered on aspects of key management,
including key creation, deletion, transport and naming. EAP usage is growing
increasingly diverse, so that there was discussion about whether the
the examples depict the issues encountered in existing EAP lower layer
implementations, and whether the principles articulated are universal or
merely true for all existing implementations. There was also discussion about
the relationship between this document and "Guidance for AAA Key Management"
which articulates principles that AAA Key Management solutions must satisfy to
qualify for standards track publication.

- Document Quality

There are existing implementations of this document, and further implementations
are likely.

- Personnel

Bernard Aboba is the document shepherd. The responsible Area Director is
Jari Arkko. No IANA expert is needed.