Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00

From: Ludovic BOCQUET <[email-masked]>
Date: Thu, 29 Oct 2020 22:48:48 +0000

Hello all,

I have done comments a long time ago about the previous draft-whited-kitten-password-storage but my changes are not here, the author has maybe forgotten it.

There are some problems here:

  *   SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
  *   SCRAM-SHA-1, SCRAM-SHA-256

It must be:

  *   SCRAM-SHA-256-PLUS, SCRAM-SHA-256
  *   SCRAM-SHA-1-PLUS, SCRAM-SHA-1

Source: RFC8600: https://tools.ietf.org/html/rfc8600

  *   "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802])"

In the same time, I think that we must to add two new official SCRAM drafts of the same author of SCRAM:

Currently SCRAM-SHA-512-PLUS and SCRAM-SHA-512 are missing:
- https://tools.ietf.org/html/draft-melnikov-scram-sha-512

Currently SCRAM-SHA3-512-PLUS and SCRAM-SHA3-512 are missing:
- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

We can have:

  *   EXTERNAL
  *   SCRAM-SHA3-512-PLUS, SCRAM-SHA3-512
  *   SCRAM-SHA-512-PLUS, SCRAM-SHA-512
  *   SCRAM-SHA-256-PLUS, SCRAM-SHA-256
  *   SCRAM-SHA-1-PLUS, SCRAM-SHA-1
  *   PLAIN
  *   DIGEST-MD5, CRAM-MD5

Explanation:

  *   EXTERNAL
  *   SCRAM-SHA3-512-PLUS, SCRAM-SHA3-512 (my request based on RFC8600: from the best to the worst)
  *   SCRAM-SHA-512-PLUS, SCRAM-SHA-512 (my request based on RFC8600: from the best to the worst)
  *   SCRAM-SHA-256-PLUS, SCRAM-SHA-256 (my request based on RFC8600: from the best to the worst)
  *   SCRAM-SHA-1-PLUS, SCRAM-SHA-1 (my request based on RFC8600: from the best to the worst)
  *   PLAIN
  *   DIGEST-MD5, CRAM-MD5 (2 bad already with good order: from the best to the worst)

If you do not respect the RFC8600, it must be:

  *   EXTERNAL
  *   SCRAM-SHA3-512-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS
  *   SCRAM-SHA3-512, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1
  *   PLAIN
  *   DIGEST-MD5, CRAM-MD5

Explanation:

  *   EXTERNAL
  *   SCRAM-SHA3-512-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS (good order: from the best to the worst)
  *   SCRAM-SHA3-512, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1 (good order: from the best to the worst)
  *   PLAIN
  *   DIGEST-MD5, CRAM-MD5 (2 bad already with good order: from the best to the worst)

Thanks in advance.

Regards,

BOCQUET Ludovic

________________________________
From: Kitten <[email-masked]> on behalf of Robbie Harwood <[email-masked]>
Sent: Tuesday, September 22, 2020 4:59 PM
To: Jim Fenton <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00

Jim Fenton <[email-masked]> writes:

> Hi,
>
> I'm not generally up to speed on the work of the kitten WG, but someone
> pointed out this draft and thought I'd be interested, and I am. Please
> bear that in mind if some of my suggestions conflict with GSS-API,
> Kerberos, etc. And I'm not familiar with the various SASL mechanisms so
> don't have any comments on them.

Hi Jim, thanks for taking a look.

Sam, have you had a chance to take a look at the review?

Thanks,
--Robbie

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 29 Oct 2020 20:40:23 -0400

Hi Ludovic,

On Thu, Oct 29, 2020, at 18:48, Ludovic BOCQUET wrote:
>  * "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS
>    variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-
>    256 variants [RFC7677] SHOULD be preferred over SHA-1 variants
>    [RFC5802])"

I disagree with the RFC on this regard, but if further evidence can be
provided I'm all ears. There are no known pre-image attacks against SHA-
1, and the weaknesses I'm aware of at least won't matter for SCRAM since
SHA-1 is only used in the HMAC so to me it seems preferable to encourage
channel binding first, and the specific hash second. That being said,
channel binding isn't actually very useful right now since there's no
way to negotiate it and the existing methods are insecure without the
TLS master secret fix, so maybe it doesn't matter either way.

I am certainly not an expert and will bow to expert opinion if consensus
is against me, so I'd love more feedback on this.

> - https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

I'm keeping an eye on those and am very excited to see them coming
along! I'd prefer that they go through expert review first though
before adding them to this document (although I do think it's
appropriate to do so since they're both just I-Ds right now, so I don't
feel strongly about this). I wouldn't want this document to go to RFC
and still be referencing those I-Ds, but I don't know what the IETF
position on this is; either way it seems worth waiting and keeping an
eye on them for now.

Thanks for your feedback!

—Sam

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 29 Oct 2020 21:44:58 -0400

Hi Jim et al,

Thanks for your reviews, I have published version 01 of the I-D which I
believe captures all of your feedback.

Thanks again,
Sam

On Fri, Sep 4, 2020, at 20:53, Jim Fenton wrote:
> Hi,
>
> I'm not generally up to speed on the work of the kitten WG, but
> someone pointed out this draft and thought I'd be interested, and I
> am. Please bear that in mind if some of my suggestions conflict with
> GSS-API, Kerberos, etc. And I'm not familiar with the various SASL
> mechanisms so don't have any comments on them.
>
> 1.1 Terminology
>
> Since the term "salt" is so widely used in this document, it would be
> good to reference a specific definition, since RFC 4949, SP 800-132,
> and SP 800-63-3 all have different definitions.
>
> For "pepper", does "not unique" mean that there is one pepper value
> for the entire database that is stored separately? This would be OK if
> the database is salted as well (need to de-duplicate cases where
> different users have the same password).
>
> 3.1 Mechanisms
>
> The end of paragraph 4 talks about providing a strong authenticator
> assurance level. In NIST SP 800-63B, authenticator assurance level is
> a categorization of authentication transactions (1-3), and single-
> factor authentication such as a password is only ever AAL1 regardless
> of how it's done. I suggest a different term be used here.
>
> 4.1 SASL requirements
>
> Hashes that are unsuitable for use with authenticators such as SHA256:
> Should explain what makes them unsuitable. I gather that's because
> SHA256 is too fast, especially with all the stuff developed for
> cryptocurrency mining. But really all hashes are too fast to be used
> alone; they need to be used iteratively or as part of a key derivation
> function that is hopefully time- and memory-hard.
>
> 4.2 Storage
>
> Salts don't really need to be random; they just need to be unique, and
> long enough to make it impractical to construct a rainbow table. "If
> it is stored": the salt, I assume? Please be specific. The pepper
> value should be stored at arm's length from everything else, such as
> in an HSM or otherwise separate place (example:
> https://github.com/jimfenton/rehash ). Storing the pepper in an
> environment variable seems like a really bad idea to me.
>
> As I mentioned above, a minimum salt length of 16 bytes seems
> excessive. NIST SP 800-63B requires 32 bits. Similarly, 32 bytes for
> the pepper is more than is really needed; SP 800-63B calls for 112
> bits (but calls it a "salt" which is confusing).
>
> 4.3 Authentication and rotation
>
> Paragraph 2, "iteration count" - some algorithms refer to this as a
> work factor so suggest "iteration count or work factor".
>
> Paragraph 3, Pepper rotation: In cases where the password is salted
> and iteratively hashed, and then a keyed hash with the pepper value is
> performed after that, it has been suggested that the keyed hash could
> be replaced by a keyed encryption, which has the advantage of allowing
> the key to be rotated by sending the verifier values to the peppering
> process, which could decrypt the verifiers with the old key and
> reencrypt with the new key. This makes a lot of sense; encryption
> isn't really a problem here because there isn't a practical brute
> force threat.
>
> 6. Password complexity
>
> Replace blacklist with blocklist, denylist, or something else
> of course.
>
> "(when paired with the same email or other uniquely identifying
> information)" - This would only result in denial of use of a password
> if it was used by the same account, when really we want to deny the
> use of things like passw0rd entirely. So just compare against the list
> without identifying information (which you don't want to have anyway).
> I'd leave out the part about commonly used patterns -- that leads down
> a slippery slope to the complex composition rules we have today, when
> really we just want to make sure common passwords aren't used. So if
> "aaaaaaaa" is considered a common password, just put it on the
> blocklist.
>
> I'm happy to discuss any of this further. Thanks for putting together
> this draft.
>
> -Jim
>
>
>

-- 
Sam Whited