eap Mailing List: RE: Issue: Requirement on transport of EAP keying material

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

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:bernard_aboba [at] hotmail.com] 
Sent: Friday, December 02, 2005 12:59 AM
To: jsalowey [at] cisco.com; eap [at] frascone.com
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" <jsalowey [at] cisco.com>
>To: <eap [at] frascone.com>
>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: jsalowey [at] cisco.com 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