Subject: [BEHAVE] TLS mutual authentication for STUN

From: "BREARD Gael RD-SIRP-ISS" <[email-masked]>
Date: Mon, 20 Aug 2007 16:03:30 +0200

Hi,
 
(My apology if this topic has already been addressed.)
 
STUN seems to only allow authentication based on a shared secret. 
(And especially TURN requires it)
 
There is some scenario we do not have shared secret but a PKI architecture.
 
Why do we not allow the use of TLS mutual authentication for STUN (and so authorize it for TURN) ?
 
Moreover, when using TLS with "server only authentication", is it really useful to challenge each request ?
 
Gaël

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 20 Aug 2007 18:01:43 +0300

> (And especially TURN requires it)

STUN defines three authentication profiles:
- long-term client credentials
- short-term client credentials
- no client credentials

STUN is only a framework... You can specify a usage that does not require 
STUN-level client authentication, and then run it on top of TLS and use 
TLS-level authentication. Or, you can use STUN-level authentication, and you 
have to specify how the credentials are obtained (e.g. ICE gets them from the 
SDP).

TURN is currently out of sync in how it obtains credentials, so it's difficult 
to comment on whether it does or does not allow something.

> Why do we not allow the use of TLS mutual authentication for STUN (and so

STUN recommends that the client authenticates the server when TLS is used.
This is pretty much common sense, otherwise you might as well not use TLS.

It does not say the server cannot authenticate the client. Of course, the spec 
does not require that, since most people use login/password pairs rather than 
client-side certificates.

> useful to challenge each request ?

If there are no client-side certificates, the server needs to authenticate the 
client with *something*.

-- 
Rémi Denis-Courmont

---

From: BREARD Gael MAPS-ISS <[email-masked]>
Date: Mon, 20 Aug 2007 17:27:02 +0200

> to comment on whether it does or does not allow something.  
Ok, my concern was specifically about this sentence (turn-04 §6.1.2):

Allocate requests MUST be authenticated, and
   furthermore, MUST be authenticated using either a shared secret known
   between the client and server, or a short term password derived from
   it.

which seems to insist on the "shared secret" necessity.

I only think it would be a good idea to allow (in TURN draft) no "STUN 
authentication" for allocate requests sent over TLS with mutual 
authentication.

> If there are no client-side certificates, the server needs to authenticate the 
I agree, but it needs to be done (in principle) only *one* time in all 
the TLS session (not at each request).
(Though I understand, it's simpler to do the same than in TCP case.)

Gaël

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 21 Aug 2007 09:06:14 +0300

On Monday 20 August 2007 18:27:02 ext BREARD Gael MAPS-ISS wrote:
> > TURN is currently out of sync in how it obtains credentials, so it's
> > difficult to comment on whether it does or does not allow something.
>

You need a shared secret to secure UDP or TCP STUN requests, and it would be 
pretty suboptimal to use TLS for bulk relayed traffic, *except* when you have 
to use TLS because HTTP CONNECT is your only way out. In fact, RTP over TLS 
very much sucks and is really the fallback of fallback cases.

If you want to encrypt the bulk content, you'd better do it end-to-end (with 
SRTP or DTLS), not end-to-relay.

Hence, if you want to use a PKI for authentication, what you would want is the 
infamous Shared Secret Request. It's been purposedly removed because nobody 
ever implemented it. And with the implementor hat, if it were ever to be 
reintroduced, I would rather it could be done over DTLS, than need a TCP 
connection to the relay.

-- 
Rémi Denis-Courmont

---

From: "Gaël Bréard" <[email-masked]>
Date: Tue, 21 Aug 2007 10:20:17 +0200

> very much sucks and is really the fallback of fallback cases.

I agree.  (note: with some proxy/fw you do not need TLS after HTTP CONNECT)

> infamous Shared Secret Request.

yes...

It's been purposedly removed because nobody
> reintroduced, I would rather it could be done over DTLS, than need a TCP

except when  HTTP CONNECT is your only way out ;) ...

Thanks for your answers.

Gaël