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

[Salowey, Joe (jsalowey]

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