Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06

Dan Harkins <> Mon, 10 October 2016 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FEE612952B; Mon, 10 Oct 2016 08:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pq4VNNM4cA9i; Mon, 10 Oct 2016 08:58:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D95F2129488; Mon, 10 Oct 2016 08:58:06 -0700 (PDT)
Received: from thinny.local ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5E6881022400A; Mon, 10 Oct 2016 08:58:06 -0700 (PDT)
To: Simon Josefsson <>, Stefan Winter <>
References: <> <> <> <> <> <> <> <>
From: Dan Harkins <>
Message-ID: <>
Date: Mon, 10 Oct 2016 08:58:04 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc:, Kathleen Moriarty <>, "" <>
Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Oct 2016 15:58:08 -0000


On 10/10/16 12:18 AM, Simon Josefsson wrote:
> mån 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter:
>> Hello,
>>> I still believe it is a bad idea to describe non-iterative password
>>> protection schemes at all.  We have had 15+ years of bad incidents with
>>> salted password databases that suggest it is time to stop doing that.
>> This is not the ocean this draft attempts to boil.
>> The draft does not make any recommendations about how to store passwords.
> Hello Stefan.
> Recommendations ought to be part of the security considerations.  It
> already is part of the document, to some extent.
>> It attempts to make password databases usable with a new EAP type.
>> I don't think you are actually stating that salt-hash databases don't
>> exist in massive amounts in deployed reality? Because saying so would be
>> quite silly; they do exist.
> Of course.  I did not say that, and if you got that impression, I must
> have been terribly unclear in what I wrote.
> I question whether deployed PRECIS/OpaqueString databases prepared
> passwords salted+hashed with SHA1 exists.  PRECIS/OpaqueString is fairly
> new.  My perception is that people who are knowledgeable enough to use
> PRECIS/OpaqueString to prepare passwords in general also know that
> salting passwords is not sufficient.

   But the draft doesn't specify OpaqueString with SHA1.

>> If we were to ignore that deployed reality and spec the draft merely
>> around PBKDF2 and some, we'd have an EAP type supporting only a tiny
>> fraction of password databases out there. All the rest of deployed
>> reality is left without a good zero-knowledge EAP type and is remains
>> stranded with "traditional" PKIX-style server validations with either a
>> cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as
>> our experience in a world-scale EAP-based roaming consortium shows,
>> means: no protection at all for many because end users ignore all
>> certificate warnings given half a chance to.
>> It is actually quite easy to improve security for virtually everybody
>> using EAP: it's these few paragraphs in the draft which describe how to
>> use salted databases.
> I'm with you on the high-level discussion.  So let's discuss details.
> My assertions are:
> 1) Drafts dealing with password hashing should not ignore security
> practices around password hashing.  Supporting PBKDF2 is a hygiene
> factor, scrypt gives bonus points.

It does support PBKDF2 now. Yes, it does so under the guise of scrypt
because the scrypt RFC indicates that as an option. Adding support for
the other scrypt options would open up this draft to ugly negotiation.
I can get away with crypt() doing a myriad of stuff under the covers
because it embeds the specific algorithm in the salt and all I need
to do is say do crypt().

   So does this draft not already pass the hygiene test and also get
a single bonus point?

> 2) Complexity leads to reduced security.  Is there legacy justification
> for all variants of hashes specified in the document?  Is there legacy
> justification for both SASLprep and PRECIS/OpaqueString?

   I believe the answer to the first question is yes. That is the motivation
for this draft. Regarding the second question, there is no legacy
justification for OpaqueString but there is one for SASLprep, that's
whey there's an option for SASLprep with SHA-1 but none for OpaqueString
with SHA-1.
> 3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed
> in a salted+hashed way but without iterative constructs.  If you have
> pointers to the opposite, for each of the specified hashes, I'm happy to
> learn something new.

   I have no pointers but if that is your challenge that you should be
happy that the draft supports OpaqueString-prepared passwords with
SHA-256 and SHA-512-- i.e. no iterative constructs. It also supports
OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-512
so we should have all bases covered.
> What do you think?
> I'm aware of password databases that use raw salt+hash on (unprepared)
> UTF-8 encoded password strings.  In my experience, that is more common
> than salt+hash of SASLprep or PRECIS/OpaqueString passwords.  The draft
> does not discuss how the password is encoded for TBD1-TBD10, which seems
> like another missing piece.

It says:
   When using SASLprep a password SHALL be considered a "stored string" per
   [RFC3454] and unassigned code points are therefore prohibited. The
   output of SASLprep SHALL be the binary representation of the
   processed UTF-8 character string.  Prohibted output and unassigned
   codepoints encountered in SASLprep pre-processing SHALL cause a
   failure of pre-processing, and the output SHALL NOT be used with EAP-pwd.

For the non-internationalized EAP-pwd already says:
   The input password string SHALL be treated as an ASCII
   string or a hexadecimal string with no treatment or normalization
   performed.  The output SHALL be the binary representation of the
   input string.

   I'm really not sure what changes are still needed in this draft. If
there are, please tell me again.