Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt

Philipp Hancke <fippo@goodadvice.pages.de> Wed, 17 July 2013 20:40 UTC

Return-Path: <fippo@goodadvice.pages.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6D21F9DFA; Wed, 17 Jul 2013 13:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZpfXPyWas-2; Wed, 17 Jul 2013 13:39:50 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4FA21F9344; Wed, 17 Jul 2013 13:39:49 -0700 (PDT)
Received: from [192.168.2.100] (p549700D7.dip0.t-ipconnect.de [84.151.0.215]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6HKddb9026363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 22:39:44 +0200
Message-ID: <51E70106.8060100@goodadvice.pages.de>
Date: Wed, 17 Jul 2013 22:39:34 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: rajmohanbanavi@gmail.com
References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <CALe60zBA_unaQekMkKwKwKNRPbJjECAtJ9bAV=fv6V6Mdfon6Q@mail.gmail.com> <CAOJ7v-2WGi_fD9mVx+dtZBo+X4-sXxXZFek9mt2cAmrqFCyYMg@mail.gmail.com> <CAJWm+fGBDec_66WMBVhsv5TD8hVzDoOtd5CGs7xAHZqkYtDGBg@mail.gmail.com>
In-Reply-To: <CAJWm+fGBDec_66WMBVhsv5TD8hVzDoOtd5CGs7xAHZqkYtDGBg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org, rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 20:40:09 -0000

Am 17.07.2013 20:56, schrieb Rajmohan Banavi:
> Hi Justin,
>
> I reviewed draft-uberti-behave-turn-rest-00 and have the following comments.
[...]
>     2. Sec 4.3 last paragraph - "Because the password is derived from the
>     USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the
>     username is trustworthy". I believe this validation is taken care of in the
>     TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN
>     client generates a long term key which is computed as => key =
>     MD5(username ":" realm ":" SASLprep(password)). This key is used to perform
>     hmac on the message. The same is done on the TURN server end as well. If
>     the MESSAGE-INTEGRITY is verified, then it implies that the username is
>     trustworthy.

Let me try to address that with a lenghty example:
The web server returns
password = BASE64(HMAC-SHA1(username, sharedsecret))
to the browser.

For example, with username = "12334939:mbzrxpgjys" and sharedsecret 
"secret", the password given to the browser would be
"+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully)




The browser passes the username, uri and password to it's webrtc stack.
The password is exposed to the user of the browser (which might be 
anyone surfing your website) during that process.

That stack does long term authentication and uses this password string 
as input for calculating MESSAGE-INTEGRITY with
key = MD5(username ":" realm ":" SASLprep(password))

For the example this would be
key =MD5("12334939:mbzrxpgjys" ":" realm ":" 
SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=")




On the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(USERNAME, 
sharedsecret))

So for the example this would be
  = MD5("12334939:mbzrxpgjys" ":" realm ":" 
SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", "secret"))
  = MD5("12334939:mbzrxpgjys" ":" realm ":" 
SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=")

So the browser and turn server use the same input to the M-I. This can 
be done by looking at the request alone given the shared secret.


Does that make it clearer?

philipp,
who only understood it after implementing it