RE: Re: Channel Binding
From: Salowey, Joe (jsaloweycisco.com)
Date: Mon, 15 Aug 2005 15:05:49 -0400 (EDT)
Hi Bernard,

Yoshi's proposal of Channel binding through key binding is not a direct
EAP requirement, however it impacts the system using EAP.   I don't know
exactly what would go in a keying framework extension document at this
point, but if the channel binding functionality is important enough to
mention in the keying framework then it seems if we this is to provide
or supplement this functionality then it should be mentioned as an
alternative. 

As you mention, although it does not require changes to the EAP method
behavior it does require changes on the lower layer and the AAA that are
not the way things operate in practice today. 

Joe


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Saturday, August 13, 2005 2:23 PM
> To: eap [at] frascone.com
> Subject: [eap] Re: Channel Binding
> 
> > Key-derivation based channel binding solution should be 
> specified as 
> > an extension to EAP keying framework.
> 
> A question: is this an EAP issue or a AAA and lower layer issue?
> 
> From an EAP point of view, the EAP method passes down the 
> exported parameters to the lower layer.
> 
> The lower layer then can compute any required keying material 
> from the exported parameters and the Channel Bindings.
> 
> The same is true on the AAA server, which operates as an EAP 
> lower layer on the server side.
> 
> So as far as I can see, no changes are needed to EAP, EAP 
> methods, or the EAP key management framework in order to 
> support Yoshi's proposal.
> 
> All that is required is a specification for how the AAA 
> client requests the mixed key and how it is transported.  
> Presumably such a key cannot be transported in the Diameter 
> EAP-Master-Session-Key attribute or in the RFC 2548 
> attributes since it is not an MSK.
> 
> Of course, such a AAA specification would not be useful 
> unless a lower layer were to exist that would use it, so 
> you'd need a lower layer specification as well.
> 
> However, as far as I can see, no EAP key management extension 
> is required here.
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
> 

Results generated by Tiger Technologies using MHonArc.