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

[Justin Uberti <[e-mail]>]

On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi
<[e-mail]>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 <[e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>