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

Rajmohan Banavi <rajmohanbanavi@gmail.com> Wed, 17 July 2013 21:09 UTC

Return-Path: <rajmohanbanavi@gmail.com>
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 004BD21E8056; Wed, 17 Jul 2013 14:09:16 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 2ftoC1RjchGA; Wed, 17 Jul 2013 14:09:15 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B06CE21E8055; Wed, 17 Jul 2013 14:09:14 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id 10so5202767ied.14 for <multiple recipients>; Wed, 17 Jul 2013 14:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XSY0uoWPDRiCPpiu9+WoyqJnEG2LNDdqGP3KoTKOass=; b=YAD5I2MF2ICVikl9m+tX4fo93W/h5jBIGI2Ii/bS9q9Xbemz2Hv7XO2VNCElZtdxmn geMBPmVTx+4a5X8ncbURgmTPxuPQXL289UdvBmlXJzkKoLU6G1/O+52QYDlK+xMl/EWQ QAZVlQEpBsCrsTLSj72q1raCfzkkz3XaLdBsIXCQvDCWmqfjygywoHOruNb12ED0KuI1 JgVttTCF93rCNIn5ad5d13TMih3o4hwVddbQ3daHj72nV6IH5TVFZOH+z/7RfbX7gL3g tAeoRgOZx2j2WvzQDH2hAChj2ABTBJBder+NxItoAm17UaaPjsNGZXcIblqE4O4jiKDY EIjw==
MIME-Version: 1.0
X-Received: by 10.50.62.75 with SMTP id w11mr2027212igr.19.1374095354174; Wed, 17 Jul 2013 14:09:14 -0700 (PDT)
Received: by 10.42.152.9 with HTTP; Wed, 17 Jul 2013 14:09:14 -0700 (PDT)
In-Reply-To: <51E70106.8060100@goodadvice.pages.de>
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> <51E70106.8060100@goodadvice.pages.de>
Date: Thu, 18 Jul 2013 02:39:14 +0530
Message-ID: <CAJWm+fGUEH43bgR1j56qea3+uSVQ63myr1tZkrdYRGEmBw=zew@mail.gmail.com>
From: Rajmohan Banavi <rajmohanbanavi@gmail.com>
To: Philipp Hancke <fippo@goodadvice.pages.de>
Content-Type: multipart/alternative; boundary="047d7bdc10e47923a204e1bb811b"
Cc: behave@ietf.org, "rtcweb@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 21:09:16 -0000

Thanks for the detailed example. I agree with the entire flow you have
given. My only concern is - why should the ephemeral password be generated
by TURN server using HMAC SHA on then username string? Why can't this be
some random unique string?

Taking your example -

Suppose TURN server generates credentials, username = "12334939:mbzrxpgjys"
and password ="+somerandomstring+". This is a randomly generated string and
passed onto webrtc app. The TURN server also stores these credentials for
later validation.
var iceServer = {
     "username": 12334939:mbzrxpgjys,
     "credential": +somerandomstring+,
   };

These credentials are passed from JS to the webrtc client stack in the
browser.

On Browser WebTRC Client.
key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+)
Similarly on the TURN server, the key for MESSAGE-INTEGRITY is calculated
using
key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+)

So the browser and turn server use the same input to the M-I. The one
implementation related advantage I see with this way of generation of TURN
password using HMAC is that the TURN server need not really store the HMAC
generated password, but can calculate the same using the USERNAME attribute
in the received TURN request.

In fact, I do not see why the sharedsecret needs to be shared between the
TURN server and the WebRTC application. The sharedsecret key "secret" is
only required by the TURN server for validating the received TURN ALLOCATE
requests once it has generated and sent out the ephemeral credentials. What
does the WebRTC application do with the shared secret key?

Thanks,
Rajmohan


On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke
<fippo@goodadvice.pages.de>wrote:

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



-- 

Life is here and now, not yesterday, not tomorrow...!