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

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