Re: [saag] Feedback on Salted EAP draft

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