Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

[Oleg Moskalenko <[e-mail]>]

Hi Tiru

regarding the refresh requests, please below:


On Mon, Feb 17, 2014 at 9:34 PM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

>   [Oleg]: Tiru, I'd still like to hear a more definite language: what
> about "new requests" within the existing session ? They are allowed to use
> the old token - right ? When you are saying "new requests" you mean "new
> session allocation requests", right ?
>
>
>
> [TR1]
>
> These are my initial thoughts (we probably need more discussion on this
> topic):
>
> [a] New token is definitely applicable for "new session allocation
> requests".  If the client uses the token after its lifetime then the TURN
> server MUST return error that the token is invalid which is in line with
> the steps defined in http://tools.ietf.org/html/rfc6749#section-1.5
>
> [b] For "new request" within the existing session why not use the new
> token ? This way the client has to maintain only one token.  We can clarify
> in the draft that Refresh request can carry the new access token.
>
> [c The actual lifetime provided by the server in the Allocate/refresh
> response should be less than or equal to the lifetime of the token.
>
>
>
I re-read the appropriate section of STUN RFC 5389:

http://tools.ietf.org/search/rfc5389#section-10.2.2

and I have a feeling that the password in the existing TURN clients and
TURN servers is supposed to be cached for the lifetime of the session. If
we allow the token to be valid for the lifetime of the session that was
established with that token (for this particular session only) then
probably the draft specs will be easier to implement and it will be more
directly related to the original STUN RFC 5389.

But I have no strong opinion on that, it can be both ways.

Regards,
Oleg