Subject: [eap] Issue 398: Discuss

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Mar 2007 16:04:35 -0800

Issue 398: Discuss
Submitter name: Sam Hartman
Submitter email address: [email-masked]
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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Thu, 8 Mar 2007 20:35:22 -0800

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Thursday, March 08, 2007 4:05 PM:

...

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

I think that this problem is one result of the sloppy terminology I
mentioned in a previous comment: of course, the AAA server has no
business looking at this cert but the EAP server does.  The problem
arises from the inappropriate conflation of the back-end EAP server and
AAA server entities.