Subject: [tram] STUN-bis and MD5 problem

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 12 Nov 2014 18:01:47 -0800

Hello,
I am trying to understand how the MD5 problem is or will be addressed.  Is it expected to be addressed in a future version of STUN-bis according to the "Hash Agility Plan" section?

Regards,
Mark

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Tirumaleswar
> Reddy (tireddy)
> Sent: Friday, October 24, 2014 5:10 PM
> To: Brandon Williams; [email-masked]
> Subject: Re: [tram] STUN-bis adoption call

... snip ...

> > Finally, there has been some discussion on the list about concerns
> regarding
> > the use of MD5 for generation and storage of keys and a hope that we
> could
> > move away from that mechanism. I'm not particularly concerns about that
> > myself, since we would be using the third party auth mechanism.
> 
> But when TURN server is deployed in Enterprise network then it may have to
> support both first and third party mechanisms.
> The problem with MD5 is documented in
> https://tools.ietf.org/html/rfc7376#section-4.
> 
> Cheers,
> -Tiru
> 
> > That said, I
> > was expecting to see some reference to these concerns in the context of
> hash
> > agility. Perhaps that item just hasn't been addressed yet and will be in a
> > future revision.
> >
> > --Brandon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 13 Nov 2014 03:13:13 -0700

> I am trying to understand how the MD5 problem is or will be addressed.  Is it expected to be addressed in a future version of STUN-bis according to the "Hash Agility Plan" section?

No, the problem that the "Hash Agility Plan" will solve (replacing HMAC-SHA1) is orthogonal to this problem.  My understanding was that the third party credential mechanism (draft-ietf-tram-turn-third-party-authz) was the replacement to the long term credential mechanism (LTCM) for people who care. (we cannot simply deprecate the LTCM because it was designed to match the way SIP stores its passwords).

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

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Nov 2014 11:10:18 -1000

On Thu, Nov 13, 2014 at 12:13 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> > I am trying to understand how the MD5 problem is or will be addressed.
> Is it expected to be addressed in a future version of STUN-bis according to
> the "Hash Agility Plan" section?
>
> No, the problem that the "Hash Agility Plan" will solve (replacing
> HMAC-SHA1) is orthogonal to this problem.  My understanding was that the
> third party credential mechanism (draft-ietf-tram-turn-third-party-authz)
> was the replacement to the long term credential mechanism (LTCM) for people
> who care.

I feel that third-party-authz is much too heavy for people who just want a
better hash algorithm. And it's an optional extension, not a core part of
STUN (unless we make it so in STUN-bis).

> (we cannot simply deprecate the LTCM because it was designed to match the
> way SIP stores its passwords).

That's just a poor excuse IMHO.

I think it is unreasonable to publish in 2015 a protocol that stores its
passwords with MD5.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 14 Nov 2014 00:30:40 +0000

From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Thursday, November 13, 2014 11:10 AM
To: Marc Petit-Huguenin
Cc: Duckworth, Mark; [email-masked]
Subject: Re: [tram] STUN-bis and MD5 problem

> I am trying to understand how the MD5 problem is or will be addressed.  Is it expected to be addressed in a future version of STUN-bis according to the "Hash Agility Plan" section?

No, the problem that the "Hash Agility Plan" will solve (replacing HMAC-SHA1) is orthogonal to this problem.  My understanding was that the third party credential mechanism (draft-ietf-tram-turn-third-party-authz) was the replacement to the long term credential mechanism (LTCM) for people who care.

I feel that third-party-authz is much too heavy for people who just want a better hash algorithm. And it's an optional extension, not a core part of STUN (unless we make it so in STUN-bis).

[TR] Yup, TURN server deployed in Enterprise network could support both first party authentication and third-party-authz.

(we cannot simply deprecate the LTCM because it was designed to match the way SIP stores its passwords).

I think it is unreasonable to publish in 2015 a protocol that stores its passwords with MD5.

[TR] What is the problem of moving to SHA-2 ?

-Tiru

Simon

---

From: Brandon Williams <[email-masked]>
Date: Thu, 13 Nov 2014 20:52:45 -0500

In my opinion, this is directly related to the hash agility plan, 
because identification of an appropriate key derivation function for 
each supported HMAC algorithm is important. I think mandating the use of 
MD5 as the KDF for SHA1 was a mistake to begin with, since it goes 
counter to the HMAC RFC. I think improved hash agility requires an 
improvement to the KDF, too.

--Brandon

On 11/13/2014 07:30 PM, Tirumaleswar Reddy (tireddy) wrote:
> *From:*tram [mailto:[email-masked]] *On Behalf Of *Simon Perreault
> *Sent:* Thursday, November 13, 2014 11:10 AM
> *To:* Marc Petit-Huguenin
> *Cc:* Duckworth, Mark; [email-masked]
> *Subject:* Re: [tram] STUN-bis and MD5 problem
>
>  > I am trying to understand how the MD5 problem is or will be
> addressed.  Is it expected to be addressed in a future version of
> STUN-bis according to the "Hash Agility Plan" section?
>
> third party credential mechanism
> (draft-ietf-tram-turn-third-party-authz) was the replacement to the long
> term credential mechanism (LTCM) for people who care.
>
> I feel that third-party-authz is much too heavy for people who just want
> a better hash algorithm. And it's an optional extension, not a core part
> of STUN (unless we make it so in STUN-bis).
>
> [TR] Yup, TURN server deployed in Enterprise network could support both
> first party authentication and third-party-authz.
>

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 14 Nov 2014 03:13:14 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Thursday, November 13, 2014 3:53 PM
> To: [email-masked]
> In my opinion, this is directly related to the hash agility plan, because
> identification of an appropriate key derivation function for each supported
> HMAC algorithm is important. I think mandating the use of
> MD5 as the KDF for SHA1 was a mistake to begin with, since it goes counter
> to the HMAC RFC. I think improved hash agility requires an improvement to
> the KDF, too.

SHA-2 can be used for key generation based on username, realm and password. KDF discussed in http://tools.ietf.org/html/rfc5869 can be used to generate appropriate keying material for message integrity of STUN messages and its length can be determined based on the hash algorithm negotiated.

-Tiru

> > On Thu, Nov 13, 2014 at 12:13 AM, Marc Petit-Huguenin
> > <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > HMAC-SHA1) is orthogonal to this problem.  My understanding was that
> > the third party credential mechanism
> > (draft-ietf-tram-turn-third-party-authz) was the replacement to the
> > long term credential mechanism (LTCM) for people who care.
> >
> > I feel that third-party-authz is much too heavy for people who just
> > want a better hash algorithm. And it's an optional extension, not a
> > core part of STUN (unless we make it so in STUN-bis).
> >
> > [TR] Yup, TURN server deployed in Enterprise network could support
> > both first party authentication and third-party-authz.
> >
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
>

---

From: Brandon Williams <[email-masked]>
Date: Thu, 13 Nov 2014 22:46:48 -0500

Sure, that's one way to resolve the "MD5 as KDF" problem for SHA-2 HMAC 
(and maybe some others too). I'm simply arguing that solving HASH 
agility and solving KDF agility are linked and should probably be 
considered collectively.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 14 Nov 2014 09:10:03 +0000

> Sent: Thursday, November 13, 2014 5:47 PM
> To: [email-masked]
> (and maybe some others too). I'm simply arguing that solving HASH agility
> and solving KDF agility are linked and should probably be considered
> collectively.

Agreed.

-Tiru

> > SHA-2 can be used for key generation based on username, realm and
> password. KDF discussed in http://tools.ietf.org/html/rfc5869 can be used to
> generate appropriate keying material for message integrity of STUN
> messages and its length can be determined based on the hash algorithm
> negotiated.
> >
> > -Tiru
> >
> >>
> >> --Brandon
> >>
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> >>