"Zero knowledge" is definitely crypto-intensive. For example, to get both privacy and strong password protection, at least two DHs are required.
However, there are circumstances where server-side certificates aren't acceptable. Even in today, many/(most?) EAP deployments do not involve certificates (e.g. LEAP, FAST). Even if "zero knowledge" isn't used on an ongoing basis (out of concern for load, for example), it still can be useful for initial provisioning. For example, EAP FAST provisioning is vulnerable to man-in-the-middle attack or dictionary attack, which could be removed with use of "zero knowledge" algorithms.
Subject: AW: [Emu] EMU Charter revision
Date: Fri, 22 Feb 2008 15:34:56 +0100
From: hannes.tschofenig at nsn.com
To: bernard_aboba at hotmail.com; emu at ietf.org
Hi Bernard,
a question your excitment regarding strong password based EAP
method.
Why do you think they are useful? There are other ways (and they
are deployed already) that can accomplish the same result without going
along the SRP & co track.
Is it because you expect performance improvements or because the
crypto-mechanisms look nicer?
I cannot quite understand the motivation.
Ciao
Hannes
I also do NOT approve of the current charter revision, for several
reasons:
a. The Charter text contains statements that are no
longer true. For example:
"Most of these methods are proprietary methods and only a few methods
are documented in RFCs."
The following EAP methods are now documented in RFCs:
EAP-TLS (RFC 2716)
EAP-SIM (RFC 4186)
EAP-AKA (RFC 4187)
EAP-PAX (RFC 4746)
EAP-SAKE (RFC 4763)
EAP-PSK (RFC 4764)
EAP-POTP (RFC 4793)
EAP-FAST (RFC 4851)
EAP-IKEv2 (RFC 5106)
9 methods claiming to satify RFC 4017 critieria is more than a "few".
b. The Charter requires support for Channel Bindings without doing the
preparatory work to define how Channel Bindings works. Either the
requirement should be removed, or a work item should be added to
better define the approach to Channel Bindings.
c. The text on tunnel methods does not provide enough guidance to avoid
potentially fruitless arguments. So far, the EMU WG has not been able
to come to consensus on selection of one of the existing tunneling
protocols, and efforts to design "yet another" tunneling protocol
haven't gotten very far either. I'd like to see more specific
language that would make it clear that work on improving existing
tunneling protocols is within scope, and also that the EMU WG,
if it cannot come to consensus on a single protocol, can proceed to
work on one or more protocols with significant support.
d. Password-based methods. While I can understand the desire to limit the
number of charter items, I do agree with Dan that work on weak-password
methods is important. With some of the IPR obstacles likely to fall by
the wayside in coming years, it is time for the IETF to re-visit its policy
on inclusion of "zero knowledge" algorithms within standards track documents.
Dan
Harkins said:
" Hi Joe,
I do NOT approve of the current charter revision, specifically the
change that says the password-based method can only be via the
tunneled method. I do approve of the inclusion of tunneled methods
in the charter though and would be willing to contribute as a
reviewer.
regards,
Dan."
On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote:
> The response to the charter revision has been underwhelming. I am a bit
> concerned that we do not have enough participation to complete the
> tunnel method work (most of the recent discussion has been about other
> methods).
>
> I would like to get an idea of the number working group members that
> approve of working on the tunnel method items and are able to
> participate in the development of requirements and specifications as
> contributors and/or reviewers.
>
> Please respond to this message and state whether you approve of the
> current charter revision and what capacity you would be willing to
> contribute towards tunneled method development: contributor, reviewer or
> not able to contribute.
>
> I have submitted an internet draft attempt at an outline of requirements
> for tunneled methods
> (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.
> txt) that I hope can provided a starting point for discussions on the
> list and in the Philadelphia meeting.
>
> Thanks,
>
> Joe
|
