Timestamp in ephemeral username should be expiry timestamp instead of creation timestamp

[GoogleCodeExporter]

Currently the timestamp in the ephemeral username is the time at which that 
username was created.  This means that both the web service creating the 
username and the TURN server have to be independently configured with the same 
TTL for everything to work as expected.

I think it would make more sense to put the expiry timestamp in the username, 
so the TURN server just needs to check whether it is in the past.  The web 
service is the only component that needs to be configured with the TTL, so 
you're less likely to see unexpected behaviour due to misconfiguration.

Original issue reported on code.google.com by gavin.ll...@crocodilertc.net on 4 Jun 2013 at 3:45

[GoogleCodeExporter]

But, this is actually how it works right now - with exception of the offset. 
The web server provides timestamp, and the only check that the TURN server is 
doing is that it is adding the expiration time (default - 1 day of seconds) and 
then it checks that it has not expired yet. Even if the clock is off like 12 
hours it still will work. We must have some absolute values because we do not 
want it to be reused. So, if understand your suggestion correctly, this is 
actually how it works now, really. 

Original comment by mom040...@gmail.com on 4 Jun 2013 at 5:47

[GoogleCodeExporter]

Original comment by mom040...@gmail.com on 4 Jun 2013 at 6:35

• Changed state: WontFix

[GoogleCodeExporter]

I have no issue with absolute time, but the offset is the key thing I am 
suggesting is changed.

Let me explain what is happening:

1) Client uses REST interface to request ephemeral credentials.
2) Web service generates ephemeral credentials, including current timestamp in 
username, and returns them in the response *along with the TTL configured on 
the web server*.  The client will repeat this request if it still requires TURN 
services after this TTL period has passed.
3) Client requests TURN services, using the credentials.  TURN server checks 
that the username has not expired *using separately-configured, possibly 
different TTL value*, and checks that the password matches (based on a shared 
secret).

So we've got the TTL configured separately in each component.  If the TTL value 
differs between components, bad things happen:
- If the web service TTL is shorter than the TURN server's, the client requests 
new credentials more often than it needs to.
- If the web service TTL is longer than the TURN server's, the client does not 
request often enough, and services may be denied for valid users mid-session 
(this would be hard to diagnose).

Yes, these are just configuration issues, and easy to fix once you've figured 
out what the problem is.  However, it's good practice to simplify the 
configuration to reduce or remove the possibility of such errors in the first 
place - by changing the timestamp offset, the TTL only has to be configured in 
the web service, so you can't have mismatched values.

Original comment by gavin.ll...@crocodilertc.net on 4 Jun 2013 at 10:20

[GoogleCodeExporter]

This is actually not an issue and the scheme that you are suggesting is just a 
special case that fits into the current scheme. What you are suggesting 
actually is:

1) Use TTL=1 always on TURN server (1 second).
2) Configure TTL=<meaningful value> on the web server.
3) Set the timestamp in the web server as "current_time + TTL".

Then it will work exactly like you suggested. Just set your web server that 
way, and use option --secret-ts-exp-time=1 in the turnserver.

Original comment by mom040...@gmail.com on 4 Jun 2013 at 10:41

[GoogleCodeExporter]

Oh look, the IETF draft now clarifies the timestamp as being the expiration 
time.  What a good idea.

http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00#section-2.2

Original comment by gavin.ll...@crocodilertc.net on 1 Aug 2013 at 6:00

[GoogleCodeExporter]

I am reopening the issue.

If we have expiration time, then why we need TTL ? What TTL means in section 
2.2 ?

I'll have to ask Justin.

Original comment by mom040...@gmail.com on 1 Aug 2013 at 6:08

• Changed state: Accepted

[GoogleCodeExporter]

That will be fixed in 2.6.1.1

Original comment by mom040...@gmail.com on 1 Aug 2013 at 7:20

[GoogleCodeExporter]

Fixed in 2.6.1.1 (beta available, GA will be available in a few days)

Original comment by mom040...@gmail.com on 5 Aug 2013 at 6:30

• Changed state: Fixed

[GoogleCodeExporter]

Release 2.6.1.1 GA is available with the fix.

Original comment by mom040...@gmail.com on 9 Aug 2013 at 5:52