eap Mailing List: RE: RE: channel binding

[Yoshihiro Ohba (yohba727]

Hi Joe,

> From: "Salowey, Joe" <jsalowey [at] cisco.com>
>
> > 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.
>
> [Joe] No I did not say that, unfortunately I haven't had a chance to
> read the EAP-IKEv2 draft yet.  The way it does channel bindings may not
> be acceptable and may need to change.  What I am in favor of is defining
> EAP methods so that the information can be bound to the authentication
> exchange.  I believe this is a more general solution to a class of
> problems than key binding.  I think it would be fine to do key binding
> in addition if a lower layer can make use of it, but it is a lower layer
> function.

I'd say that a more general solution should better be defined in an 
"extensible authentication 
protocol" (not necessaliry the EAP defined in RFC 3748) itself, not within 
each authentication method run on top of it.  On the other hand, I don't 
think EAP is a right behicle to define it mostly because EAP itself does 
not have its own protection mechanism. I don't think it's a good idea to 
expand each EAP authentication method towords a more general solution, 
which I believe would make things worse than better in terms of complexity 
and interoperability. Carrying channel parameters in EAP methods seems to 
be a gray area.

> > 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.
>
> [Joe] Since key binding and binding within the method are doing the same
> thing I don't see why the same approach wouldn't be taken with both of
> them.  The difference just happens to be an artifact of your IKEv2
> definition.  I don't think it is necessary to have IANA assigned values.

You are right.  We can define a blob in EAP-IKEv2 Notify payload to avoid 
IANA assigned values, if people want it.

> There are two ways that I think are feasible to implement  channel
> bindings.  One is to take external lower layer parameter blob that is
> input by both sides and have both sides ensure that the bindings are the
> same (this is the GSS-API approach).  The other is to take an optional
> lower layer blob defined by the lower layer application on both sides
> and return the lower layer blob to the other party for validation in the
> lower layer (this is the approach that has been discussed in the EAP
> group).   Neither of these require the EAP method to understand the
> channel bindings.  The GSS-API approach is very similar to your key
> binding approach.  The EAP approach is somewhat more complex, but allows
> for more variation in how parameters are evaluated.

I'd like to see the GSS-API like approach at least as an optional 
mechanism.

Yoshihiro Ohba


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