Subject: [eap] Issue: Requirement on transport of EAP keying material

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 1 Dec 2005 15:14:01 -0800

Submitter name: Joe Salowey
Submitter email address: [email-masked]
Date first submitted: 12/1/2005
Reference:
Document: Keying Framework
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 2.2
Rationale/Explanation of issue:

The document states 

"In order to prevent the compromise of
   transported EAP keying material and parameters, the AAA client and
   EAP authenticator MUST be co-resident."

It could be possible for the EAP authenticator to use another secure
protocol other than a AAA protocol to transport EAP key material.  

Requested change:

"In order to prevent the compromise of
   transported EAP keying material and parameters they MUST be securely
transmitted from the entity that hosts the EAP server to the entity that
hosts the EAP authenticator and makes use of the key material."
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 01 Dec 2005 22:59:15 -0800

I think the issue here is similar to the one brought up in Issue 313.  An 
EAP authenticator may be constructed in a variety of ways.  Whether the 
authenticator has multiple ports or a single port,  involves multiple CPUs 
or a single CPU, or even is constructed using lightweight APs and a WLAN 
switch is not relevant to EAP.

For EAP purposes, an Authenticator is an entity that identifies itself with 
a single authenticator identity, both within the lower layer as well as in 
AAA.  Neither the EAP peer nor the AAA server care about the details of how 
the authenticator is constructed, and neither should this document.

So when the document says that the "Authenticator and AAA cilent are 
co-resident" it means that both the Authenticator and AAA client share the 
same authenticator identity.  This is required, because if it were not true 
then Channel Bindings would fail to verify.  That's probably all we can or 
should say on this subject.

>From: "Salowey, Joe" <[email-masked]>
>To: <[email-masked]>
>Subject: [eap] Issue: Requirement on transport of EAP keying material
>Date: Thu, 1 Dec 2005 15:14:01 -0800
>