eap Mailing List: Issue 398: Discuss

[Bernard Aboba (bernard_aboba]

Issue 398: Discuss
Submitter name: Sam Hartman
Submitter email address: hartmans-ietf [at] mit.edu
Date Submitted:  March 7, 2007
Reference:
Document: KEYING-18
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

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.