Subject: [tram] STUN hash agility

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Mar 2014 14:18:59 -0400

I don't see this problem listed in draft-ietf-tram-auth-problems. Does
it need to be?

Here's a naive attempt at a summary. Please feel free to suggest
improvements.

7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no
mechanism for hash agility in the protocol itself, although Section 16.3
of [RFC5389] does discuss a plan for migrating to a more secure
algorithm in case HMAC-SHA1 is found to be compromised. In addition,
STUN passwords are stored server-side using unsalted MD5 hashes, which
is not considered best current practice. [RFC6151]

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Brandon Williams <[email-masked]>
Date: Mon, 24 Mar 2014 15:58:57 -0400

These two problems might want separate bullets, but they are definitely 
both important issues with the authentication mechanism in the RFC.

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 24 Mar 2014 13:17:33 -0700

I suppose that that summary is good enough - it describes the problem
without suggesting a particular solution.

On Mon, Mar 24, 2014 at 12:58 PM, Brandon Williams <
[email-masked]> wrote:

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

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 25 Mar 2014 14:32:34 +0000

> is not considered best current practice. [RFC6151]

I would amplify the second point to say that it’s currently not possible use STUN long-term credentials in FIPS 140-2 compliant implementations, since MD5 isn’t an approved algorithm.

For a solution (and thus getting off the direct topic of draft-ietf-tram-auth-problems), one possibility would be to change the long-term credential mechanism to be able to use SHA-256 instead of MD5 (and thus inheriting the mechanisms of draft-ietf-httpauth-digest in the same way that STUN inherits those of RFC 2617), and I believe Oleg’s rfc5766-turn-server implements something like this.

However, it sounds like people might think that long-term credentials are broken for deeper reasons than just the choice of the hash algorithm, which would imply that a deeper mechanism change would be needed.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 25 Mar 2014 22:57:55 -0700

Jonathan, please see below inline:

On Tue, Mar 25, 2014 at 7:32 AM, Jonathan Lennox <[email-masked]> wrote:

> I would amplify the second point to say that it's currently not possible
> use STUN long-term credentials in FIPS 140-2 compliant implementations,
> since MD5 isn't an approved algorithm.
>
> For a solution (and thus getting off the direct topic of
> draft-ietf-tram-auth-problems), one possibility would be to change the
> long-term credential mechanism to be able to use SHA-256 instead of MD5
> (and thus inheriting the mechanisms of draft-ietf-httpauth-digest in the
> same way that STUN inherits those of RFC 2617), and I believe Oleg's
> rfc5766-turn-server implements something like this.
>

I did not get the part SHA256 vs MD5.

SHA1 algorithm (and optionally SHA256 in our implementation) is used for
the message digest calculation. MD5 is used totally independently of SHA1
(and SHA256) for a different purpose - for the key calculation (and
storage). Are you suggesting usage of SHA256 for the key calculation, too
(in place of MD5) ? Probably, for FIPS, it would indeed make sense. We are
currently still using MD5 for the key storage, and SHA256 only for the
message digest.

Oleg

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Mar 2014 08:23:59 -0400

Le 2014-03-26 01:57, Oleg Moskalenko a écrit :
>     I would amplify the second point to say that it’s currently not
>     possible use STUN long-term credentials in FIPS 140-2 compliant
>     implementations, since MD5 isn’t an approved algorithm.
> 
> the message digest calculation. MD5 is used totally independently of
> SHA1 (and SHA256) for a different purpose - for the key calculation (and
> storage). Are you suggesting usage of SHA256 for the key calculation,
> too (in place of MD5) ? Probably, for FIPS, it would indeed make sense.
> We are currently still using MD5 for the key storage, and SHA256 only
> for the message digest.

The situation with MD5 as I understand it is the following. I'm not a
cryptographer, so please anyone feel free to correct me. This is all
from memory, so I'm not going to cite sources.

- There are known attacks against MD5 and, to a lesser extent, SHA1. A
better hash algorithm is to be preferred when possible.

- Those attacks don't carry over to HMAC-SHA1, which is still believed
to be secure for now. However, planning a migration to HMAC-SHA256 (or
whatever else) would be justified.

- The special case of HMAC-SHA1 used with a key resulting from MD5 is
also believed to be secure for now.

- In STUN, the server stores MD5(username:realm:password). This is
problematic today because MD5 is known to be weak and there is no salt.
So if the password database gets stolen, an attacker could recover
passwords more easily than if a better hash algorithm was used with salt.

Simon

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 26 Mar 2014 16:08:10 +0000

On Mar 26, 2014, at 1:57 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Mar 25, 2014 at 7:32 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

SHA1 algorithm (and optionally SHA256 in our implementation) is used for the message digest calculation. MD5 is used totally independently of SHA1 (and SHA256) for a different purpose - for the key calculation (and storage). Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably, for FIPS, it would indeed make sense. We are currently still using MD5 for the key storage, and SHA256 only for the message digest.

Yes, I’m saying that we'd want to be able to use SHA256 for the key calculation.

This is partially motivated by the FIPS compliance problem.

Additionally, however, one motivation for the specific design of STUN’s current long-term credential mechanism was to let service providers re-use their existing RFC 2617 password databases for their TURN servers.

As draft-ietf-httpauth-digest’s update to RFC 2617 is adding the ability to use SHA-256 (and SHA-512/256) for digest authentication, and deprecating MD5, if this is still a use case that TRAM wants to support we need to support key calculation hash agility matching digest authentication’s updated hash agility.

That said, I believe the service providers of interest in STUN's design were not actually using RFC 2617 for HTTP Digest, but rather for SIP authentication.  So I think TRAM’s decision may want to depend on whether the SIPCORE working group decides to adopt draft-yusef-sipcore-digest-scheme (which adapts draft-ietf-httpauth-digest to SIP), or instead goes for a more thorough redesign of SIP authentication, which some people were advocating in the working group meeting in London.

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 27 Mar 2014 15:26:15 -0700

On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <[email-masked]> wrote:

>  Yes, I'm saying that we'd want to be able to use SHA256 for the key
> calculation.
>
I checked the document
http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I found
no suggestion on the key storage and calculation algorithms.

The problem is that I do not think that we can use the "classic" HMAC-SHA
approach with a salt word, or a shared secret, as the keys for the HMAC
functions - because then we have an immediate problem: how the client
(person or application) will know that salt value or the secret value ? The
client application must be able to calculate the same hash key value.

May be I am missing something (I am not a security expert), but if we do
want to use HMAC-SHA256 for the keys, then I see only one realistic
approach (or a variation):

hmac-key = username:realm:password

long-term-credentials-key = HMAC-SHA256(hmac-key)[hmac-key], where hmac-key
is used both as the key and as the input string to the HMAC algorithm.

STUN-message-integrity-digest =
HMAC-SHA256(message)[long-term-credentials-key] (similar to the existing
long-term-credentials mechanism)

With this approach, we are having about the same advantages as the "salt
scheme" has, but we do not have a problem how to distribute the "salt" or
the extra "secret" to the client application.

Oleg

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 27 Mar 2014 22:34:50 +0000

On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I found no suggestion on the key storage and calculation algorithms.

That document has been replaced by http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 — they decided to re-write it as a replacement for RFC 2617, not an update to it.  Apologies if I had the wrong link in an earlier e-mail.

In that document, the key is H(A1), as described in section 5.12 — i.e., hash(username:realm:password).  (Section 5.12 is poorly worded, because there are two different versions of A1 — but in either case, what the database has to store is exactly hash(username:realm:password).)

The problem is that I do not think that we can use the "classic" HMAC-SHA approach with a salt word, or a shared secret, as the keys for the HMAC functions - because then we have an immediate problem: how the client (person or application) will know that salt value or the secret value ? The client application must be able to calculate the same hash key value.

May be I am missing something (I am not a security expert), but if we do want to use HMAC-SHA256 for the keys, then I see only one realistic approach (or a variation):

long-term-credentials-key = HMAC-SHA256(hmac-key)[hmac-key], where hmac-key is used both as the key and as the input string to the HMAC algorithm.

STUN-message-integrity-digest = HMAC-SHA256(message)[long-term-credentials-key] (similar to the existing long-term-credentials mechanism)

With this approach, we are having about the same advantages as the "salt scheme" has, but we do not have a problem how to distribute the "salt" or the extra "secret" to the client application.

I don’t see any benefits to using HMAC for the long-term-credentials-key over using SHA256(username:realm:password) directly.

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 27 Mar 2014 15:44:16 -0700

OK, thanks for the link.

I agree that SHA256(username:realm:password) is better (simpler) here than
HMAC-SHA256(username:realm:password)[username:realm:password].

I'll update our experimental implementation so it will be using SHA256 for
the key storage.

Oleg

On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox <[email-masked]> wrote:

>
>  On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <[email-masked]> wrote:
>
>  On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <[email-masked]>wrote:
>
>>
>>
>>    SHA1 algorithm (and optionally SHA256 in our implementation) is used
>> for the message digest calculation. MD5 is used totally independently of
> http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I
> found no suggestion on the key storage and calculation algorithms.
>
>
>  That document has been replaced by
> http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 -- they decided
> to re-write it as a replacement for RFC 2617, not an update to it.
>  Apologies if I had the wrong link in an earlier e-mail.
>
>  In that document, the key is H(A1), as described in section 5.12 -- i.e.,
> hash(username:realm:password).  (Section 5.12 is poorly worded, because
> there are two different versions of A1 -- but in either case, what the
> database has to store is exactly hash(username:realm:password).)
>
>   The problem is that I do not think that we can use the "classic"
> HMAC-SHA approach with a salt word, or a shared secret, as the keys for the
> HMAC functions - because then we have an immediate problem: how the client
> long-term-credentials-key = HMAC-SHA256(hmac-key)[hmac-key], where
> hmac-key is used both as the key and as the input string to the HMAC
> algorithm.
>
>
>  I don't see any benefits to using HMAC for the long-term-credentials-key
> over using SHA256(username:realm:password) directly.
>
>