From nobody Thu Aug 13 14:35:59 2015 Return-Path: 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 986BD1B3B39; Thu, 13 Aug 2015 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 iFJBpzL3pHiU; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 856DA1B39D3; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1FE881022400A; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Message-ID: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 13 Aug 2015 14:35:55 -0700 (PDT) From: "Dan Harkins" To: "Christian Huitema" 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: Cc: Sam Hartman , "saag@ietf.org" , "emu@ietf.org" Subject: Re: [Emu] [saag] Feedback on Salted EAP draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 21:35:56 -0000 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. From nobody Sun Aug 16 21:33:21 2015 Return-Path: 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 C42C61A039A for ; Sun, 16 Aug 2015 21:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 nHeP83VW9wW9 for ; Sun, 16 Aug 2015 21:33:18 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78311A0390 for ; Sun, 16 Aug 2015 21:33:17 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so74472825lbb.0 for ; Sun, 16 Aug 2015 21:33:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WdOi5+tEa6h/Je+EHrTpwErIniwYnhMBMR2mVfMD300=; b=Dv1vqkreF5ZXhc+ztC2btolx3H++ejgawyu8c89je5PRleV0zCCK1wTYRfSRxR4yWU AOnypOk3Gq3sR4GITfaQEhpBrruO/FRv2JP889mWCu1u+AOGtGhNyNvcVn+N3u1RHeSm DoYbG5r22VhcW9YMW1Q8FeYHclKX0rJp1IHW+mMp2ka9wWGWpx/rOvVtpo1NRVsdj0uu jkGuyc1faylfpNGi0YKz5RsXmdq55NBiBIANcvHpQwxZDjXVry4hVjEFPNLjCSCt5lO1 m+7gjKkz6pk+Rk+dDqZAp8uBEiqFnXbGV7gpqoyhG/FyZFd8KbG/R1D/BU+dsVSJFK2X kP4A== X-Gm-Message-State: ALoCoQldEK4iYixVJE90LSIUe5DTZG1kDuD/EQT5H2bUKhBCxwhHRr2HVjupq19wISaTOUrCW6py MIME-Version: 1.0 X-Received: by 10.112.142.196 with SMTP id ry4mr54085692lbb.68.1439785996265; Sun, 16 Aug 2015 21:33:16 -0700 (PDT) Received: by 10.112.122.17 with HTTP; Sun, 16 Aug 2015 21:33:16 -0700 (PDT) In-Reply-To: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> References: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> Date: Sun, 16 Aug 2015 21:33:16 -0700 Message-ID: From: Joseph Salowey To: Dan Harkins Content-Type: multipart/alternative; boundary=089e0112bf7edc4370051d7a4ce2 Archived-At: Cc: Christian Huitema , Sam Hartman , "saag@ietf.org" , "emu@ietf.org" Subject: Re: [Emu] [saag] Feedback on Salted EAP draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 04:33:19 -0000 --089e0112bf7edc4370051d7a4ce2 Content-Type: text/plain; charset=UTF-8 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. 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? Thanks, Joe On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins 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 > --089e0112bf7edc4370051d7a4ce2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan,

I read the latest version of th= e draft (-02) and it looks mostly good to me. =C2=A0 some comments:

I think you want to change the RFC references in the abst= ract from RFC 2751 to RFC 2759. =C2=A0

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

Thanks,
<= br>
Joe

On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins = <dharkins@loung= e.org> wrote:

=C2=A0 Hi Christian,

On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
[snip]
> The draft is short and clear enough, but it acknowled= ges a pretty big
> security issue: "the salted
> password from a compromised database can be used directly to impersona= te
> 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 ov= er
> operating with unsalted passwords. The draft aligns server side passwo= rd
> management for EAP-pwd=C2=A0 with standard industry practices, which i= s good.
> In case of server compromise, the immediate effect of the compromise i= s an
> attack on the already compromised server, and the per-user salt make > password discovery harder. The security section should be expanded to<= br> > explain this tradeoff.

=C2=A0 Yes, it's a big caveat and, as I mentioned, I'm tryin= g 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?) in= clude support for
> salted passwords."

=C2=A0 Nice catch.

=C2=A0 An -02 version has been posted. Would you please take a look
and let me know whether it satisfactorily addresses your comments?

=C2=A0 regards,

=C2=A0 Dan.


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--089e0112bf7edc4370051d7a4ce2-- From nobody Mon Aug 24 09:58:24 2015 Return-Path: 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 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: In-Reply-To: References: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> Date: Mon, 24 Aug 2015 09:58:18 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey" 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: Cc: "saag@ietf.org" , "emu@ietf.org" Subject: Re: [Emu] [saag] Feedback on Salted EAP draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 >> >