Subject: Re: [Emu] [saag] Feedback on Salted EAP draft

From: "Dan Harkins" <[email-masked]>
Date: Thu, 13 Aug 2015 14:35:55 -0700 (PDT)

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: Joseph Salowey <[email-masked]>
Date: Sun, 16 Aug 2015 21:33:16 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 24 Aug 2015 09:58:18 -0700 (PDT)

Hi Joe,

> I think you want to change the RFC references in the abstract from RFC

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

> 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.

>> > In case of server compromise, the immediate effect of the compromise
>> is
>> an