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.
- [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Sam Hartman
- Re: [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Sam Hartman
- Re: [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Sam Hartman
- Re: [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Sam Hartman
- Re: [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Glen Zorn
- Re: [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Glen Zorn
- Re: [Emu] server unauthenticated provisioning mode Glen Zorn
- Re: [Emu] server unauthenticated provisioning mode Dan Harkins
- Re: [Emu] server unauthenticated provisioning mode Glen Zorn