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

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 5 Jan 2006 12:39:30 -0500

Let me see if I understand this.

Peer--------authenticator-----------EAP server
			AAA client------AAA server 

The way I understand it, the authenticator is simply a pass-through, so
it is visible to the peer according the EAP documentation, so the peer
knows the authenticator ID. The authenticator does not really have to
have AAA functionality to assist EAP, does it. It is the really the AAA
client that encapsulates the EAP signaling into AAA protocol
Since AAA function is really not visible to the peer, the AAA client
does not have to be visible to the peer. The AAA client is the entity
that deals with AAA server and hence receives the transported EAP keying
material (not the authenticator, right?).
The "co-resident" requirement seems to only serve the purpose of fixing
the channel binding issue, since the peer sees the authenticator, while
the server sees the AAA client. I think this limits the usage of EAP
keying. If I have a key distribution center that wants to say do
handover keying and if I want the KDC to receive the master keys from
EAP server, it means KDC must be a AAA client and the above requirement
means a KDC cannot be geographically separate from the authenticator.
All this because we are trying to solve the channel binding problem??

Any comments?

Madjid 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, December 02, 2005 12:59 AM
To: [email-masked]; [email-masked]
Subject: RE: [eap] Issue: Requirement on transport of EAP keying
material

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

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

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

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 5 Jan 2006 12:40:44 -0500

I don't see how the proposed change makes anything any different? 

-----Original Message-----
From: Salowey, Joe [mailto:[email-masked]] 
Sent: Thursday, December 01, 2005 5:14 PM
To: [email-masked]
Subject: [eap] Issue: Requirement on transport of EAP keying material

The document states 

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