Hi Hannes,
As you know EAP-pwd was presented to EMU and the ADs ruled that
it was out of scope. Since the ADs are the same, and the EMU charter
is the same then EAP-pwd must still be out of scope for EMU. So that
course is not available. What Bernard says makes a lot of sense.
Unfortunately, that was tried already and it failed.
The reason EAP-pwd should be Standards Track is because it is important
for the Internet community to recommend a _secure_ way of doing
authentication using only a shared key (i.e. no certificate needed).
Today we have an Internet recommendation for that practice that is
susceptible to a passive off-line dictionary attack. EAP-pwd is not
susceptible to such an attack.
There is no official policy about Standards track EAP methods only
coming out of EMU. And following such an unwritten policy will produce
the following bizarre situation for authenticating using a shared key:
INSECURE is on Standards Track (EAP-GPSK)
SECURE is Informational (EAP-pwd)
That makes no sense.
Informational RFCs are for edification purposes. Proposed Standards
represent a recommendation of the Internet community and if the
Internet community is going to recommend a practice (and it obviously
is doing that) then it should recommend a secure practice and not an
insecure one. Why is that so puzzling?
regards,
Dan.
On Sat, July 25, 2009 2:55 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> In the past EAP method authors could publish their EAP methods as
> Informational or Experimental RFCs. For Standards Track EAP methods we
> had to go through the EMU working group.
>
> This is what we did, for example, with the pre-shared key EAP method:
> * EAP-PSK http://www.rfc-editor.org/rfc/rfc4764.txt was published as an
> Experimental RFC.
> * EAP-PAX http://tools.ietf.org/html/rfc4746 was published as an
> Informational RFC.
> * EAP-GPSK http://tools.ietf.org/html/rfc5433 was an effort done in the
> EMU working group with input from various pre-shared EAP method
> proposals, including EAP-PSK and EAP-PAX.
>
> Hence, I agree with Bernard and I am a bit puzzled why
> draft-harkins-emu-eap-pwd was planned for Proposed Standard.
>
> Ciao
> Hannes
>
>
> ________________________________
>
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On
> Behalf Of ext Bernard Aboba
> Sent: 23 July, 2009 03:37
> To: ietf@xxxxxxxx
> Subject: Re: Last Call: draft-harkins-emu-eap-pwd (EAP
> Authentication UsingOnly A Password) to Proposed Standard
>
>
> I would like to comment on the process aspect of this IETF last
> call. A subsequent post will provide comments on the protocol.
>
> Overall, I believe that the appropriate process for handling
> this document is not to bring it to IETF last call as an individual
> submission, but rather to charter a work item within an IETF WG.
>
> There are two current EAP method drafts that are based on
> zero-knowledge algorithms:
> 1. http://tools.ietf.org/html/draft-harkins-emu-eap-pwd (this
> document)
> 2. http://tools.ietf.org/html/draft-sheffer-emu-eap-eke
>
> Previously there was also an EAP method submission utilizing
> SRP:
> 3. http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03
>
> All three of these documents were slated for inclusion on the
> IETF standards track.
>
> Given the number of EAP method RFCs that have already been
> published, I do not believe that it serves the Internet community for
> the IETF to publish multiple EAP method specifications of a similar
> genre on the Standards Track, while bypassing the WG process.
>
> If the standardization of zero-knowledge algorithms is an
> important area of work for the IETF (and I believe this to be true),
> then work in this area should be chartered as a working group work item,
> with the goal to select a single method for standardization. Prior to
> the EMU WG re-charter, Dan Harkins made an argument for chartering of
> work in this area. His arguments were sound then, and they are (even
> more) sound today. However, Dan did not succeed in getting the work
> added to the EMU WG charter. It is time for the IESG to re-consider its
> decision to delay standardization of zero knowledge algorithms, which
> was made in the earlier part of the decade. If the EMU WG is not
> suitable for handling this work, then another security area WG should be
> created for the purpose.
>
>
>
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf