Re: [Emu] server unauthenticated provisioning mode

"Dan Harkins" <dharkins@lounge.org> Fri, 26 August 2011 06:11 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201A321F8AFF for <emu@ietfa.amsl.com>; Thu, 25 Aug 2011 23:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Level:
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ9yeSH0lUqp for <emu@ietfa.amsl.com>; Thu, 25 Aug 2011 23:11:51 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 92CC821F8AFB for <emu@ietf.org>; Thu, 25 Aug 2011 23:11:51 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BACB11022404C; Thu, 25 Aug 2011 23:13:05 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 25 Aug 2011 23:13:05 -0700 (PDT)
Message-ID: <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net>
In-Reply-To: <4E572FD4.4040704@gmail.com>
References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <tslvctm8vu7.fsf@mit.edu> <aec7a052a6bdefd7dbd6651e4979fbd3.squirrel@www.trepanning.net> <tslippm8s7s.fsf@mit.edu> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <tsl39gq8hr3.fsf@mit.edu> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <tslobzd5wsi.fsf@mit.edu> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> <4E572FD4.4040704@gmail.com>
Date: Thu, 25 Aug 2011 23:13:05 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Glen Zorn <glenzorn@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Sam Hartman <hartmans-ietf@mit.edu>, emu@ietf.org
Subject: Re: [Emu] server unauthenticated provisioning mode
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Fri, 26 Aug 2011 06:11:52 -0000

On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote:
> On 8/26/2011 4:22 AM, Dan Harkins wrote:
>
>>> 3) I think MSCHAPv2 is an entirely inappropriate MTI for this
>>> mechanism. I brought that up as an example about how under certain
>>> conditions the fact that something is the kind of thing the IETF
>>> standardizes but is never the less informational should not block a
>>> downward reference. I was attempting to explain my thinking on the
>>> process issue to you, not to suggest MSCHAPv2 for this document.
>>> Apparently I failed to explain my thinking on the process issue.
>>
>>   I completely missed that. Sorry. But if the IETF standardized a
>> wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a
>> shared key)
>
> Please check your sources & refrain from spouting nonsense; if EAP-pwd
> is really so wonderful you shouldn't need to disparage other work, it
> should stand on its own merit.

  I stand corrected. That must be why draft-zorn-emu-team proposed using
MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd.

>> then I really don't understand your opposition to EAP-pwd.
>> MSCHAPv2 became widespread solely due to Windows.
>
> Hardly.  The fact that the IETF was busy a) insisting that there was no,
> and never would be, any need for dynamic key generation (let alone
> mutual authentication) in network access protocols (specifically PPP;
> how could there be, since the only appropriate usage of PPP was to
> connect two routers which can easily be configured with telnet) and b)
> waiting with baited breath for the magical genesis of the universal PKI
> (which would happen because IPsec required it & that hamstrung niche
> protocol was so wonderful that the world would change to satisfy its
> requirements) certainly had a lot to do with it.  MS-CHAPv2 succeeded
> because it satisfied a need that the IETF was simultaneously too
> ignorant and arrogant to see.

  That's great Glen. You accuse me of disparaging other work and then
you go and disparage other work. "Do as I say and not as I do". OK,
I promise.

  Dan.