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

Rajmohan Banavi <rajmohanbanavi@gmail.com> Thu, 18 July 2013 12:28 UTC

Return-Path: <rajmohanbanavi@gmail.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 8FBA221F8D0D; Thu, 18 Jul 2013 05:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Wi0RqG+PGIVl; Thu, 18 Jul 2013 05:28:17 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB68A21F8895; Thu, 18 Jul 2013 05:28:17 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id 10so6968332ied.0 for <multiple recipients>; Thu, 18 Jul 2013 05:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/sGhxOCPIg1cfuS5hK+Pf+YrhGs8LYx6AoGDVazxhPk=; b=SvCK1F/zJqqgeWcU0lX7+g4lftHYH+nZIttdZ/7ihMKGQu77XNZw8q+sKf93NyQ5Zq GKPl18RGLxAOExuW3kEPzKAaGuvQbPOey/TNXf17RbaYI9c5JVK4m+Q6xiMP1wpYmJ+d ZYfxCL6scYS1g/wuO66ZzjbE3VQ1AYtsYxX8oWxcFyAR+3wuPKAfWfY+VdZkP6C3JI+p OwRrg6qFnfAxOEkxu7+I+xf8HAfOBIxv9A6QBaEEncK3Qy9GQc7NhbHKDCqvFfCHQOxX FGfx1/cuuP5U4ht9GyPcxhtLp0FT+m7aZKHrDM86jZJJemjWtHJy+T+0xb99exQvjnY6 FPRQ==
MIME-Version: 1.0
X-Received: by 10.50.1.78 with SMTP id 14mr2951908igk.60.1374150497256; Thu, 18 Jul 2013 05:28:17 -0700 (PDT)
Received: by 10.42.152.9 with HTTP; Thu, 18 Jul 2013 05:28:17 -0700 (PDT)
In-Reply-To: <CAOJ7v-2wzEQXSMPM4bnGW5_0ciDf9VuY1nb2xp=Wbqe0Rq5yZA@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> <CAOJ7v-2wzEQXSMPM4bnGW5_0ciDf9VuY1nb2xp=Wbqe0Rq5yZA@mail.gmail.com>
Date: Thu, 18 Jul 2013 17:58:17 +0530
Message-ID: <CAJWm+fE1G2r0TcUAcZUVCP0WRSC35JFBdZ-oMqJfAykhNExqyA@mail.gmail.com>
From: Rajmohan Banavi <rajmohanbanavi@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="047d7bdc119a41cf0c04e1c85826"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, behave <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: Thu, 18 Jul 2013 12:28:18 -0000

Hi  Justin, comments inline with additional comments at the end.

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

IMHO, the standard spec should not be based on any specific implementation
method. Now I agree that the TURN server validation becomes easier using
this method because it does not have to do some sort of lookup. However,
some another TURN server implementer can achieve the same functionality by
providing REST API but using randomly generated pasword (rather than use
HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE
request is received.

Now lets look at the collateral affects of using this proposed
implementation way
- TURN server needs to perform MESSAGE-INTEGRITY validation across two
secrets (worst case due to key rotation) when TURN ALLOCATE request is
received
- TURN username needs to consist of entire state (user identifier + expiry
time). And upon receiving the ALLOCATE request, TURN server must check if
the username is still valid based on expiry time part (of username)
- Time sync needs to be maintained across the web server and the TURN
server.

All of the above are not needed if one does not use the implementation
method specified in the draft but still provide REST API to generate
ephemeral credentials. How these ephemeral credentials are generated and
how the TURN requests are validated is an implementation decision. And it
is not desirable to have standards which caters to each implementation
method.


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

What does the web server do with the secret key? This is not clear from the
text.

Additional comments.

   1. 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)?
   2. The implementation method proposed is implicit and not clear from the
   draft text for the reader. The text states that username must be so and so,
   password must be HMAC processed etc, but it is not clear why these need to
   be done. It must be made clear somewhere in the draft that these are being
   proposed to ensure that the TURN server can validate the TURN ALLOCATE
   requests by performing HMAC on the USERNAME attribute received. And that
   the TURN server does not have to maintain/store ephemeral credentials. This
   will help the reader to comprehend the draft in a better way.

Hope it is clear.

Thanks,
Rajmohan Banavi