eap Mailing List: RE: channel binding consensus call

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Thursday, August 25, 2005 5:27 AM
> To: eap [at] frascone.com
> Subject: [eap] channel binding consensus call
> 
> 
> In IETF-63 we discussed different ways of achieving channel 
> bindings, but we also got requirements from methods authors 
> that a solution is needed so that they can include/reference 
> it in their specifications and analysis. In the SECMECH BoF 
> there were also comments made that the channel binding 
> functionality is essential.
> 
> In the last couple of weeks there's been a discussion about 
> the pros and cons of the two proposed schemes.
> Before continuing that discussion, I'd like to take a step 
> back and first make the decision that we'll actually be 
> working on some solution, and some of the key requirements 
> for the solution. This will also confirm the consensus that 
> we had in Paris for not developing such a solution to the 
> keying framework.
> 
> So here are the questions:
> 
> 1. Should we take on a WG work item, a specification
>     of a solution/protocol that provides channel bindings?
> 
[Joe] I don't think there is necessarily a single solution.  I think
there are three different approaches that have been discussed as
"channel bindings"

1. both parties pass data into the EAP method.  The data is bound to the
authentication exchange so it can't be modified.  If the data input by
both parties matches then the method succeeds, else the method fails.
This approach is similar to "channel bindings" used in the GSS-API.

2. Both parties pass data into the method that is bound to the
authentication exchange so it can't be modified and can be output on the
other side.  Each party takes the exported data from the method and
validates it to determine if there is success or failure. 

3. Both parties input data independent of EAP that gets mixed into the
key material that is output from EAP.  If the data matches the keys
match, if the keys don't match then keys don't match. 

Type 1 and 2 require support from EAP methods.  Type 1 and 3 fail if
there is any mismatch in data where type 2 allows for some flexibility.
Type 3 requires that you use go through the process of using the derived
key material before you discover a problem, whereas type 1 fails in the
method.  Type 3 probably requires the most AAA work, although they
probably could all benefit from it. 

> 2. Is this solution something that should go to
>     keying framework, as "the" mechanism to be
>     used by everyone, or is it an independent
>     extension? Result from Paris, at least as far
>     as Yoshi's scheme goes, was "independent
>     extension".
> 

[Joe] I don't think you can necessarily specify a mechanism that can be
used by everyone.  For example a mechanism that only modifies the key
material does you no good if the consumer of the EAP method is not using
the key material. 

> 3. Should the solution be unified in some sense
>     across different types of EAP usage or should
>     we pursue multiple approaches? An example
>     of multiple approaches would be leaving it
>     to individual method writes without coordination,
>     different mechanisms for different link layers,
>     or developing both method and aaa-key based
>     mechanisms.
> 

[Joe] My opinion is that we should specify a recommendation for methods
to support type 1 above and possibly type 2.  Type 3 is largely
independent of EAP and needs to be specified in the lower layers and
perhaps the AAA protocol (which might be useful for 1 as well). We can
describe the approach at a high level and the AAA attributes that would
help facilitate it.