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
- [rtcweb] Fwd: New Version Notification for draft-… Justin Uberti
- Re: [rtcweb] Fwd: New Version Notification for dr… Rajmohan Banavi
- Re: [rtcweb] Fwd: New Version Notification for dr… Philipp Hancke
- Re: [rtcweb] Fwd: New Version Notification for dr… Justin Uberti
- Re: [rtcweb] Fwd: New Version Notification for dr… Rajmohan Banavi
- Re: [rtcweb] Fwd: New Version Notification for dr… Justin Uberti
- Re: [rtcweb] Fwd: New Version Notification for dr… Rajmohan Banavi
- Re: [rtcweb] Fwd: New Version Notification for dr… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Fwd: New Version Notification for dr… Adam Roach
- Re: [rtcweb] Fwd: New Version Notification for dr… Philipp Hancke
- Re: [rtcweb] [BEHAVE] Fwd: New Version Notificati… Justin Uberti
- Re: [rtcweb] [BEHAVE] Fwd: New Version Notificati… Rajmohan Banavi
- Re: [rtcweb] [BEHAVE] Fwd: New Version Notificati… Rajmohan Banavi
- Re: [rtcweb] [BEHAVE] Fwd: New Version Notificati… Oleg Moskalenko
- Re: [rtcweb] [BEHAVE] Fwd: New Version Notificati… Oleg Moskalenko
- Re: [rtcweb] [BEHAVE] Fwd: New Version Notificati… Kaiduan Xie