Subject: [saag] Key-Derivation Scheme

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 4 May 2014 08:16:54 -0400

Hi,

There are few protocols (e.g. HTTP, SIP, OAuth, and STUN) that use a
challenge-response mechanism to authenticate users.
These protocols typically use Basic or Digest schemes, which have many
limitations as described RFC2617.

This email and the attached draft is to discuss the idea of creating a new
scheme, Key-Derivation Authentication Scheme, to be used with the
challenge-response mechanism.

The scheme is based on the following NIST document:
"NIST Special Publication 800-132 - Recommendations for Password-Based Key
Derivations", December 2010.
http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf

The scheme ensures that the password and the master-key are never sent on
the wire, and allows for a better secure storage of passwords as it
significantly increases the amount of computation needed to derive a key
from a password in a dictionary attack.

Any comments on the idea, described in the attached document, would be
greatly appreciated.

Regards,
 Rifaat

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 4 May 2014 16:28:43 +0000

> Any comments on the idea, described in the attached document, would be

Why is this the right forum for discussion of the new scheme, rather
than a cryptography mailing list?

As for feedback:

    * This is subject to replay attacks.

    * This does not authenticate the server to the client.

    * Undetected disclosure of the server's master database makes it
      possible to authenticate to the server as any user, which is not the
      case when the server stores password hashes, and the users
      send passwords (the primary use-case in the cited standard).

    * This seems unlikely to get much traction.

-- 
	Viktor.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 4 May 2014 12:47:07 -0400

Hi Viktor,

Thanks for your comments. Please see my reply inline...

Regards,
 Rifaat

On Sun, May 4, 2014 at 12:28 PM, Viktor Dukhovni
<[email-masked]>wrote:

> I am not sure of the best list to discuss this, and I was told to start
here.
The draft is *not* introducing any new crypto algorithms.

> This is mitigated by the number of iterations that server chooses to use
to create the user's master-key.

> It was not meant to authenticate the server.

> I am not sure I understand this comment; can you please elaborate?

Thanks,
 Rifaat

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 5 May 2014 13:18:43 -0400

Viktor,

> On Sun, May 4, 2014 at 12:28 PM, Viktor Dukhovni <[email-masked]
> > wrote:
>
>>
>>
The protocols require the server to store H(A1) in the case of Digest,
which is a hash of username:real:password.
If the database is compromise, then the server will have the same problem.
Is that what you are talking about here?

Regards,
 Rifaat

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 5 May 2014 18:31:55 +0000

> Is that what you are talking about here?

I don't believe this is the right forum for dissecting novel
cryptography.  While I piggy-backed some observations about the
proposal in my initial response, they were not in invitation to
continue the discussion.

-- 
	Viktor.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 5 May 2014 14:45:13 -0400

What is the right forum?

Regards,
 Rifaat

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 15:11:47 -0500

> proposal in my initial response, they were not in invitation to

Is there novel cryptography here?  The referenced NIST publication
refers to PKCS#5, which is in widespread use in Internet protocols.
It is not novel.

My response to the proposed I-D is that we already have protocols
making use of PBKDF2, such as SCRAM (RFC5802).  Any new proposals in
this space should take existing protocols into consideration.

Also, we *do* need novel PBKDFs, like scrypt.  Those should first be
discussed in CFRG ([email-masked]).

Nico
--

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 5 May 2014 16:30:26 -0400

Hi Nico,

Thanks for you comments.
As I mentioned in a previous email, "The draft is *not* introducing any new
crypto algorithms.", so I agree with you that there is no novel
cryptography here.
I will take a look at the SCRAM document.

I will also take a look at scrypt.
I have looked at J-PAKE as a possible protocol that could fit into a
challenge-response framework.
When I have some text around these I will try to discuss them on the CFRG
mailing list.

How about this draft? where should this be discussed?

Regards,
 Rifaat

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 6 May 2014 10:34:23 -0700 (PDT)

> challenge-response framework.

  The NIST document says:

    "The scheme ensures that the password and the master-key are
      never sent on the wire, and allows for a better secure storage of
      passwords as it significantly increases the amount of computation
      needed to derive a key from a password in a dictionary attack."

So it merely increases the amount of computation needed to perform
a dictionary attack, it does not prevent a dictionary attack. It's much
better to actually prevent  a dictionary attack and any PAKE protocol
would do that for you.

  Dan.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 6 May 2014 16:32:16 -0400

Hi Dan,

The NIST document talks about the latter part of the quote (the increase of
computation).

I guess that the result would depend on the number of iterations selected
by the server.
If the solution can tolerate some delay in the initial communication
between the client and the sever, then the server can select an iteration
number that would practically prevent a dictionary attack.

I agree with you that PAKE-based solution would be better, but these
solutions will either require some changes to the challenge-response
framework, or will not fit into the challenge-response framework.
I am looking at J-PAKE; will see if that fits into the challenge-response
framework.

Regards,
 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 14 May 2014 08:53:15 -0400

Hi,

I sent two emails to the CFRG mailing list to continue this discussion.

The first email to discuss the idea of PAKE-based solution:
http://www.ietf.org/mail-archive/web/cfrg/current/msg04523.html

The second email to continue the Key-Derivation Scheme idea using the
Scrypt function and performing mutual authentication:
http://www.ietf.org/mail-archive/web/cfrg/current/msg04536.html

I would appreciate any comments on these emails on the CFRG mailing list.

Regards,
 Rifaat

On Tue, May 6, 2014 at 4:32 PM, Rifaat Shekh-Yusef <[email-masked]>wrote:

> Hi Dan,
>
> The NIST document talks about the latter part of the quote (the increase
> of computation).
>