Subject: [pntaw] FW: New Version Notification for draft-reddy-behave-turn-auth-03.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 3 Sep 2013 11:53:20 +0000

[Including pntaw mailing list]

This draft discusses the issues with STUN Authentication for TURN. Comments and suggestions are welcome. In BEHAVE WG there were discussions to solve the problem mentioned in the draft using techniques like TURN over DTLS, draft-uberti-behave-turn-rest-00.

-Tiru.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 03, 2013 12:10 PM
To: Ram Mohan R (rmohanr); Tirumaleswar Reddy (tireddy); Muthu Arul Mozhi Perumal (mperumal); Alper Yegin; Ram Mohan R (rmohanr); Alper E. Yegin; Muthu Arul Mozhi Perumal (mperumal)
Subject: New Version Notification for draft-reddy-behave-turn-auth-03.txt

A new version of I-D, draft-reddy-behave-turn-auth-03.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Filename:	 draft-reddy-behave-turn-auth
Revision:	 03
Title:		 Problems with STUN Authentication for TURN
Creation date:	 2013-09-03
Group:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-03.txt
Status:          http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth
Htmlized:        http://tools.ietf.org/html/draft-reddy-behave-turn-auth-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-reddy-behave-turn-auth-03

Abstract:
   This document discusses some of the issues with STUN authentication
   for TURN messages.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 03 Sep 2013 15:38:38 +0200

Hi all,

These are another points in favor of TURN over websockets, as it would 
be possible to reuse HTTP authentication mechanisms, host several 
domains on same TURN server or even use SSOs/oAuth and reuse same 
authentication for web and for turn connections.

Best regards
Sergio

El 03/09/2013 13:53, Tirumaleswar Reddy (tireddy) escribió:
> _______________________________________________
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Sep 2013 16:05:08 +0200

Quick review of this document..... I am typing this up because I spent 
time reading the draft, not because I have a particular opinion about 
what should be done with it.

1) Please get someone to fix the grammar. For non-native English 
speakers like me, it is problematic to parse sentences like this:

    TURN server plays a vital and is a building block to support direct,
    interactive, real-time communication using audio, video,
    collaboration, games, etc., between two peers web-browsers in Web
    Real-Time communication (WebRTC) [I-D.ietf-rtcweb-overview]
    framework.

the problems of this specific sentence include:
- no article ("the", "a") on "Turn server"
- The sentence fragment around "peers web-browsers in..." does not parse 
for me. Either "peers using web browsers that implement" or, simpler, 
"two peers' web browsers using the" - or it's possible that the intended 
meaning wasthat "in Web Real-Time communication" was intended to group 
with "a building block". There's no way I can tell from the sentence.
- "plays a vital" has no object

I could go on, but it's really distracting and error-prone to guess at 
the intended grammar before I can start guessing at the intended meaning.

(the subsequent sections are actually a bit better. But this particular 
sentence was scary to me.)

2) The use case reference is wrong. Section 4.2.4.1 doesn't exist. 
Section 3.2.5.1 seems to fit the bill, but it's more stable to refer to 
them by name.

3) The password guessing attack described in section 4 bullet 1 *is* an 
offline dictionary attack. So the paragraph gives the same attack twice.

4) section 4 bullet 2 assumes that one needs a credentials database at 
the TURN server to verify the credentials. This is incorrect, as 
draft-uberti shows; all that is required is that the credentials are 
verifiable.

5) In section 4 bullet 4 one talks about "the USERNAME of the host". 
This word is used in addition to "client" and "user, seemingly 
interchangeably. The takeaway here is that reusing USERNAMEs over time 
leads to tracking of usages of the USERNAME, which may lead to tracking 
of the entity (client or user) that uses it. This is a good argument for 
a draft-uberti-like mechanism for throwaway credentials.

6) The security section is just incorrect. The whole draft is about 
raising security concerns.

I am not very happy with the idea of spending significant draft and 
review time on listing issues - but if we list issues, the issues should 
be correctly stated.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Sep 2013 08:41:06 +0000

Hi Harald,

Thanks for the comments. Please see inline

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Harald Alvestrand
> Sent: Tuesday, September 03, 2013 7:35 PM
> To: [email-masked]
> Subject: Re: [pntaw] FW: New Version Notification for draft-reddy-behave-turn-
> auth-03.txt
> 

Thanks, corrected.

> Section 3.2.5.1 seems to fit the bill, but it's more stable to refer to

In version 11 of draft rtcweb-use-cases-and-requirements section numbers have changed added section name for clarity (it is Section 3.2.5.1).

> offline dictionary attack. So the paragraph gives the same attack twice.

Fixed.

> draft-uberti shows; all that is required is that the credentials are

TURN server needs access to a credential database with username, realm and MD5 hash computed over the username, realm, and password. TURN server needs key derived from username and password (key = MD5(username ":" realm ":" SASLprep(password))) to validate message integrity for TURN request and also to calculate message-integrity for TURN response. 

> interchangeably. 

changed to "client" in all the places.

> The takeaway here is that reusing USERNAMEs over time

Fixed.

Thanks and Regards,
-Tiru.

> > This draft discusses the issues with STUN Authentication for TURN. Comments
> and suggestions are welcome. In BEHAVE WG there were discussions to solve the
> problem mentioned in the draft using techniques like TURN over DTLS, draft-
> uberti-behave-turn-rest-00.
> >
> > -Tiru.
> >
> > To: Ram Mohan R (rmohanr); Tirumaleswar Reddy (tireddy); Muthu Arul Mozhi
> Perumal (mperumal); Alper Yegin; Ram Mohan R (rmohanr); Alper E. Yegin; Muthu
> Arul Mozhi Perumal (mperumal)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 04 Sep 2013 11:40:41 +0200

> Thanks for the comments. Please see inline

Thanks for the rapid turnaround!
> TURN server needs access to a credential database with username, realm and MD5 hash computed over the username, realm, and password. TURN server needs key derived from username and password (key =…

For the case where the "password" is machine-generated, not user-chosen, 
there are more options (this was a surprise for me the first time I 
encountered it, too!)

For instance, if

username = <string, maybe chosen by user>
password = base64(HMAC(site-wide secret key + username))

the server that only knows the site-wide secret key can compute what the 
password should have been for any given <string chosen by user>, and 
thereby complete the verification.

(this particular scheme probably has cryptographic weaknesses; most 
schemes not designed by cryptographers are breakable)

You don't need a database, you just need to be able to validate the MAC 
- a database is one implementation.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 5 Sep 2013 12:15:15 +0000

Hi Harald,

Please see inline

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2013 3:11 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> > TURN server needs access to a credential database with username, realm and
> MD5 hash computed over the username, realm, and password. TURN server needs
> key derived from username and password (key = MD5(username ":" realm ":"
> SASLprep(password))) to validate message integrity for TURN request and also
> to calculate message-integrity for TURN response.
> 

Yes, draft-uberti-behave-turn-rest-00 is a new approach that solves some of the problems discussed in the draft. It is addressing third party authorization which will be useful in scenarios where WebRTC service and TURN server are provided by the same provider. 

The other scenario to consider is - If Enterprises want to deploy TURN server and want to use first party authentication (let's say "log-in" username and password for auditing, policy enforcement on usage of TURN resources etc)  then there is still a problem. In those cases either TLS or DTLS can be used to carry the TURN messages and addresses the problems in the draft, but WebRTC specific problem will be exposing the credential to java script.
 
-Tiru.