Re: [Emu] salted EAP-pwd
"Jim Schaad" <ietf@augustcellars.com> Wed, 01 October 2014 00:16 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97D01A8A82 for <emu@ietfa.amsl.com>; Tue, 30 Sep 2014 17:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVi3PK1vChnW for <emu@ietfa.amsl.com>; Tue, 30 Sep 2014 17:16:25 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27DE1ACD2C for <emu@ietf.org>; Tue, 30 Sep 2014 17:16:25 -0700 (PDT)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 3B61A38F6D; Tue, 30 Sep 2014 17:16:25 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Dan Harkins' <dharkins@lounge.org>
References: <e000123dbf6d5c42568d26464ed55a08.squirrel@www.trepanning.net> <0e3a01cfdcf3$cdca13d0$695e3b70$@augustcellars.com> <dc89a9b829a387162e216e7170678a35.squirrel@www.trepanning.net>
In-Reply-To: <dc89a9b829a387162e216e7170678a35.squirrel@www.trepanning.net>
Date: Tue, 30 Sep 2014 17:13:57 -0700
Message-ID: <0e7a01cfdd0c$980c9060$c825b120$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJrPpFfgr3g/sqefUjDnX1/AEi66wLbbiWIAmGGW/eaubK+IA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/emu/fxt5P0DTLgEaPeIWVJUbL3ZrevA
Cc: emu@ietf.org
Subject: Re: [Emu] salted EAP-pwd
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 01 Oct 2014 00:16:27 -0000
-----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Tuesday, September 30, 2014 4:25 PM To: Jim Schaad Cc: emu@ietf.org Subject: RE: [Emu] salted EAP-pwd Hi Jim, On Tue, September 30, 2014 2:16 pm, Jim Schaad wrote: > I can see two problems right off the bat. > > 1. It does not allow me to use a different salted method for > different people so I can upgrade by salt function piecemeal. Sure it does. The EAP-Identity/Response from the client will indicate the identity, the server looks up that identity in the password database, sees how it's salted and responds appropriately. One entry in the database could be SHA-1 and another could be SHA-256. [JLS] Ok - so if I understand this correctly. Server sends a message saying <EAP-PW, name="server", preprocess="SHA-256", Cipher="foo"> to the client Client returns a message saying <EAP-PW, name="dan", preprocess="SHA-256", cipher="foo"> to the server. Server looks up dan and says - ouch - that should have been SHA-1 because that password is not upgraded yet. --- I based this comment on the first paragraph of section 2.4 which says: Like all EAP methods, EAP-pwd is server initiated. The server is required to indicate its intentions, including the password pre- processing it wishes to use, before it knows the identity of the client. Thus if the pre-processing is client identity based it would not know this. You might be able to get around this if the client identity in the EAP-Identity message is what is used for the lookup in the database and not the string sent in the EAP-pwd-ID/response. > 2. It does not allow me to do both SASLprep and salting on the same > password. Yes, I see that might be needed if SASLprep was done on the password before it was salted and stored. Given that SASLprep is already a password pre-processing technique (and it is the value 0x02 while "none" is 0x00 preventing the distinction being a low-order bit) I see no choice but to double all the proposed salting indicators, one for SASLprep before the hashing and one for do nothing to the password before hashing. Would that be satisfactory to you? [JLS] It would solve the immediate problem. I don't really care for it as a solution though. regards, Dan. > Jim > > > -----Original Message----- > From: Emu [mailto:emu-bounces@ietf.org] On Behalf Of Dan Harkins > Sent: Tuesday, September 30, 2014 12:02 PM > To: emu@ietf.org > Subject: [Emu] salted EAP-pwd > > > Hello EMU, > > I've had requests to add support for salted password databases to > EAP-pwd. > A newly posted draft does just that: > > http://tools.ietf.org/html/draft-harkins-salted-eap-pwd-00 > > Please take a look and comment. > > regards, > > Dan. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > >
- [Emu] salted EAP-pwd Dan Harkins
- Re: [Emu] salted EAP-pwd Jim Schaad
- Re: [Emu] salted EAP-pwd Dan Harkins
- Re: [Emu] salted EAP-pwd Jim Schaad
- Re: [Emu] salted EAP-pwd Dan Harkins