Subject: [eap] channel binding consensus call

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

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?

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

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.

Please answer by Wednesday, August 31st.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Aug 2005 11:04:58 +0300

Responding to my own questions, personal opinions
of course...

>    of a solution/protocol that provides channel bindings?

I believe we have realized that channel binding functionality
would be useful. We are also at a stage where there's new
protocol work happening (methods) and where EAP and
AAA usage is growing, (e.g., due to new VPNs, link layers
that are adopting it).This creates a window where we can
actually have an effect, so I think we should do it.

But as has been noted by others, we haven't finished the
discussion of what kind of approach(es) to use.

>    as Yoshi's scheme goes, was "independent

The keying framework should say roughly what
it already says about this matter, i.e., talk about
the security properties and explain the impacts
of different approaches.

>    or developing both method and aaa-key based

I do not believe we need to make one choice for
ever, or forbid e.g. specific methods to do what they
want. However, for interoperability, media and method
independence reasons, I believe we need to choose a single
recommended mechanism that is developed in EAP
WG (or elsewhere), and bring it to a state where it
is fully specified and directly usable in common EAP
usage scenarios.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Aug 2005 13:17:25 -0400

>    of a solution/protocol that provides channel bindings?

Yes, I think we should take it a WG work item.  This is my impression
I had while I was participating in the reviewing process of IEEE
802.16e on their EAP usage in last couple of months.  Since EAP WG did
not have an official channel binding solution at that moment, we could
not make a useful recommendation to 802.16e about channel binding.  I
hope new lower layers can benefit from an official channel binding
solution.

>    as Yoshi's scheme goes, was "independent

I'd like to see basic framework solution [like the 3 approaches
outlined by Joe] described in the keying framework draft.  Actual
detailed solution can be defined in separate document.

>    or developing both method and aaa-key based

I agree with Bernard that we might not be at the point we can choose a
single solution.  However, before making a decision to allow multiple
solutions, I think we might need more analysis on the impact of
allowing multiple solutions.  For example, we can argue whether (i)
each lower layer specification chooses one of multiple solutions
(e.g., lower layer X must use solution 1 and lower layer Y must use
solution 2, etc.), or (ii) each lower layer specification allows to
use multiple solutions (e.g., some deployment of lower layer X uses
solution 1 and another deployment of the same lower layer X uses
solution 2, etc.).

Yoshihiro Ohba