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

[Justin Uberti <[e-mail]>]

Thanks for your comments. Responses inline.

On Wed, Jul 17, 2013 at 2:56 PM, Rajmohan Banavi
<[e-mail]>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 <[e-mail]> 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: <[e-mail]>
>> Date: Mon, Jul 15, 2013 at 5:49 PM
>> Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt
>> To: Justin Uberti <[e-mail]>
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
> --
>
> Life is here and now, not yesterday, not tomorrow...!
>