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

[Oleg Moskalenko <[e-mail]>]

Please see my comments in the text:


On Tue, Jul 23, 2013 at 11:54 PM, Rajmohan Banavi
<[e-mail]>wrote:

>
> Just to make my earlier point clearer - The credentials are generated by
> TURN server and validated by TURN server. None of the other components in
> the chain - web server, web application and the webrtc client, are
> concerned with it (sort of like a blob). So the interoperability is not an
> issue at all irrespective of what implementation approach you take.
>

This is not the case. It is not the TURN server who generates the
credentials. The web server must generate the temporary password, and to be
able to do that the web server must have the shared secret - the same as
TURN server has. How they share the same shared secret I'd leave outside
the proposed specs.



>
> I had some other comments earlier, which are collated below.
>
>    1. What does the web server do with the shared (with TURN server)
>    secret key? This is not clear from the text.
>
> It is rather clear - the web server takes the shared secret and it
generates the temporary password for long-term TURN credentials. The TURN
server can reproduce that generation process and obtain the same temporary
password - because the TURN server knows the same shared secret as the web
server.


>
>    1.
>    2. Sec 4.2 Server - "Note that the REALM value supplied by the server
>    is not meaningful in this context, and can be set to any valid value".
>    Which realm value is being referred here? The REALM attribute value in the
>    401 challenge response sent by the TURN server (in response to initial
>    ALLOCATE request)?
>
>
I do not see those words in the draft text on the Internet:

http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00

is there a newer version somewhere ?


>
>    1.
>    2. The 2 statements seem to be contradictory: sec 1 "However, as a
>    relay service, it imposes a nontrivial cost on the service provider". sec
>    5.1 "The assumption is that TURN services are of low enough value that
>    waiting for the timeout to expire is a valid approach for dealing with
>    possibly-compromised credentials". I am OK with the text, but would prefer
>    if this could be reworded in anyway.
>
>
I'd really like to have an access to the fresh draft,it seems like it was
not posted publicly - I cannot find it.

Thanks
Oleg