Unauthorized on ConnectionBind request

[Markus Wallén]

Hi,

I'm currently using version 3.2.2.4 of the turn server and I have some authorization problems when doing ConnectionBinds.

I use the shared secret solution as specified in REST Turn API.

It usually works fine, but if the allocation of one of my clients is alive for x hours that client cannot do connection binds anymore. Unfortunately I do not know when it starts to fail, but I have a hunch that it might be connected to the TTL in the username.

It seems to accept refreshes of the allocation and permission fine so I guess some parts of the server finds the username to be OK.

Here are the interesting parts of the log from the turnserver:

150184: refreshed: session id=000000000000000142, username=<1401290823:00408CDC898B>, lifetime=600

150184: user <1401290823:00408CDC898B>: incoming packet REFRESH processed, success

150244: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

150514: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

150754: refreshed: session id=000000000000000142, username=<1401290823:00408CDC898B>, lifetime=600

150754: user <1401290823:00408CDC898B>: incoming packet REFRESH processed, success

150785: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

151055: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

151324: refreshed: session id=000000000000000142, username=<1401290823:00408CDC898B>, lifetime=600

151324: user <1401290823:00408CDC898B>: incoming packet REFRESH processed, success

151325: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

151595: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

151865: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

151894: refreshed: session id=000000000000000142, username=<1401290823:00408CDC898B>, lifetime=600

151894: user <1401290823:00408CDC898B>: incoming packet REFRESH processed, success

152135: user <1401290823:00408CDC898B>: incoming packet CREATE_PERMISSION processed, success

152165: IPv4. tcp or tls connected to: 10.85.128.26:56605

152165: user <>: incoming packet message processed, error 401

152165: IPv4. Server relay addr: 10.20.2.11:3478

152165: IPv4. Local relay addr: 10.20.2.11:57572

152165: new: session id=000000000000000143, username=<1401435308:1300>, lifetime=600

152165: user <1401435308:1300>: incoming packet ALLOCATE processed, success

152165: user <1401435308:1300>: incoming packet CONNECT processed, success

152165: IPv4. tcp accepted from: 10.20.2.11:57572

152165: IPv4. tcp or tls connected to: 10.85.128.26:56606

152165: user <>: incoming packet message processed, error 401

152165: IPv4. tcp or tls connected to: 10.85.128.26:56607

152165: user <>: incoming packet message processed, error 401

152165: user <>: incoming packet CONNECTION_BIND processed, success

152165: TURN connection closed (non-mobile pattern), user <>

152165: check_stun_auth: Cannot find credentials of user <1401290823:00408CDC898B>

152165: user <>: incoming packet message processed, error 401

152174: TURN connection closed (non-mobile pattern), user <>

152174: TURN connection closed (non-mobile pattern), user <1401290823:00408CDC898B>

152174: delete: session id=000000000000000142, username=<1401290823:00408CDC898B>

152174: TURN connection closed (non-mobile pattern), user <1401435308:1300>

152174: delete: session id=000000000000000143, username=<1401435308:1300>

The user failing to do a connectionbind is "1401290823:00408CDC898B".

I've also attached a wireshark trace of the communication between my clients and the turn server.

For this test I started both clients on the same computer. One of them was started two days ago and kept its allocation alive and when I started the second one today and tried to connect to the first one, the first one gets unauthorized on the connection bind request.

This works if I restart the first client so it gets a new "fresh" allocation.

Hope someone can help me figure out why I get the unauthorized message.

I'm also a bit curious why some log entries has empty users (user<>).

Thanks!

[Oleg Moskalenko]

Markus, there were multiple fixes (including the logging facility) between your version 3.2.2.4 and the latest version (3.2.3.8). Try to upgrade to the latest version, and re-run your tests. The problem may be fixed already, or you will have better log with more explanations what is going on.

The REST API was developed for WebRTC (that uses the "classic" RFC 5766 specs). You are not using WebRTC, you are using an unusual combination - REST API with RFC 6062. It may be not tested so well. So please upgrade to the latest version, repeat the tests and post the log and wireshark capture. 

Regards,

Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

[Oleg Moskalenko]

Markus, I actually found the problem. That is really about the mismatch between the REST API specs and the RFC 6062 specs for the TCP relay.

When the client issues a CONNECTION_BIND then a new connection between the client and the server is created. The new connection is authorized as a new connection, not as a cached existing connection. So if the ephemeral credentials expired, already, then the new connection cannot be established.

I'll think what can be done. 

Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

After further investigation, I found that when we accept the new peer TCP DATA connection in the CONNECTION_BIND, we check that the username is the same as the username of the "main" TCP connection - for security reasons. Even if you are using the updated "fresh" ephemeral credentials, still then you will have error 401 - because the "fresh" username is different from the "original" username.

As a quick dirty fix, you can modify the function check_username_hash() and force it to return 1, always - and recompile the server. It will allow CONNECTION_BIND with new frash usernames.

I'll fix that and I'll issue a new release, in a few days.

Regards,

Oleg

[Oleg Moskalenko]

... so, there are two unrelated problems:

1) The new connection initiated by CONNECT_BIND, requires "fresh" username and password and it is not accepting the expired username and password. This is a grey area, because the RFC 6062 TCP connections were not supposed to be used with REST API. We either can require the clients to use the "fresh" credentials, always, or we let them use the expired credentials for the "secondary" connections. 

2) Even if the client will try to establish the new connection with "fresh" credentials, the new connection will be rejected because the username is different from the "primary" TCP connection's username.

I am actually surprised that anybody is using REST API with RFC 6062. I'll file those two bugs and I'll fix them in 3.2.3.9 version.

Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Oleg Moskalenko]

Download the version 3.2.3.9. It must fix your problems.

Oleg

Oleg

To post to this group, send email to turn-server-project-rfc5766-turn-s...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

[Markus Wallén]

Thanks a lot! I'll download the latest one and try again.

The reason for using REST API is of course that it is a very neat end clever way to handle users and passwords. I read about your reasons for using it with webRTC and thought that it would fit my case perfectly as well.

//Markus

[Oleg Moskalenko]

Markus, I found an error in my fix for ConnectionBind authorization. I'll be working on another fix, hopefully in a few days I'll post it.

Regards,
Oleg

[Markus Wallén]

Ok thanks. I'll try it out when it's ready. 

Tested the latest version and it works great. 

Regards

Markus

[Oleg Moskalenko]

The build 3.2.3.92 is ready. Please try it. It fixes some auth problems in RFC 6062.

Oleg