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

[Rajmohan Banavi <[e-mail]>]

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