Subject: Re: [BEHAVE] Some questions regarding RFC5766(TURN) authentication

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Nov 2012 21:01:24 +0200

Hello,

I may not be understanding the problem well. Nevertheless, let me share the following points based on some understanding, and let's see if they are useful.

As I see, TURN is relying on a username/password based credential for message integrity protection.
Username/password is agreed between the end-points using an out-of band mechanism.

(Actually, if the protocol were relying on PSK-based credentials [ID/PSK] that'd be more secure and modular… If it is not too late, please consider that as well. Probably that's a side improvement.)

PANA can be the out-of band mechanism to populate the credential (whether it's username/password, or PSK-based) to be used with TURN. 

Input to the PANA authentication is a set of credentials.
The output is another set of credentials (e.g., session credentials). Such as ID/PSK, or username/password.
The output credentials can be used with TURN to secure the TURN signaling.

PANA end-points are same as TURN end-points. But, if the server-side end-point is not in a position to authenticate the client (because it does not have access to the user DB), then it can utilize another protocol (RADIUS or Diameter) to reach another the server that has access to such DB. PANA and RADIUS run in conjunction to perform authentication and generate session credentials.

So, we are talking about the TURN server also implementing the PANA Authentication Server functionality. In that case, TURN server does not have to know or learn the "windows credential". It'll talk to the a RADIUS/Diameter server that knows the windows credential to authenticate the client, and receive a session credential (a temporary-use credential), which gets used for securing TURN.

Alper

Thanks Tiru, 

I take a look at the PANA, it didn't clear my confusion.
My real headache is TURN needs to generate long-term credential attribute, it requires a username and password, how to choose the username?
In enterprise, I have a domain account with realm -- that is my windows credential. I would like user to use that credential, but the TURN server is most likely to be deployed in DMZ, AD-DS is always in internal network, so how can TURN get the username and password to verify my TURN authentication attribute?

Thanks,
Wilson Chen 

On Tue, Nov 13, 2012 at 12:51 PM, Tirumaleswar Reddy (tireddy) <tireddy at cisco.com> wrote:
Hi Wilson,
 
In enterprise deployments for webrtc calls TURN server is required to audit all media sessions from inside the company premises to any external peer (http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09). Hence this will be a important scenario to consider for Enterprise deployments. PANA (RFC 5191) can be used to solve the problem for both STUN/TURN servers deployed in Enterprise premises. Using PANA for other protocols like PCP is already being discussed in PCP WG. 
 
--Tiru.

From: chen wilson [mailto:oeichenwei at gmail.com] 
Sent: Wednesday, October 31, 2012 3:07 AM
To: behave at ietf.org
Subject: [BEHAVE] Some questions regarding RFC5766(TURN) authentication

RFC5389(STUN) section 10 provides 2 ways to do authentication and 

integrity check while RFC 5766 only supports long-term credential.

My question is how to integrate the long-term credential with SSO, 

for example, SAML mechanism?

2 typical user cases in my mind are:

1. Deploy TURN in enterprise just like HTTP proxy, in such a case, 

it would be better to authenticate with enterprise Active Directory;

2. Deploy TURN as a cloud service, the service providers would 

always have their own unified authentication server.

Are these 2 user cases typical for TURN?

Thanks,

Wilson Chen

---

From: chen wilson <[email-masked]>
Date: Wed, 28 Nov 2012 18:04:45 +0800

Alper,

Thank you, that is useful for me!
PANA is an option for out-of-band mechanism to negotiate a temporary
username/password (ID/PSK) between client and server, and ID/PSK is really
a good practice which I will take!

- Wilson

On Wed, Nov 28, 2012 at 3:01 AM, Alper Yegin <[email-masked]> wrote:

> RFC 5191