Subject: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 26 Nov 2020 16:32:26 +0000

Russ

Driven by the bitcoin business, highly specialized ASIC speeding up hash calculation are available for a relative cheap price. Therefore, we would propose to further update RFC4211 Section 4.4 as follows.

Add a sentence to the end of the first paragraph of Section 4.4
"The security of this MAC depends heavily on the entropy of the used password. Using one-time passwords also improves the security."

Add an update of the explanation on iterationCount
"iterationCount 
identifies the number of times the hash is applied during the key computation process.  The iterationCount SHOULD be as large as server power allows, typically at least 10.000 iterations (see recommendations in [NIST SP800-63B] section 5.1.1.2)."

Add this paragraph to the Security Considerations:
"The security of the password-based MAC relies on the number of times the hash function is applied and on the entropy of the shared secret (the password) used. As ASICs providing HW support for hash calculation are available for cheap prices, the value of a high iterationCont is limited.  Therefore, the entropy of the used shared secret is crucial for the security of this MAC function. A high entropy can be achieved by using computer generated shared secrets, e.g., a randomly chosen shared secret with 10 characters offers a entropy of  59 bits and with 20 characters offers a entropy of 118 bits, assuming an alphabet of 60 characters. The use of one-time passwords also increases the security of the MAC, assuming that the transaction is completed before the attacker is able to break the shared secret (offline attacks)."

What do you thin?

- Hendrik

Hendrik Brockhaus
Siemens AG

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Nov 2020 12:47:11 -0500

> "The security of this MAC depends heavily on the entropy of the used password. Using one-time passwords also improves the security."

I would prefer to say: "The password for this MAC SHOULD NOT be used for any other purpose."  I think this avoids potential issues with repeated requests.

What do others think?

> identifies the number of times the hash is applied during the key computation process.  The iterationCount SHOULD be as large as server power allows, typically at least 10.000 iterations (see recom…

Good idea.

> "The security of the password-based MAC relies on the number of times the hash function is applied and on the entropy of the shared secret (the password) used. As ASICs providing HW support for has…

This seems like a good addition.

Russ

---

From: Jonathan Hammell <[email-masked]>
Date: Thu, 26 Nov 2020 13:23:36 -0500

Russ, Hendrik:

> I would prefer to say: "The password for this MAC SHOULD NOT be used for any other purpose."  I think this avoids potential issues with repeated requests.

I think Russ's proposal is more clear for implementers.  The proposed
text to add to the Security Considerations discusses the entropy
requirements and suggestion for one-time passwords.

I agree with the other proposed changes from Hendrick.

However, I'm concerned about the ASN.1 for PBMParameter Section 4.4 of
RFC 4211 for the following reasons.  If one wanted to use scrypt (RFC
7914) for the owf, there is duplication of the salt parameter and the
iterationCount in PBMParameter would no longer be relevant.  One might
even want to use Argon2 (draft-irtf-cfrg-argon2), but unfortunately
there is no ASN.1 module in that I-D to specify parameterization.  I
realize that backwards compatibility needs to be maintained for
PBMParameter so those parameters cannot be made OPTIONAL, but perhaps
some guidance like the following should be added?

  "If a salt value is specified in the AlgorithmIdentifier parameters
for owf (such as in [RFC7914]), the salt value in PBMParameter MUST
NOT be used and it SHOULD be the zero-length octet string.  Similarly,
if the mechanism specified in owf has its own cost parameter for
deriving a key (such as in [RFC7914]), then the iterationCount value
in PBMParameter MUST NOT be used and it SHOULD be set to 0."

Jonathan

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Nov 2020 16:26:34 -0500

> in PBMParameter MUST NOT be used and it SHOULD be set to 0."

I do not think I agree.  If you want to use one of these other constructions, wouldn't completely replace id-PasswordBasedMAC?

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 27 Nov 2020 07:11:58 +0000

Russ

> Von: Russ Housley <[email-masked]>
> Gesendet: Donnerstag, 26. November 2020 18:47
> 
> Hendrik:
> 
> > Driven by the bitcoin business, highly specialized ASIC speeding up hash
> calculation are available for a relative cheap price. Therefore, we would
> propose to further update RFC4211 Section 4.4 as follows.
> >
> > Add a sentence to the end of the first paragraph of Section 4.4 "The
> > security of this MAC depends heavily on the entropy of the used password.
> Using one-time passwords also improves the security."
> 
> I would prefer to say: "The password for this MAC SHOULD NOT be used for
> any other purpose."  I think this avoids potential issues with repeated
> requests.
> 
My goal was to make sure that the password is not reused for another activity, including a second enrollment to a later point in time, to thwart offline attacks. Saying ' SHOULD NOT be used for any other purposes' addresses part of the issue better than my wording, but does not express prohibiting the reuse for the same purpose.

Hendrik

---

From: Jonathan Hammell <[email-masked]>
Date: Fri, 27 Nov 2020 12:47:36 -0500

> I do not think I agree.  If you want to use one of these other constructions, wouldn't completely replace id-PasswordBasedMAC?

You would not be able to just replace id-PasswordBasedMAC with
id-scrypt since you need the specification for the MAC construction to
perform the proof of possession.  However, you are right, it might be
best to use a new OID and define a new parameters structure to use a
MAC with one of these alternative PBKDF mechanisms.

Best regards,
Jonathan

---

From: Russ Housley <[email-masked]>
Date: Fri, 27 Nov 2020 15:09:50 -0500

> MAC with one of these alternative PBKDF mechanisms.

It seems like a two page document + boilerplate.

Russ