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

Rajmohan Banavi <rajmohanbanavi@gmail.com> Wed, 17 July 2013 18:56 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 421D921E804D; Wed, 17 Jul 2013 11:56:24 -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 abFslb4-zksj; Wed, 17 Jul 2013 11:56:23 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2408C21F9F3A; Wed, 17 Jul 2013 11:56:23 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id u16so4851653iet.23 for <multiple recipients>; Wed, 17 Jul 2013 11:56:22 -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=kT2Gvojh7D6+x9vC06KDxYq/tyr+eD3rI7eNZ/5V4QI=; b=bztslltZO4fwWEH+i5uADB2fpu1DJ8QppKHJl0b5Y3YmFGGHVTf8CwEhVKtk458T+V 3ORRrqOjNZkU5TdMl5ICQEuMtetVCOj3gxBDWUhv3FbU4QqoY9bkdlGogFHK2j0jsstV 2R39Sd+JAErusJarWqdMt55ViuYu62pper4j3DVMflBpkQPKCCrhsKD/OPXwuHsm0zMv v1ds7EHYyx5/4AQEpxeK5CfX9gUjoquOrfXi2sspsDMATAVwLj9BNnoUYOPHEj//twz/ wsZAEVi/bICf3IUlKpRKcFSBGtgaZmgjadj8fWocxS4oI3L+m2cxFGE1JNSSjUxDqL19 RELg==
MIME-Version: 1.0
X-Received: by 10.50.66.210 with SMTP id h18mr11086023igt.19.1374087382679; Wed, 17 Jul 2013 11:56:22 -0700 (PDT)
Received: by 10.42.152.9 with HTTP; Wed, 17 Jul 2013 11:56:22 -0700 (PDT)
In-Reply-To: <CAOJ7v-2WGi_fD9mVx+dtZBo+X4-sXxXZFek9mt2cAmrqFCyYMg@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>
Date: Thu, 18 Jul 2013 00:26:22 +0530
Message-ID: <CAJWm+fGBDec_66WMBVhsv5TD8hVzDoOtd5CGs7xAHZqkYtDGBg@mail.gmail.com>
From: Rajmohan Banavi <rajmohanbanavi@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=047d7bdca46855c97504e1b9a6dd
Cc: behave@ietf.org, "rtcweb@ietf.org" <rtcweb@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: Wed, 17 Jul 2013 18:56:24 -0000

Hi Justin,

I reviewed draft-uberti-behave-turn-rest-00 and have the following comments.

   1. IMHO, calling the API as REST does not seem to be appropriate since
   the API does not follow the REST principles of addressing/operating on a
   resource.
   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. So why not just generate a TURN password randomly? This
   would avoid the need to have a secret key between the TURN server and the
   webrtc app. Am I missing any scenario here where this extra security is
   required?
   3. sec 4.1 Client - Does it make it more clear if we reword the last
   sentence as - and the "password" value as input to generate the HMAC digest
   key used while calculating MESSAGE-INTEGRITY hash.
   4. Sec 5.1 Revocation - Why is revoking of specific credentials not
   possible? Probably need more clarity on who would try to revoke the
   credentials and under what scenario?
   5. Sec 5.2 Key Rotation - I presume here that the shared secret
   mentioned is the one shared between the TURN server and the webrtc
   application. The TURN password once generated using say secretkey1 and
   user1 will be valid on the TURN server till the expiry timeout (as per
   suggested value of 1 day) value. Why do we then need the TURN server to
   validate the message integrity against 2 secret keys? Wouldn't this
   behavior not contradict the one stated in TURN RFC?

Thanks,
Rajmohan
MindBricks


On Tue, Jul 16, 2013 at 3:22 AM, Justin Uberti <juberti@google.com> wrote:

> I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not
> all of the comments I received on the RTCWEB mailing list have been
> addressed.
>
> BEHAVE chairs, I would like 10 minutes of agenda time to discuss this
> draft.
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Mon, Jul 15, 2013 at 5:49 PM
> Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt
> To: Justin Uberti <justin@uberti.name>
>
>
>
> A new version of I-D, draft-uberti-behave-turn-rest-00.txt
> has been successfully submitted by Justin Uberti and posted to the
> IETF repository.
>
> Filename:        draft-uberti-behave-turn-rest
> Revision:        00
> Title:           A REST API For Access To TURN Services
> Creation date:   2013-07-15
> Group:           Individual Submission
> Number of pages: 8
> URL:
> http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest
> Htmlized:
> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00
>
>
> Abstract:
>    This document describes a proposed standard REST API for obtaining
>    access to TURN services via ephemeral (i.e. time-limited)
>    credentials.  These credentials are vended by a web service over
>    HTTP, and then supplied to and checked by a TURN server using the
>    standard TURN protocol.  The usage of ephemeral credentials ensures
>    that access to the TURN server can be controlled even if the
>    credentials can be discovered by the user, as is the case in WebRTC
>    where TURN credentials must be specified in Javascript.
>
>
>
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


-- 

Life is here and now, not yesterday, not tomorrow...!