Subject: Re: [tram] Questions on STUN credentials and MD5

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 09:39:32 -0400

On 07/23/2014 09:51 AM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message-----
>> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
>> Sent: Wednesday, July 23, 2014 7:18 PM
>> To: Duckworth, Mark; [email-masked]
>> Subject: Re: [tram] Questions on STUN credentials and MD5
>>
>> Le 2014-07-23 08:58, Duckworth, Mark a écrit :
>>> Hello,
>>>
>>> I am a complete beginner regarding STUN and TURN, but I'm interested
>>> in one of the issues in draft-ietf-tram-auth-problems-02.  Section 4
>>> paragraph 2 describes the problem with using MD5 for STUN long term
>>> credentials.  A few questions about that -
>>>
>>> 1.       Does draft-ietf-tram-turn-third-party-authz solve the problem,
>>> because it provides a different way to do authentication which does
>>> not require MD5, and which can be FIPS 140-2 compliant?
>
> Yup,  draft-ietf-tram-turn-third-party-authz does not have this problem.
>

It's correct that the proposed 3rd party auth mechanism doesn't have 
this problem. That said, I don't think this means the draft solves the 
problem. It's probably also important to move away from MD5 for the 
other auth methods.

--Brandon

>
>>
>> I'll let the authors respond to that.
>>
>>> 2.       There was previous discussion about replacing MD5, possibly
>>> with SHA256, for the key calculation and storage.
>>> http://www.ietf.org/mail-archive/web/tram/current/msg00466.html.  Is
>>> that still a possibility, or did the group decide against that?
>>
>> I think that this is something that will need to go into STUN-bis. We currently
>> don't have an editor for that. All we need is a volunteer with time to do the
>> work...
>>
>>> 3.       At first I thought maybe draft-ietf-tram-stun-dtls could also
>>> solve the problem, because the hashed key would be further protected
>>> by DTLS.  But that wouldn't help with the issue of storing the MD5
>>> hashed keys on the TURN server side, would it?  Do I understand correctly?
>>
>> You're correct.
>>
>> Simon
>>
>> _______________________________________________
>> tram mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

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

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 09:43:25 -0400

On 07/23/2014 09:48 AM, Simon Perreault wrote:
>> I am a complete beginner regarding STUN and TURN, but I’m interested in
>> one of the issues in draft-ietf-tram-auth-problems-02.  Section 4
>> credentials.  A few questions about that –
>>
>> because it provides a different way to do authentication which does not
>> require MD5, and which can be FIPS 140-2 compliant?
>
> I think that this is something that will need to go into STUN-bis. We
> currently don't have an editor for that. All we need is a volunteer with
> time to do the work...
>

Should there be a ticket for this in the issues tracker? And what about 
a ticket for MESSAGE-INTEGRITY hash agility?

--Brandon

>> solve the problem, because the hashed key would be further protected by
>> DTLS.  But that wouldn’t help with the issue of storing the MD5 hashed
>> keys on the TURN server side, would it?  Do I understand correctly?
>
> You're correct.
>
> Simon
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 3 Sep 2014 09:51:35 -0400

On Wed, Sep 3, 2014 at 9:43 AM, Brandon Williams
<[email-masked]> wrote:
> Should there be a ticket for this in the issues tracker? And what about a
> ticket for MESSAGE-INTEGRITY hash agility?

Sure, if I can find my Trac password... ;) In the end I think we all
agree it is something for STUN-bis.

Simon