eap Mailing List: Re: RE: channel binding

[Yoshihiro Ohba (yohba727]

> From: Nicolas Williams <Nicolas.Williams [at] sun.com>
> To: Yoshihiro Ohba <yohba727 [at] hotmail.com>
> CC: jsalowey [at] cisco.com, eap [at] frascone.com
> Subject: Re: [eap] RE: channel binding
> Date: Tue, 9 Aug 2005 01:02:49 -0500
>
> On Mon, Aug 08, 2005 at 11:37:19PM +0000, Yoshihiro Ohba wrote:
> > >From: "Salowey, Joe" <jsalowey [at] cisco.com>
> > >Date: Mon, 8 Aug 2005 11:12:48 -0700
> > >
> > >[Joe] Neither mechanism is ideal, as the both require changes to the
> > >system. I am not arguing against binding information in the key
> > >derivation.   I am saying that performing this function in the 
mechanism
> > >is different that performing it in the key derivation and that I 
believe
> > >it is advantageous to have this functionality in the mechanism.
> >
> > 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...
>
> Except that channel bindings are part of EAP.  That you think they're not
> a good idea does not make the feature go away :)  

I believe that the channel binding mechansm described in RFC 3748 (i.e., 
EAP-method based mechanism) is just a possible solution.  RFC 3748 does not 
mandate the use of the specific channel binding mechanism. RFC 3748 has the 
EAP-method based channel binding mechanism in the security claims list in 
section 7.2, but now it turns out that there is another solution (i.e., 
key-derivation based mechanism).  I am trying to suggest having a fresh 
view of the problem.

> Are you proposing that the feature be removed?  Or simply that some 
mechanism or other not
> provide it?  

I am proposing to have the key-derivation based channel binding mechanism 
as an extension to EAP key management, meaning that some system can use it 
instead of the EAP-method based mechanism. All EAP methods that do not 
carry channel parameters (and most EAP methods do not) will benefit from 
this extension. (And I did not hear objection in the EAP meeting on having 
the key-derivation based approach as an extension, though there was a clear 
objection to define the approach in the key management framework I-D.) 

Then, I thought if such an extension is defined, EAP-IKEv2 can be 
simplified by 
removing  removing the EAP-method based mechanism from the EAP-IKEv2 
specification
and rely on the extention instead.  It seems that Joe and you would like to 
see 
the EAP-method based mechanism defined in the EAP-IKEv2 specification as it 
currently stands.
If you would like to see it in EAP-IKEv2, then we need to consider how we 
can manage a list of channel parameters (which are mostly lower-layer 
parameters, I believe) carried in IKEv2 Notify payloads in EAP-IKEv2 by 
IANA. Is it a reasonable thing to let each SDO working on lower layers to 
carry EAP to register their parameters to IANA to be carried in EAP-IKEv2 
Notify payloads?  I think many people do not (yet) serisouly consider this 
level of details about the channel binding problem. Note that the 
key-derivation based mechanism addresses this issue by simply having each 
SDO to define its own content of the key-binding-blob.

Yoshihiro Ohba

> The former would require, er, much process and would likely
> not succeed; the latter may be a matter of course for some types of
> mechanisms, but for those that provide full keying functionality I see
> no reason not to also provide channel binding (though you might argue
> that features such as channel binding and cryptographic binding could be
> provided by pseudo-mechanisms stacked atop any mechanism that provides
> for key derivation, and I'd agree, but I'd rather see such features
> provided natively as well).




> Nico
> --