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

Justin Uberti <juberti@google.com> Wed, 17 July 2013 22:12 UTC

Return-Path: <juberti@google.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 2A19721E804B for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 15:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UJQNbGTJ-xyd for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 15:12:14 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 48A7521F9FC8 for <rtcweb@ietf.org>; Wed, 17 Jul 2013 15:12:03 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id ey16so185777wid.3 for <rtcweb@ietf.org>; Wed, 17 Jul 2013 15:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q9hk7ezbueSHDE6DyXVKPX334cUUJEP2DDnXj8fImEk=; b=J74VEE0yXBGBdpZc9KVEuhj9jOgrQJWqY2qdIyG9SnN8HoWRpT3PdcVPAhC6ojCHzF nxd4zLAWkHI022GI5i5mdYAJKsHmUEfEzbZiMqCDUlIgVMK3QcH3AXd4cB43OBUJ/5jY P4UJXNS/flA5cKATDlZ2YHq7vUCj7T5l6HRiJ1cCMuEY2RKE3XMthyog2T6BWFg5shAJ 4EnL+8Lp/uV3PE8EbB22EG162vGx5eXuWQdV+oDCXW4ZNvoFtOFdnSBetq/FHh8BtvsU tX637dA73/eIb3dNeckN+TfZKO4eZvP9i+Qb/igAlp+93ncalbKHKkzCs5WGhmzmlm54 n8zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=q9hk7ezbueSHDE6DyXVKPX334cUUJEP2DDnXj8fImEk=; b=IqSkFbFZCYjEyurIihJwDJC6440DykIcTJVTxVBa1pPFXo9+g/5ThPxmwSuw9kznJi q2nlG+v4jQvuTyFVNgyjXQUc9E8wpLuInxqVFHKTMo//Kz2Ky0PNpn7pQ74/TjR85XxX qLX5UzHCBjO9ci1mqE23KpPMpYkHyKoJVAoWmwCAxQTaEcCOqliBrhQXuJS1ymEIMK2e UFaz98i95Occ2x1TQpxelkBFWA1RVqUBLPoWMmgC7UmCt5bVf9JheWz0mnBpVs9J2rGb TPN0TxK7DmPg5CeCKvCPYkONj1seoF4q+du+bWgFogiMYzd8C+N65Atak0JAJpmmM3Ri x/Zg==
X-Received: by 10.180.80.6 with SMTP id n6mr17535435wix.59.1374099122181; Wed, 17 Jul 2013 15:12:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.62.113 with HTTP; Wed, 17 Jul 2013 15:11:42 -0700 (PDT)
In-Reply-To: <CAJWm+fGUEH43bgR1j56qea3+uSVQ63myr1tZkrdYRGEmBw=zew@mail.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> <51E70106.8060100@goodadvice.pages.de> <CAJWm+fGUEH43bgR1j56qea3+uSVQ63myr1tZkrdYRGEmBw=zew@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 17 Jul 2013 18:11:42 -0400
Message-ID: <CAOJ7v-2wzEQXSMPM4bnGW5_0ciDf9VuY1nb2xp=Wbqe0Rq5yZA@mail.gmail.com>
To: Rajmohan Banavi <rajmohanbanavi@gmail.com>
Content-Type: multipart/alternative; boundary=14dae9cc955c1083aa04e1bc627c
X-Gm-Message-State: ALoCoQk1jObkguZ1N8JoI5712KhJ9BwxD/Fbd7zjZfQ95YwUmzYlM6IJDEdlXC1EzKpK3YcJihcPx6z/EftNgnslydj+ytIwB5En187hq0MekQcB3W+NF/ppBM70Suc7HfqBeXcfibyk1YnR3jXOvnLp8FcTyjNod3J9oN+pmucklHth26UFEUlmophfmv7z6nkllj5KF182
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, behave@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 22:12:14 -0000

On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi
<rajmohanbanavi@gmail.com>wrote;wrote:

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

Correct, but that is a significant advantage, especially when the web and
TURN servers are separate entities.

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

The WebRTC client application doesn't see the secret key, this is only
shared between the web and TURN servers.


>
> 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...!
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>