Subject: RE: [eap] RE: channel binding

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 10 Aug 2005 07:17:31 -0700

> > 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.) 
 
[Joe]  The objections I heard in the EAP meeting to the key binding
approach were that it requires changes in many places (Peers,
authenticators and servers).  This is not a trivial objection. You are
correct that channel bindings requires support from EAP methods,
however many methods have the capability for this support already, but
it does need more definition.  

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

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

> 
> 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
> >--
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Yoshihiro Ohba" <[email-masked]>
Date: Thu, 11 Aug 2005 18:56:40 +0000

Hi Joe,

>From: "Salowey, Joe" <[email-masked]>
>

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.

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

>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