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

Perhaps we can deal with this entirely in 313 -- the
original text proposal in Joe's first e-mail did not work
too well for me.
--Jari
Salowey, Joe wrote:

-----Original Message-----

From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Thursday, December 01, 2005 10:59 PM

To: Salowey, Joe; 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.  

[Joe] Yes, it is. 

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.

[Joe] This makes sense.  If we define an authenticator to span multiple
physical entities then I am OK with the current text. Perhaps we should
include this in the definition or point to sections of the document
where this is described.  I'm thinking maybe we should pull the
description of the authenticator variations out of 2.4 into its own
section on EAP authenticator.

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.  

[Joe] I'm not sure that this is true. I'm not sure that the

authenticator identity is necessarily the only choice for identifier.

The lower layer must define what the identifier is, define attribtues in

AAA protocols need to carry the identifier and how to do comparisions of

the identifier.  However this is a separate issue related to section

2.4.  

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

Re: Issue: Requirement on transport of EAP keying material	<– Date –> <– Thread –>
From: Jari Arkko (jari.arkkopiuha.net)
Date: Tue, 13 Dec 2005 06:05:59 -0800 (PST)

eap Mailing List
View Index by: Date - Thread - Author