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

Oleg Moskalenko <> Wed, 24 July 2013 07:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EAC221F9B0D; Wed, 24 Jul 2013 00:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KkLGO9PF5Ygq; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::229]) by (Postfix) with ESMTP id B19AE21F9011; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
Received: by with SMTP id rp16so9471149pbb.28 for <multiple recipients>; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckE9drNK/meu1p7jSl2RuPZEg2xWJoLnM99Co79r52Y=; b=DBExkhiUDBuwucEr6PnZxVhp/ySyDnVWhjFwiXLSY/YfyeuSDDcG9VxsAFDp+SRxZQ BSLNYgVpwvOh11kfVFfdwWRW63cBfmTfoLrDZAnlSsvKtmHy3fFN8EwHGW9fqCIRvn1d JLyyn0lNlX8CR8vcI3LLIpwXAA49ilVzVNniQ+xUrLCWPsGSxaEg77X+g6dO+N79D+A0 TUCI0PhRrnUXbzk38yPHRPF/7owllL6Ls0CyKZUR7QP9/1HEwvtzyfc5il1z8v+TuWvj VQ0nQO9aMo8YGmHvvvS0YbcRozc0e5/qVPsek3r4T6+eNh7TbABc/ir49EB5Vxbi9z2K HiVA==
MIME-Version: 1.0
X-Received: by with SMTP id ii1mr40987113pbb.95.1374649881412; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
Received: by with HTTP; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 24 Jul 2013 00:11:21 -0700
Message-ID: <>
From: Oleg Moskalenko <>
To: Rajmohan Banavi <>
Content-Type: multipart/alternative; boundary="047d7b5d9ff7df488e04e23c9d1f"
X-Mailman-Approved-At: Wed, 24 Jul 2013 15:19:38 -0700
Cc: behave <>, "" <>
Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2013 07:11:22 -0000

Please see my comments in the text:

On Tue, Jul 23, 2013 at 11:54 PM, Rajmohan Banavi

> 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

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

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.