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

Justin Uberti <juberti@google.com> Wed, 17 July 2013 20:52 UTC

Return-Path: <juberti@google.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 E21AC21F9D30 for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 13:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.912
X-Spam-Level:
X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 mB+Up-oxb37K for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 13:52:14 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id AABB921F9FC8 for <rtcweb@ietf.org>; Wed, 17 Jul 2013 13:52:06 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id ey16so5926302wid.3 for <rtcweb@ietf.org>; Wed, 17 Jul 2013 13:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xIb0opwds0tFvYPj5l1fhcvdpSisaYIntBXdJYyLFbg=; b=CK2z3GinCjX0eABj3U/O+VFkyBP7wFhPay0KGRd/FdZbxzjruzugkg3MZgV3kWtQLJ ER3aow2Mzo/6NjTVFuHpSDaA5UGyD8r2AU5BcNcF22EtWsgFVgZRmFi7ulk0q8u+vlFy 1uCPRIA6wDo8i1/1TrpWdkSUBtsGQ+WMiFS1NLmnejujoAt1gzomGfK/taqvkF9Ijunk vagfqEYUqYimklS1a1kddhzB1NsRO1qn73IXP2pcumkoBRjbizwJfHrkG9aMr5oBXFQq X7wi6jgmuKrfizjwQKtPRi9TXspeknnUGImLDQ/F9X/ezbaxjVYZcwKOjdHiPXQiQw6y Esow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xIb0opwds0tFvYPj5l1fhcvdpSisaYIntBXdJYyLFbg=; b=P7jOy+gvSQ4zl2UvMMOg4JbTCKSzJTcz2ikeom53FSSjDidm0JojCBa2NcvmEGZt7v tgc1ld+ZxpWUZOe7nfOcucs5xrVSHvW9IZhU8NV4fisaJLcaIWwWgF3BL5NGVs8QQRbl +mxNEMubbkbGLIxA3FX6H82Qh/uleKj3GMxVtFAL9ZmCzNPkdCQ2J8GJvKOnabE2QpJQ uM2RfL3uyOhj3vOvUCsDkU/K2VMVuJg4aWqd0LN4E7BPiyJ2aPurKK/sYEE8n4LLnZl9 9J7H/5Y44rXzZwysDyieGNkfhCp/RWqQJZqNA6E5NDH9urLiKJGn2l4GUhkIT+2U30jJ jW6g==
X-Received: by 10.194.58.239 with SMTP id u15mr6169979wjq.87.1374094325595; Wed, 17 Jul 2013 13:52:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.62.113 with HTTP; Wed, 17 Jul 2013 13:51:45 -0700 (PDT)
In-Reply-To: <CAJWm+fGBDec_66WMBVhsv5TD8hVzDoOtd5CGs7xAHZqkYtDGBg@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>
From: Justin Uberti <juberti@google.com>
Date: Wed, 17 Jul 2013 16:51:45 -0400
Message-ID: <CAOJ7v-30p-osbYhkRw-uAePT6GLeExUk3NZ3LkoQno2jz0cJyw@mail.gmail.com>
To: Rajmohan Banavi <rajmohanbanavi@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba97b942a598a04e1bb44fa
X-Gm-Message-State: ALoCoQl8Tvvhshjx/pxgKT4SZyGZ+twdcHQuRqr4omeF8RnkLSoTzKrwQDtOew1mC06oP6IzFthb+H/APmrAMauWGSujkeUjv9SVGTvy9KbezYcGWUzT63Tj+HHtABvKdkGMZ91Gafce9wNLIFPfo5r7aimGnhRAhGY9vu3h/UAmhv8V6ZmZFPb1ndS6Q7PLO1uMVIWsI8VH
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 20:52:29 -0000

Thanks for your comments. Responses inline.

On Wed, Jul 17, 2013 at 2:56 PM, Rajmohan Banavi
<rajmohanbanavi@gmail.com>wrote;wrote:

> 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.
>
> This came up in some earlier rtcweb feedback, but I think it falls within
the definition of REST, as it meets the REST design constraints:
http://en.wikipedia.org/wiki/**Representational_state_**transfer#Constraints<http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints>


>
>    1. 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?
>
> RFC 5766 doesn't make any guarantees regarding the USERNAME attribute. You
know it hasn't been tampered with on the wire, via MESSAGE-INTEGRITY, but
you don't know that the USERNAME value is in fact something that the *web
server* previously gave out.

The construct defines in this draft ties the password to the USERNAME, so
that the client cannot change the USERNAME value and still have
MESSAGE-INTEGRITY validate properly.

This is also why a TURN password can't be generated randomly - the TURN
server wouldn't know what random value to use when computing its own
MESSAGE-INTEGRITY.

>
>    1. 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.
>
> Yes, thanks.

>
>    1. 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?
>
> There is no way to revoke credentials through the REST interface, since
there is no communication path between the web server and the TURN server.

>
>    1. 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?
>
> The lifetime of vended credentials may be 1 day, but if key rotation is
performed, sometimes a key rotation will occur during the lifetime of a
credential set. As such, the credentials will always need to be validated
against secretkey1 (old) and secretkey2(current) until 1 day after the key
rotation.

>
>
> 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...!
>