Re: RE: channel binding
From: Jari Arkko (jari.arkkopiuha.net)
Date: Fri, 26 Aug 2005 02:55:12 -0400 (EDT)
Salowey, Joe wrote:





-----Original Message-----
From: Jari Arkko [mailto:jari.arkko [at] piuha.net] Sent: Thursday, August 25, 2005 4:43 AM
To: Salowey, Joe
Cc: Yoshihiro Ohba; Nicolas.Williams [at] sun.com; eap [at] frascone.com
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

an extension to EAP keying framework.





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

But I could have misunderstood what you meant.

--Jari


Results generated by Tiger Technologies using MHonArc.