RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

"Glen Zorn" <gwz@net-zen.net> Wed, 22 July 2009 10:48 UTC

Return-Path: <gwz@net-zen.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0059C3A6C10 for <ietf@core3.amsl.com>; Wed, 22 Jul 2009 03:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSFinxOYg550 for <ietf@core3.amsl.com>; Wed, 22 Jul 2009 03:48:15 -0700 (PDT)
Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 396F83A68E9 for <ietf@ietf.org>; Wed, 22 Jul 2009 03:48:15 -0700 (PDT)
Received: (qmail 2077 invoked from network); 22 Jul 2009 08:00:06 -0000
Received: from unknown (124.120.223.104) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 22 Jul 2009 08:00:06 -0000
From: Glen Zorn <gwz@net-zen.net>
To: "'Joseph Salowey (jsalowey)'" <jsalowey@cisco.com>, iesg-secretary@ietf.org
References: <012501ca0a0b$b435e770$1ca1b650$@net> <AC1CFD94F59A264488DC2BEC3E890DE50867B247@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50867B247@xmb-sjc-225.amer.cisco.com>
Subject: RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC
Date: Wed, 22 Jul 2009 14:55:36 +0700
Organization: Network Zen
Message-ID: <00a201ca0aa1$cf2c9ba0$6d85d2e0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoKC7BIE+Es9kcQT1OQB3VpRD6cowARNlFwABP0QCA=
Content-Language: en-us
Cc: iesg-secretary@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2009 10:48:16 -0000

Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] writes:
 
> I object to this document being published as a Proposed Standard.  When
> this document was discussed in the EMU meeting at IETF-71 there was
> much
> concern raised with respect to existing IPR in the area of secure
> password methods used by this draft.  Additionally, soon after its
> initial publication and announcement on the CFRG list, flaws were found
> with the draft.  The authors were very responsive in addressing the
> issues, but this points out that the algorithms used in this draft have
> had less review than other secure password mechanisms developed over
> the
> years.  Another approach to a secure password only EAP method, EAP-EKE,
> has been proposed in draft-sheffer-emu-eap-eke-02.  This method is
> based
> on EKE, which is already in use, has a long history of review, and has
> much better understood IPR considerations.  Given that there is an
> alternative to consider I do not support publishing EAP-PWD in the
> standards track.

IMHO, this question is orthogonal (& largely immaterial) to the one at hand.
It's one thing for the IETF to reach consensus that the draft be
Informational; it is a completely different thing for the publication path
to be changed without either notification of (other than the Last Call
announcement itself) or consultation with the authors.  If this was _not_ a
simple error, then the action was arbitrary & capricious, not to mentioned
underhanded & must certainly be considered as grounds for dismissal of the
(as yet unnamed) person or persons responsible, unless the IETF has recently
converted to an authoritarian regime.  As an aside, it seems that
draft-green-secsh-ecc has suffered the same fate, suggesting that this is
neither an error nor an isolated occurrence.

...