Subject: [eap] channel binding

From: "Yoshihiro Ohba" <[email-masked]>
Date: Mon, 08 Aug 2005 16:02:47 +0000

Hi Joe,

On Fri, Aug 05, 2005 at 02:33:18AM -0700, Salowey, Joe wrote:
>  
> 
> > -----Original Message-----
> > From: Jari Arkko [mailto:[email-masked]] 
> > Sent: Friday, August 05, 2005 1:59 AM
> > To: [email-masked]
> > Cc: Yoshihiro Ohba
> > Subject: [eap] channel binding
> > 
> > Forwarding bounced message to the list:
> > 
> > >Subject: channel binding
> > >User-Agent: Mutt/1.5.9i
> > >
> > >In the IETF63 EAP meeting, I think there was a consensus 
> > that the new 
> > >channel binding scheme described in 
> > >draft-ohba-eap-aaakey-binding-00.txt will not be included in the EAP 
> > >keying framework draft.  But I would like to confirm if it is OK to 
> > >describe the scheme to be described in a separate document as an 
> > >extension to the keying framework.
> > >
> > >As Hannes mentioned in the meeting, we need an answer for it 
> > as soon as 
> > >possible because EAP-IKEv2 (I am a co-author of it) has its 
> > own channel 
> > >binding functionality and I think that if the new channel binding 
> > >scheme is accepted as an extension, we can remove the 
> > channel binding 
> > >functionality from EAP-IKEv2 to make it much simpler and rely on the 
> > >new channel binding scheme instead.
> > >
> 
> [Joe] I don't think it would be a good idea to remove "channel bindings"
> from EAP-IKEv2 itself.  Performing this functionality in the method is
> different than doing it in the key derivation.  For example there are
> uses of EAP where EAP derived keys are not used and therefore any sort
> of binding in the key derivation would be useless.

I don't understand this, as we are not discussing the case where EAP
derived keys are not used.

Yoshihiro Ohba

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 8 Aug 2005 16:49:53 -0700

> 
> I think this is where we have different opinions. I don't 
> think using EAP methods to carry channel parameters a good 
> idea (even in the form a blob), while you think it is advantageous...
>
[Joe] Yes, I believe that being able to bind information (channel
parameters or otherwise) to the authentication exchange within an EAP
method is a good thing.

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 15 Aug 2005 12:09:56 -0700

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

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, August 13, 2005 2:23 PM
> To: [email-masked]
> 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.

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 26 Aug 2005 10:25:44 -0700

> Sent: Thursday, August 25, 2005 11:55 PM
> To: Salowey, Joe
> Cc: [email-masked]
> Subject: Re: [eap] RE: channel binding
> 
> Salowey, Joe wrote:
> 
> > 
> >
> >  
> >
> >>Sent: Thursday, August 25, 2005 4:43 AM
> >>To: Salowey, Joe
> >>Cc: Yoshihiro Ohba; [email-masked]; [email-masked]
> >>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
> >>    
> >>
> >>>[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