Subject: Re: [tram] STUN hash agility

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 28 Mar 2014 09:16:20 +0000

In addition to the MD5 security problem that Simon had mentioned in previous mails. The other problems that will not be resolved with SHA256 are:

1)TURN Server has to maintain the {username/realm/password} database just like the AD server which is an overhead.

2)In a large Enterprise Network (for e.g. consider a large service company) where NNN number of new users join, MMM users leave every day. It seems difficult to manage this credential database on the TURN server to be in sync with the AD.

3)If each branch office in an large enterprise network wants to deploy TURN servers, then the cost of TURN server includes additional storage space and operational issues which may be a concern of the I.T.

4)AD server maintained in the Data Center usually has better physical security than branch offices - what if someone breaks into the branch office and steals all the username + password ? (I am assuming the username, password are the same credentials used to access other critical enterprise resources)

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Friday, March 28, 2014 4:14 AM
To: Jonathan Lennox
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] STUN hash agility

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]<mailto:[email-masked]>> wrote:

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:

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.

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):
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.

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: Fri, 28 Mar 2014 02:55:58 -0700

Hi Tiru

I hope that those problems can be mostly addressed by the new OAuth
mechanism for TURN.

Regards,
Oleg

On Fri, Mar 28, 2014 at 2:16 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  In addition to the MD5 security problem that Simon had mentioned in
> previous mails. The other problems that will not be resolved with SHA256
> are:
>
>
>
> 2)In a large Enterprise Network (for e.g. consider a large service
> company) where NNN number of new users join, MMM users leave every day. It
> seems difficult to manage this credential database on the TURN server to be
> in sync with the AD.
>
> 3)If each branch office in an large enterprise network wants to deploy
> TURN servers, then the cost of TURN server includes additional storage
> space and operational issues which may be a concern of the
> I.T.
>
>
> 4)AD server maintained in the Data Center usually has better physical
> security than branch offices - what if someone breaks into the branch
> office and steals all the username + password ? (I am assuming the
> username, password are the same credentials used to access other critical
> enterprise resources)
>
>
>
> -Tiru
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Oleg Moskalenko
> *Sent:* Friday, March 28, 2014 4:14 AM
> *To:* Jonathan Lennox
> *Cc:* Simon Perreault; [email-masked]
>
> *Subject:* Re: [tram] STUN hash agility
>
>
>
> 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].
>
> 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
> 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.
>
>
>
>  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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 28 Mar 2014 10:44:15 +0000

Hi Oleg,

Yes, 3rd party with solve this problem. But, should first party auth be enhanced somehow to solve the below problems ?

Cheers
-Tiru

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Friday, March 28, 2014 3:26 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; Simon Perreault; [email-masked]
Subject: Re: [tram] STUN hash agility

Hi Tiru
I hope that those problems can be mostly addressed by the new OAuth mechanism for TURN.
Regards,
Oleg

On Fri, Mar 28, 2014 at 2:16 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

-Tiru

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Oleg Moskalenko
Sent: Friday, March 28, 2014 4:14 AM
To: Jonathan Lennox
Cc: Simon Perreault; [email-masked]<mailto:[email-masked]>

OK, thanks for the link.

Oleg

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Mar 2014 08:47:01 -0400

Oooooh! I love playing the devil's advocate... :)

Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a écrit :
> 1)TURN Server has to maintain the {username/realm/password} database
> just like the AD server which is an overhead.

Are you assuming that the TURN server cannot query the AD server instead
of maintaining a duplicate database?

In any case, database replication is easy and well understood. You need
to have *lots* of accounts for e.g. dead-simple MySQL replication to not
be sufficient.

> company) where NNN number of new users join, MMM users leave every day.
> It seems difficult to manage this credential database on the TURN server
> to be in sync with the AD.

Really? MySQL replication (for example) is dead simple.

> space and operational issues which may be a concern of the

I doubt this very much. You would need *lots* of user accounts for the
password database to not fit on any regular-sized hard drive.

About operations: once again, database replication is well understood
and very common.

> security than branch offices – what if someone breaks into the branch
> username, password are the same credentials used to access other
> critical enterprise resources)

Now this I totally buy. We need something better than
MD5(username:realm:password).

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: Jonathan Lennox <[email-masked]>
Date: Fri, 28 Mar 2014 14:40:10 +0000

> MD5(username:realm:password).

If TRAM wants to keep TURN password database compatibility with rfc2617bis, we’ll have to keep the key generation hash the same, since draft-ietf-httpauth-digest uses SHA256(username:realm:password).

That said, the security flaws that you have correctly identified with that scheme (notably, unsalted passwords) are exactly why some SIPCORE members were advocating moving away from 2617bis when updating SIP authentication.

I think the useful requirement (and this is a point that should probably be in the tram-auth-requirements draft) is to be able to keep password database compatibility with *SIP* as it defines new mechanisms, not necessarily with HTTP.

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 28 Mar 2014 11:46:08 -0700

see below inline:

On Fri, Mar 28, 2014 at 7:40 AM, Jonathan Lennox <[email-masked]> wrote:

> If TRAM wants to keep TURN password database compatibility with
> rfc2617bis, we'll have to keep the key generation hash the same, since
> draft-ietf-httpauth-digest uses SHA256(username:realm:password).
>
> That said, the security flaws that you have correctly identified with that
> scheme (notably, unsalted passwords)

I cannot agree that the scheme HASH(username:realm:password) can be
regarded as "unsalted passwords". An unsalted password would be something
like:

1) HASH(password)
2) HMAC-HASH(<some_long_string>)[password]

The scheme HASH(username:realm:password) has good qualities of a salted
password:

1) If two users of the same realm have the same password then their hashes
will be different;
2) If two users of different realms have the same name and the same
password, their hashes will be different.
3) Computationally, an attack is difficult.

Basically, all records in the database will have different hashes.
Computationally, an attack will be about as difficult as an attack on a
"salted" password database.

The problem with "salted" passwords is that the client must know that
"salt". I have no idea how to make that happen.

I think that if we do want to deal with a hashed password database, then
SHA256(username:realm:password) is a good scheme.

> are exactly why some SIPCORE members were advocating moving away from
> 2617bis when updating SIP authentication.
>
> I think the useful requirement (and this is a point that should probably
> be in the tram-auth-requirements draft) is to be able to keep password
> database compatibility with *SIP* as it defines new mechanisms, not
> necessarily with HTTP.
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Mar 2014 15:03:39 -0400

> "salt". I have no idea how to make that happen.

I suppose we could put the salt in a new STUN attribute.

I agree that the addition of salt would not change much. The only two
advantages to salt that I can see are:

- "username:realm" might not provide enough entropy compared to salt.

- Across different servers, the same "username:realm" would be hashed
according to the passwords only. No entropy at all. In particular, using
the same password would result in the same hash.

I don't know how strong those arguments are...

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 28 Mar 2014 17:26:39 -0700

Please see inline:

> - "username:realm" might not provide enough entropy compared to salt.

That concern might be valid only when a cryptographically weak hash
function is used. If the function is good enough (like SHA256) then any
minor difference in the input string must yield a new hash value as
dramatically new as a totally different input. For a good hash function the
difference between hash("Marissa1") and hash("Marissa2") must be as
significant as the difference between hash("Alice") and hash("Bob") - and
equally unpredictable.

> the same password would result in the same hash.

If those different servers are parts of the same realm and they are using
the same user database then, as you explained before, they will be using
database replication and the data will not be similar - the data will be
just the same, so an attacker will have as much extra information as if the
attacker would simply copy the stolen database multiple times over his hard
disk. Multiple copies of the same database do not give any extra
information.

If the applications are different then either the realm or the password
must be different, and the hash values are to be different.

Oleg

---

From: Brandon Williams <[email-masked]>
Date: Mon, 31 Mar 2014 09:57:09 -0400

On 03/28/2014 08:26 PM, Oleg Moskalenko wrote:
>
 > On Fri, Mar 28, 2014 at 12:03 PM, Simon Perreault 
<[email-masked]> wrote:
> If those different servers are parts of the same realm and they are
> using the same user database then, as you explained before, they will be
> using database replication and the data will not be similar - the data
> will be just the same, so an attacker will have as much extra
> information as if the attacker would simply copy the stolen database
> multiple times over his hard disk. Multiple copies of the same database
> do not give any extra information.

I think that Simon's point is that, without some entropy, access to the 
result of the hash on one machine for one session compromises the user's 
credentials for future sessions, even if the attacker has not determined 
the user's actual password.

--Brandon

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 31 Mar 2014 09:13:30 -0700

Yes that's a valid concern.

Oleg

Sent from my iPhone

> On Mar 31, 2014, at 6:57 AM, Brandon Williams <[email-masked]> wrote:
> 
> > On Fri, Mar 28, 2014 at 12:03 PM, Simon Perreault <[email-masked]> wrote:
> I think that Simon's point is that, without some entropy, access to the result of the hash on one machine for one session compromises the user's credentials for future sessions, even if the attacker has not determined the user's actual password.
> 
> --Brandon
> 
> --