eap Mailing List: Re: channel binding consensus call

[Jari Arkko (jari.arkko]

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

> 1. Should we take on a WG work item, a specification
>    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.

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

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.

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

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