Re: [saag] Feedback on Salted EAP draft

"Dan Harkins" <dharkins@lounge.org> Mon, 24 August 2015 16:58 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA9D1A8A09; Mon, 24 Aug 2015 09:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.167
X-Spam-Level:
X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] 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 j4D9zsrvft2P; Mon, 24 Aug 2015 09:58:20 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id ED1B71A8968; Mon, 24 Aug 2015 09:58:18 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A232A10224008; Mon, 24 Aug 2015 09:58:18 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 Aug 2015 09:58:18 -0700 (PDT)
Message-ID: <fc2127e5b25631c1082268d5ebc88d09.squirrel@www.trepanning.net>
In-Reply-To: <CAOgPGoB_EEZEi0_SsFyq2jWkWvb7TM9tSN40UO52DGjH42YkLw@mail.gmail.com>
References: <CAHbuEH5u=Q_h4L4yNdrpPw1J3fAsr1MfEMBV84TgdnHVWcxX0w@mail.gmail.com> <CAHbuEH4--TP0duM-8GSaR4RaUG5DoL=QtnCFE3shHbaUNPvwVg@mail.gmail.com> <tsloane9wff.fsf@mit.edu> <CAHbuEH5cGW3pknnwseEnp=mqzrMLPFBh-bN4pd2wKKDgpS08wQ@mail.gmail.com> <DM2PR0301MB06558BFBD0251595A3B4B0B9A89B0@DM2PR0301MB0655.namprd03.prod.outlook.com> <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> <CAOgPGoB_EEZEi0_SsFyq2jWkWvb7TM9tSN40UO52DGjH42YkLw@mail.gmail.com>
Date: Mon, 24 Aug 2015 09:58:18 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Joseph Salowey" <joe@salowey.net>
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
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/xgLYHaivT47Buwo2EeP2AFvr-qk>
Cc: "saag@ietf.org" <saag@ietf.org>, "emu@ietf.org" <emu@ietf.org>
Subject: Re: [saag] Feedback on Salted EAP draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2015 16:58:22 -0000

  Hi Joe,

On Sun, August 16, 2015 9:33 pm, Joseph Salowey wrote:
> Hi Dan,
>
> I read the latest version of the draft (-02) and it looks mostly good to
> me.   some comments:
>
> I think you want to change the RFC references in the abstract from RFC
> 2751
> to RFC 2759.

  Yes, good catch! I am not referring to the "Signaled Preemption
Priority Policy Element." :-)

> One question I have is there any reason why you specify the input of the
> hash function as password | salt instead of the other way around?  Is this
> the way it is done in practice?

  I actually asked whether this was how it was done in eduroam and
did not get definitive answer back. When I poked around in the results
of a "how to hash passwords" query there were a few examples that had
code and they did it that way. If you know of a counter example, please
speak up while the cement has yet to dry.

  regards,

  Dan.

> Thanks,
>
> Joe
>
> On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins <dharkins@lounge.org>; wrote:
>
>>
>>   Hi Christian,
>>
>> On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
>> [snip]
>> > The draft is short and clear enough, but it acknowledges a pretty big
>> > security issue: "the salted
>> > password from a compromised database can be used directly to
>> impersonate
>> > the client-- there
>> > is no dictionary attack needed to recover the plaintext password."
>> >
>> > That's a pretty big caveat, but there are still some advantages over
>> > operating with unsalted passwords. The draft aligns server side
>> password
>> > management for EAP-pwd  with standard industry practices, which is
>> good.
>> > In case of server compromise, the immediate effect of the compromise
>> is
>> an
>> > attack on the already compromised server, and the per-user salt make
>> > password discovery harder. The security section should be expanded to
>> > explain this tradeoff.
>>
>>   Yes, it's a big caveat and, as I mentioned, I'm trying to
>> be as blunt as possible about it. I have updated the Security
>> Considerations to include the point you are making about server
>> compromise and the per-user salt still making password recovery
>> harder.
>>
>> > Nits:
>> >
>> > - in the abstract, missing "not" in " but did (not?) include support
>> for
>> > salted passwords."
>>
>>   Nice catch.
>>
>>   An -02 version has been posted. Would you please take a look
>> and let me know whether it satisfactorily addresses your comments?
>>
>>   regards,
>>
>>   Dan.
>>
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>