eap Mailing List: RE: RE: channel binding

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Thursday, August 25, 2005 11:55 PM
> To: Salowey, Joe
> Cc: eap [at] frascone.com
> Subject: Re: [eap] RE: channel binding
> 
> Salowey, Joe wrote:
> 
> > 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Jari Arkko [mailto:jari.arkko [at] piuha.net]
> >>Sent: Thursday, August 25, 2005 4:43 AM
> >>To: Salowey, Joe
> >>Cc: Yoshihiro Ohba; Nicolas.Williams [at] sun.com; eap [at] frascone.com
> >>Subject: Re: [eap] RE: channel binding
> >>
> >>Salowey, Joe wrote:
> >>
> >>    
> >>
> >>>>OK.  I think we are reaching some agreement on (please
> >>>>        
> >>>>
> >>correct if I'm
> >>    
> >>
> >>>>wrong):
> >>>>
> >>>>- Channel binding mechanism in EAP-IKEv2 should not be 
> removed (but 
> >>>>needs some modification to carry a blob in order to avoid 
> the IANA 
> >>>>assignment issue.)
> >>>>
> >>>>- Key-derivation based channel binidng solution should be
> >>>>        
> >>>>
> >>specified as
> >>    
> >>
> >>>>an extension to EAP keying framework.
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>[Joe] Yes, I think this is a good approach.
> >>> 
> >>>
> >>>      
> >>>
> >>Hold it. Does this mean that we'll have two (possibly
> >>incompatible) ways of doing channel bindings for, say, wireless LAN 
> >>access?
> >>
> >>    
> >>
> >[Joe] I don't think so. It lower layer that needs to 
> coordinate this, 
> >since it will specify what data either needs to go into the method, 
> >come out of the method or bind to the keying material.  These 
> >approaches provide tools for binding additional data to the 
> >authentication and/or the key derivation, a lower layer 
> would have to specify how to use them.
> >  
> >
> I think I understand what you are saying. But does that mean 
> that what you want is a set of tools that can be used by 
> lower layers, but not a "ready made" solution that would work 
> over existing link layers as-is? Or are you referring to AAA 
> as the lower layer here? Certainly the AAA logic needs to be 
> involved in any of the approaches that we've discussed. But 
> it seems that in order to get an actual working channel 
> binding solution, provide interoperability and maybe even 
> media independence, its necessary to define the whole 
> process, and not just tools.
> 

[Joe] The lower layers are going to have to specify what goes into the
channel bindings.  We can specify the process at a high level.  Lower
layers typically define AAA attributes to carry lower layer parameters.
Interfaces to EAP and/or key derivation would need to be defined accept
channel binding data and AAA processing for lower layer services would
need to take advantage of this interfaces. 

I guess you could say we provide a "framework", but the lower layers
need to specify what gets used within the framework to make sense for
their domains. 

> But I could have misunderstood what you meant.
> 
[Joe] I'm not sure I really clarified it any. 

> --Jari
>