Subject: RE: [eap] RE: channel binding

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 8 Aug 2005 11:12:48 -0700

> >
> >[Joe] We are discussing the capabilities of an EAP-method.  
> Although an 
> >EAP-method can generate keys there is nothing forcing those 
> keys to be 
> >used for anything.  Binding data to the authentication exchange and 
> >binding data to the key derivation are similar but different 
> approaches.
> 
> Although I agree that binding data to the authentication 
> exchange and binding data to the key derivation are different 
> approaches, I don't agree with using keys generated by an EAP 
> method for arbitrary purpose, especially AAA-Key.  I think 
> there is a key-scoping issue if we do not specify the usage 
> of the keys generated by an EAP method.  At least AAA-Key 
> should be restricted to be used by a specific pair of EAP 
> peer and authenticator. Also, this is also related to EAP 
> applicability statement which currently allows the use of EAP 
> for network access authentication, not for authentication for 
> arbitrary application.
>

[Joe] I'm not sure what you are talking about as this has nothing to do
with what I mentioned above.  I suggest that we do not try to confuse
the issue.

  > Besides this I have two issues on the use of EAP-method based 
> chanel binding scheme.
> One issue is as described in section 2 of 
> draft-ohba-eap-aaakey-binding. 
> The other issue
> is complexity being added to each EAP method by having direct 
> communication between each EAP method and lower layer, which 
> is not described in the EAP state machine I-D. The latter 
> issue issue keeps me away from implementing EAP-method based 
> chanel binding scheme in Open Diameter EAP libraries.
> 
[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.   

> Regards,
> Yoshihiro Ohba
> 
> 
> >I do not think that one should eliminate binding of data in the 
> >authentication in favor of binding data in the key 
> derivation as they 
> >solve different problems.  I am not familiar with the 
> EAP-IKEv2 use of 
> >"channel bindings", but I would rather see the capability 
> fixed if it 
> >has a problem than removed.
> >_______________________________________________
> >eap mailing list
> >[email-masked]
> >http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Yoshihiro Ohba" <[email-masked]>
Date: Mon, 08 Aug 2005 23:37:19 +0000

Hi Joe,

>From: "Salowey, Joe" <[email-masked]>
>To: "Yoshihiro Ohba" <[email-masked]>
>CC: <[email-masked]>
>Subject: RE: [eap] RE: channel binding
>Date: Mon, 8 Aug 2005 11:12:48 -0700
>
>
> > >

Maybe I have over-reacted to the part "nothing forcing those keys to be 
used for anything".

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

Yoshihiro Ohba

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Aug 2005 01:02:49 -0500

> carry channel parameters a good idea (even in the form a blob), while you 

Except that channel bindings are part of EAP.  That you think they're not
a good idea does not make the feature go away :)  Are you proposing that
the feature be removed?  Or simply that some mechanism or other not
provide it?  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
--

---

From: "Yoshihiro Ohba" <[email-masked]>
Date: Wed, 10 Aug 2005 02:38:44 +0000

>From: Nicolas Williams <[email-masked]>
>To: Yoshihiro Ohba <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [eap] RE: channel binding
>Date: Tue, 9 Aug 2005 01:02:49 -0500
>
>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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Aug 2005 14:41:25 -0500

You are correct about this: given an EAP method that provides keying but
not channel (or cryptographic) bindings it should be possible to provide
those elsewhere.

RFC3748 speaks of "a protected exchange of channel properties," but I
don't see how working these properties into key derivation departs from
the spirit of the RFC3748 description.

I.e., I don't see how what you propose is fundamentally new in regards
to EAP channel binding -- what's new in what you propose is to add
components that provide features missing from methods.

I can't help but be reminded of the stackable pseudo-mechanism notion
that we're working on in the GSS-API context at the KITTEN WG.  That is,
I think it's a good idea -- I would, of course, since I've been
promoting idea of GSS stackable and composite mechanisms ;)

I don't necessarily agree that all methods should be simplified by not
providing optional features that can be provided via composite methods.

But thinking of the SECMECH BoF GUAM proposal I do agree that the core
of a mechanism could/can/should indeed be specified such that it
provides only the fundamental properties needed and the rest of the EAP
or GSS semantics can then be provided by inclusion or elsewhere.

Nico

---

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

>Date: Wed, 10 Aug 2005 14:41:25 -0500
>

I'ts not fundamentally new because the goal is the same, but it's a 
different approach.

>providing optional features that can be provided via composite methods.

I understand your point.

>or GSS semantics can then be provided by inclusion or elsewhere.

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.

Best regards,

Yoshihiro Ohba

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 14:40:27 -0500

> - Key-derivation based channel binidng solution should be specified as an 

I'm a bit of a neutral party in this, so far.  You'll want to see what
Joe and the rest of the EAP community have to say.  Going by what Joe
has written already I think that only proposals involving changes to
specs that have not been implemented and deployed have a chance of
producing consensus.

Nico

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 Aug 2005 14:47:56 -0400

> specs that have not been implemented and deployed have a chance of

I have not heard any channel binding solution implemented and
deployed, and the above changes should be ok in this regard.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 14:38:15 +0300

Salowey, Joe wrote:

>system. 
Yes. At least for me, personally, the severity of the impacts
to the "system" are the key decision factor on which type
of channel bindings to use. While both require changes,
we probably have different ideas in the group regarding
what changes are more acceptable than others... personally
I'd like to avoid NAS/AP changes for deployment reasons,
which speaks in favor of method-based schemes. But
YMMV.

--Jari