Subject: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening

From: Yutaka OIWA <[email-masked]>
Date: Thu, 6 Mar 2014 01:46:56 +0900

Following the discussion in the HTTPAUTH WG sessions in
several previous meeting,
I believe it is a good thing to introduce a password hardening
into the current MutualAuth draft.
I'd like to incorporate the following changes to the
next revision of the WG document.
# I've talked with chairs Monday about how to make a
# significant changes to the document in WG status,
# and this is how we're suggested to try.

If you think we should do something different,
or if you have a suggestion for the open issues
described below, please let me know.
I really want to have suggestions from
cryptography people for some security parameters.

I'll work on the revisions within a few weeks.

The following is the proposed text for the update:

In Section 11.2 (Default Functions for Algorithms),

---OLD---
   pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username)
   | VS(ph(password)))).
---
will be replaced with
---NEW---
   pi = INT(PBKDF2(HMAC-H,
                   ph(password),
                   VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username),
                   2048, dkLen))

   where

     o HMAC-H be the HMAC function [RFC2104] composed from the hash
function H, and
     o dkLen shall be the length of hash H, counted in octets.
---

The open issues for the above change are:

 * Which function, possibly other than PBKDF2, will be the best
   choice for the hardened password hash function?
   I currently chose PBKDF2 just because there is an RFC.

 * What number of iterations are to be used?
    Fixing it to 2048 makes sense?  Or it should be a security parameter?

 * What is the best value for dkLen?
   It is an output length of the hardened password hash in octets.

   Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used.
   The above definition lead to the value 256/8 = 32.
   It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256).
   The cryptographically best values are either 2046/8, or
   more precisely some irrational number 2046.99999..../8 (*), but
   to achieve it, we need to modify/update PBKDF2 itself.
   (*) 2046.99999... is log_2 r, where r is a number of mathmatically
   possible elements (size of the generated group) for the passwords-equivalent.

Thanks in advance.

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Chris Newman <[email-masked]>
Date: Wed, 05 Mar 2014 17:30:44 +0000

--On March 6, 2014 1:46:56 +0900 Yutaka OIWA <[email-masked]> wrote:
>                    VS(algorithm) | VS(auth-domain) | VS(realm) |
> VS(username),                    2048, dkLen))
>
>    where
>

That's also what SCRAM (RFC 5802) choose and that change was recommended to 
the SCRAM editors by security folks as it was done in a security WG. So I 
have reason to believe PBKDF2 is the right choice for this purpose until I 
hear otherwise from the security community.

>  * What number of iterations are to be used?

SCRAM used 4096 as minimum iteration count several years ago. I suspect it 
should be higher now.

>     Fixing it to 2048 makes sense?

No, that can't adapt to advancements in computing power.

>  Or it should be a security parameter?

That's what SCRAM did.

>    It is an output length of the hardened password hash in octets.

Shouldn't it be the size of the base hash function output?

>    to achieve it, we need to modify/update PBKDF2 itself.

Please do not modify PBKDF2. Security primitives should be reused as-is for 
their primary purpose unless there's a really really good reason to develop 
something new and start the security analysis all over again. The reason 
has to be good enough to attract attention of security researchers.

		- Chris

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 6 Mar 2014 02:53:59 +0900

Chris, thank you very much.

Iteration counts and function choices:

Really valuable input for the iteration count, thanks.
I will raise that number and make it a security parameter in some way.

Additional question: If possible, I want to have it fixed with
each "ciphersuites" we're defining, expecting that
if we need to raise that iteration number,
we also need to strengthen the hash itself.
Do you have some thoughts about relation of those?
Is it difficult to forecast these relations?
# While writing this, I feel it's difficult...

Output length of PBKDF2:

Thank you very much, too.  It's also very valuable information for me.
I completely agree with your view on the security primitives modification.
I actually want to make sure that such modification is not required
(to make sure there is not "a really really good reason") around my use case.
# I am putting the output to a field of large prime size (2^2046.99999...),
# so it's a bit strange use case compared to the usual use cases of PBKDF2.

Thank you again for your comments!

2014-03-06 2:30 GMT+09:00 Chris Newman <[email-masked]>:
> something new and start the security analysis all over again. The reason has
> to be good enough to attract attention of security researchers.
>
>                 - Chris
>

---

From: Tim <[email-masked]>
Date: Wed, 5 Mar 2014 09:57:06 -0800

>    I currently chose PBKDF2 just because there is an RFC.

I'm currently fond of scrypt, since it can be made memory-hard in
addition to computationally hard.  There was an attempt to standardize
it, but it appears the draft has expired:
  https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-01

I believe scrypt is used as the work-factor function in several
crypto-currencies, so it certainly does receive some scrutiny,
security-wise. I'm not sure how difficult it would be to integrate
this into your protocol...

tim

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 6 Mar 2014 04:14:01 +0900

Dear Tim,

Thank you very much for the information.
It's very interesting.  I'll read the paper and
how it can be used for benefit on our proposal...

# long-while expiring draft is an issue, indeed...
# to use it, someone should take care of that.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Mar 2014 12:23:38 +0200

> into the current MutualAuth draft.

I actually had the same idea (but didn't post it to the list).

>    I currently chose PBKDF2 just because there is an RFC.

Basically, there are two kinds of "slow" password derivation:
- Ones that burns CPU.
- Ones that burn both CPU and memory.

The latter are meant as anti-GPU, as otherwise one can use GPUs for
high-performance password cracking.

Unfortunately, while using fair amount of memory previously made GPU
performance really fall off the cliff, that doesn't really happen anymore,
but it still limits paralelism on GPU nicely.

I think someone mentioned scrypt (or was it bcrypt)? Those both are
well-known memory-burning password stretching functions. I don't
think either has an RFC.

>     Fixing it to 2048 makes sense?  Or it should be a security parameter?

As someone else said, 2048 for PBKDF2 is vastly insufficient (but for
some other algorithms, iterations may be vastly more expensive).

I would guess that the iteration counts for PBKDF2 nowadays would be in
hundreds of thoursands or even millions. But that's just guessing
(I have done some homebrew password stretching functions, those have
iteration counts in millions).

>    possible elements (size of the generated group) for the passwords-equivalent.

On the last point, if one wanted to hash to group order, the standard method
is to generate slightly larger number of bits (NIST says at least 64, I would
say at least 100), interpret the number as integer and then take modulo r.
(or modulo (r - 1) + 1)

This tends to be bit slow with larger groups, especially if the order is not
near-power-of-two (IIRC, NIST P-224, NIST P-521, all E-series and all M-series
elliptic curves do, NIST P-256 and P-384 don't).

I think there was some RFC that described how to use hash function to stretch
input...

I don't know if hashing to group order is needed or not. I know SRP does
not do it, it just takes 256 (or whatever) bit hash function value and uses
that as an exponent.

-Ilari

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 7 Mar 2014 21:12:47 +0900

Dear Ilari,

thank you very much for the really valuable comment.

For the iteration numbers:

Hmm, very insightful, really.
I feel that we need some compromise around there,
as introduction of this is just a mitigation and
also an additional caution measure.
In other words, we're not strongly depending on the
hash strength of password for the whole security.
One million of iterations sounds a bit too many for me, I feel.
I will also compare it with the computation time needed for
modular/EC-field exponentiation, which is also
needed for reversing the server-stolen password tokens.

Scrypt is also mentioned by another people, and
is very interesting for me. I'm reading the paper for that now.
However, to use it we see some hurdles ahead of us,
provided that pbkdf is available as RFC now and is well verified.
Choosing a good security parameter seems to be important
to get benefit from it, too.
My current feeling for this is that one possibility might be
to start a study about next standards for general password
strengthening including scrypt, possibly with other area's people as well.
Once it is accepted, we may add it as a new "ciphersuite".
If more people are interested to do it starting now, it's interesting for me.

Hash lengths:

I think situation is exactly the same as SRP
(In other words, we only accept cryptographic primitives which has the
same properties).
So, your comment pushes me from the behind
to take just a 256-bit value as a password-equivalent.
Thank you very much.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Mar 2014 20:07:23 +0200

> hash strength of password for the whole security.

For me, this kind of strenghening only makes sense for
schemes secure against active attacks.

> needed for reversing the server-stolen password tokens.

At least when comparing fast EC curves (~256-bit) with targets
I tune password stretching functions to (and I have heard some
using even slower targets), EC curves are faster by multiple
orders of magitude.

-Ilari