Re: [Emu] Potential Notes in EAP-FAST Documents

Dorothy Stanley <dstanley1389@gmail.com> Tue, 03 February 2009 16:13 UTC

Return-Path: <emu-bounces@ietf.org>
X-Original-To: emu-archive@megatron.ietf.org
Delivered-To: ietfarch-emu-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836D928C126; Tue, 3 Feb 2009 08:13:51 -0800 (PST)
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B9528C126; Tue, 3 Feb 2009 08:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 jRoCJ41SOH-J; Tue, 3 Feb 2009 08:13:49 -0800 (PST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 21A1628C0DF; Tue, 3 Feb 2009 08:13:49 -0800 (PST)
Received: by wa-out-1112.google.com with SMTP id m33so1087215wag.5 for <multiple recipients>; Tue, 03 Feb 2009 08:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EpN7LlA1wkRtvp8Tl1PS9SIC5Z8hyuRyPdHxVgtPvsg=; b=oN2pXex4J9amhnePKAzy+O9A3uH89ojZGnVcZElRmQr8zDttK5Os2QWywCu5c+l06D nix5fpW8YE5aRstoQwhuIFe7aTyxsvmN0Gl774v8e23KX+hljQYvA0RzdDwQ9L3n7JMA Ats0V81RW8rcvj+a4siKCbxxudaFT0GlyMpq8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iaCQTzIZLiNMW8fGsTyWzD36HGyYLaTBCTRRlFIlm9p2zGR4m8w0bflOAU7y9tXkua GhVtrMTF6ECi8+703OFspukycJWt5RYaGaH2UDUJu4/YX/x/tuK+bQ0gLDw9CAzo62Jn 9U7hltLiBLNtss+nM0L8SSKfEVH7SafZzG/0g=
MIME-Version: 1.0
Received: by 10.114.194.1 with SMTP id r1mr3767208waf.149.1233677609315; Tue, 03 Feb 2009 08:13:29 -0800 (PST)
In-Reply-To: <012a01c985ab$210b2490$63216db0$@net>
References: <20090201204629.D5F093A6974@core3.amsl.com> <012a01c985ab$210b2490$63216db0$@net>
Date: Tue, 03 Feb 2009 08:13:29 -0800
Message-ID: <5bfe7a820902030813j36702991g6d24252bb63b7d34@mail.gmail.com>
From: Dorothy Stanley <dstanley1389@gmail.com>
To: Glen Zorn <glenzorn@comcast.net>
Cc: Russ Housley <housley@vigilsec.com>, iesg@ietf.org, emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0154368352=="
Sender: emu-bounces@ietf.org
Errors-To: emu-bounces@ietf.org

The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC
implementations and incorrect re-use of EAP Types must be
addressed/corrected prior to publication.

One solution is to

(a) Get a new, correct type number for use by the method in the published
document, and change the name of the method
(could use "name-CR" for "corrected/revision", or similar). This eliminates
the interoperability concern with existing methods,
and uniquely identifies the IETF published method.

and

(b) Add descriptive text in the document to explain the difference between
this IETF published method and similar  deployed
methods - to meet the desire to document deployed methods.

Dorothy Stanley

On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn <glenzorn@comcast.net> wrote:

>
> > Dear EMU WG:
> >
> > These two documents are in the RFC Editor queue:
> >
> >    draft-cam-winget-eap-fast-provisioning-10.txt
> >    draft-zhou-emu-fast-gtc-05.txt
> >
> > The IESG has received a very late comment about these documents, and
> > we seek your input on the proposed resolution.
> >
> > The late comment raises a potential interoperability concern with
> > existing implementations of EAP-MSCHAPv2 and EAP-GTC.
> >
> > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies
> > a very specific way to generate the challenges used in EAP-MSCHAPv2
> > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2
> > exchanges.
> >
> > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is
> > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST-
> > GTC
> > employs a subset of the EAP-GTC formatting.
> >
> > The IESG recognizes the difficulties caused by re-use of an EAP Type.
> > Further, the IESG recognizes the concern about implementations that
> > might not easily adapt to additional requirements.  However, the IESG
> > also recognizes the significant value in documenting EAP methods that
> > are implemented and deployed in the Internet today.
> >
> > The IESG believes that the right thing to do in this situation is to
> > proceed with the publication of these documents.  However, the IESG
> > also
> > sees value in warning future EAP method designers about this experience
> > so that this pain might be avoided in the future.
> >
> > The IESG is considering the additional informative paragraph in the
> > IANA
> > considerations section of both documents that says:
> >
> >     IESG Note: EAP-FAST has been implemented by many vendors and it is
> >     used in the Internet.  Publication of this is intended to promote
> >     interoperability, even though the use of the EAP-MSCHAPv2 and
> >     EAP-FAST-GTC EAP methods might be difficult in some software
> >     environments.  If EAP-FAST were to be designed today, these
> >     difficulties could be avoided by the assignment of new EAP Type
> >     codes.
> >
> > Please provide comments on the proposed way forward.
>
> I am strongly opposed to the publication of these documents as RFCs in
> their
> current form.  Not only is the "fast provisioning" for EAP-FAST what can
> only be characterized as a security disaster, but EAP-FAST-GTC has nothing
> whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined for use with
> various Token Card implementations which require user input" but
> EAP-FAST-GTC is used solely to transfer a username/password combination,
> the
> password in plaintext.  It's hard to see what this has to do with actual
> token cards & appears to be a lazy misuse of an existing type.
>  Furthermore,
> it's even harder to see how rewarding this kind of nonsense with
> publication
> will serve as a warning of any kind; I would expect that the action of
> publication (with or without IESG note) would be more likely taken as
> notice
> that one can do whatever one please without fear.
>
> > On behalf of the IESG,
> >   Russ
> >
> > _______________________________________________
> > Emu mailing list
> > Emu@ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu