Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 9 May 2002 18:59:27 -0500

And, you haven't yet told me what are the other threats to the STUN service
that the Digest-ish 4-way handshake (w/ client, server nonce etc) cannot
mitigate, for which you need TLS (w/ all its expensive bells and
whistles)-based secret download.
 
And, TLS is useless for UDP devices, which many, many IP phone vendors
(including yourselves and ourselves) wouldn't presumably throw away in the
time-span of pre-Midcom. 
 
And, Allison (and the IAB) doesn't want us to deploy STUN servers all over
the public Internet & doesn't see any issue with the shared secret approach.
 
And, finally, I don't see the reason for not being able to add the necessary
STUN attributes and worry about the secret download later (or in parallel).
 
So, what's the problem?

-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH] 
Sent: Thursday, May 09, 2002 6:23 PM
To: 'Melinda Shore'; [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

> -----Original Message----- 
> From: Melinda Shore [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Thursday, May 09, 2002 5:39 PM 

> 
> 
> At 05:20 PM 5/9/02 -0500, Sanjoy Sen wrote: 
> >Because, we want to avoid the TLS handshake that would add 
> more roundtrips, avoid the DH or RSA key exchange and avoid 
> any Certificate download. 
> 
> You're still assuming pre-provisioned symmetric keys.  That's 
> not a reasonable assumption. 
> 
I don't understand. The exchanges required as described above are
unavoidable if you use TLS. The TLS handshake protocol itself comprises of
at least 8 messages exchanged (& depending on situations, it can be more) -
clientHello, serverHello, serverHelloDone, clientKeyExchange (RSA or DH),
clientChangeCipherSpec, clientFinished, serverChangeCipherSpec,
serverFinished.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 9 May 2002 17:28:45 -0700

> the public Internet & doesn't see any issue with the shared secret approach.

I have not seen any discussion on the IAB list about STUN that
discussed the shared secret approach.  Note that I am not speaking for
the IAB, but I do not personally see a reason why you would draw the
conclusion of IAB consensus around "doesn't see any issue with the
shared secret approach".  The UNSAF document represents the last
public document of IAB consensus and it does not mention that approach
by name or (to my reading) implication.  If Allison has made a
statement about the shared secret approach, I also missed that in my
reading of the mailing list and would be happy to have a pointer.

			regards,
				Ted Hardie

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 May 2002 09:58:52 -0400

>reading of the mailing list and would be happy to have a pointer.

In conversation with me and, apparently, with Sanjoy Allison
said that because STUN is to be a short-lived protocol (my other
.sig is "Software longa hardware brevis") and because we don't
want to encourage ubiquitous deployment we don't want to add
features to it that would tend to do that.  NOTE THAT I AM
REPEATING MY UNDERSTANDING OF WHAT WAS SAID, NOT WHAT WAS ACTUALLY
SAID.  If Allison wants to weigh in on this that would be great,
but I don't think that attempting to bolster an argument in
favor of a poor security solution by paraphrasing what was said
in a conversation none of us was privy to is a very good idea.

In the meantime, we already know of one large vendor who is planning
on a large STUN deployment and whose needs would not be met by
pre-provisioned keys.  That, I think, needs to be the acid test
here, not a third-hand report of a casual conversation with an
Area Director.

Melinda