Subject: [tram] Questions on STUN credentials and MD5

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 23 Jul 2014 05:58:26 -0700

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?

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?

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?
Thanks for the help.
Mark Duckworth

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Jul 2014 09:48:27 -0400

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?

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Jul 2014 13:51:15 +0000

> -----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
> 
> > 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?

Yup,  draft-ietf-tram-turn-third-party-authz does not have this problem.

-Tiru

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