Subject: [http-auth] HTTP Digest - HMAC & Salted Hash

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 5 May 2015 19:13:11 -0400

Hi,

During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC
support was suggested by both reviewers.
Also, the STUNbis team asked to add support for salted hash.
Based on the discussion with the ADs it was decided that, if there is
interest, that these two issues be addressed in a separate draft.

Here is an initial proposal for adding HMAC and salted hash support that I
would like to discuss:

Definitions
-----------

H(data) = Hash(data)
KD(secret, data) = HMAC-Hash(secret, data)

A1 Calculation
--------------

If the solution is able to provide only system wide salt, then:
A1 = username:realm:password:salt

If the solution is able to provide a per user salt, then:
A1 = password:realm:salt

Example
-------

Using HMAC-SHA256 and per user salt calculation:

A1 = password:realm:salt
H(A1) = SHA256(password:realm:salt)
Response = KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) = HMAC-SHA256( H(A1),
nonce:nc:cnonce:qop:H(A2) )

Is there any objection to starting a new document to define HMAC and salted
hash support?
Any thoughts about the proposal above?

Thanks,
 Rifaat

---

From: Tim <[email-masked]>
Date: Tue, 5 May 2015 17:26:55 -0700

If you're going to go through the effort of offering a salted hash at
that level, wouldn't make more sense to use a modern one such as one of:
  https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02
  https://www.ietf.org/rfc/rfc2898.txt

(scrypt being preferred)

For more info on the reasoning, see:
  http://chargen.matasano.com/chargen/2015/3/26/enough-with-the-salts-updates-on-secure-password-schemes.html

tim

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 5 May 2015 21:18:17 -0400

This proposal is simple and straightforward, and the change is restricted
to the A1 value, and the H and KD functions.

KDF-based approach is much more involved, and if we are to go that path I
think it would be better to create a new scheme than to overload the Digest
scheme.
In fact, I have a SIP draft that discusses the idea of creating a new
PBKDF2-based scheme:
https://www.ietf.org/archive/id/draft-yusef-sipcore-key-derivation-00.txt

Regards,
 Rifaat

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 14 May 2015 05:27:35 -0600

I am also interested in seeing progress for the work, and I am willing to help.  As co-author of stunbis, I am especially interested to discuss how we can coordinate a shared IANA registry for password hash method between STUN, HTTP and eventually SIP.

Thanks.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Sophie Bremer <[email-masked]>
Date: Mon, 18 May 2015 21:01:36 +0200

Hi Rifaat,

I am interested in implementing the proposal.
Unfortunately this requires a transition over several years, because it includes a completely new generated A1.
Do you expect changes to the new A1s below, or can we start with calculation?

Best Regards,
Sophie

Am 06.05.2015 um 01:13 schrieb Rifaat Shekh-Yusef:

> Hi,
> 
> During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC support was suggested by both reviewers.
> Based on the discussion with the ADs it was decided that, if there is interest, that these two issues be addressed in a separate draft.
> 
> 
> Here is an initial proposal for adding HMAC and salted hash support that I would like to discuss:
> 
> 
> Definitions
> -----------
> 
> H(data) = Hash(data)
> Response = KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) = HMAC-SHA256( H(A1), nonce:nc:cnonce:qop:H(A2) )
> 
> 
> Is there any objection to starting a new document to define HMAC and salted hash support?

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 19 May 2015 08:01:51 -0400

Thank you all for your response and support for this work.

Sophie,

I think you should hold off on starting implementing this until we have a
meaningful discussion, either on the mailing list or during the coming IETF
conference in Prague.

Regards,
 Rifaat

On Mon, May 18, 2015 at 3:01 PM, Sophie Bremer <[email-masked]