Subject: RE: [midcom] Working group last call - STUN (security)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 10:52:55 -0500

To be clear, I'm not speaking to self-signed certificates (which would still
require asymmetric keys, X.509 verification, TCP, the extra RTT, and incur
all of the other penalties described in my note). I'm speaking to
Digest-like password strings that would be shared by the STUN client and
server, assuming that there is some way for such a shared secret to be
communicated to the client - probably the same means by which the client
learns the domain of the STUN server. I agree that self-signed certificates
would not be a promising direction for this work to take.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 5:48 AM
> To: Peterson, Jon; [email-masked]'
> Subject: RE: [midcom] Working group last call - STUN (security)
> 
> 
> At 01:07 AM 4/23/02 -0500, Peterson, Jon wrote:
> >As far as I can tell from the draft, and my conversations with some of
the
> >authors, I suspect that each of the various ways in which a client might
> >discover a STUN server could also provide a means for a secret symmetric
key
> >to be shared with the client.
> 
> We talked about the use of self-signed certs, and it's
> probably not a good idea in this instance.  If you want to
> make sure that you're talking to who you think you're
> talking to without taking their word for it, you can't
> trust their signature, either.  With the use of DNS, even
> if you're capable of transporting the keys, you need a
> secure mechanism to push them to the STUN server along
> with the identity/credentials of the STUN client.  You 
> also would need to trust your DNS server.  It would add 
> a great deal of complexity, unfortunately.
> 
> Melinda
> 

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 25 Apr 2002 00:05:51 -0700

I am greatly in favor of finding a simpler scheme to solve this stuff. I
went and tried to implement the CMS stuff before the last IETF and I gave
up. It's not simple even if you have an S/MINE library. I predict many
people will choose to live dangerously with the current scheme. I hope I am
wrong.

One point I wanted to mention is that general security would suggest we
figure out what we are protecting against. There has not been much
discussion on this.

If the string to provision a STUN client was in the form
user:[email-masked] would it make anyone feel any better? Is this much
different than, say, imap or pop.

Is there any merit to something like using TLS to get a one time or short
lived password from the stun server for an anonymous user then use this as
the shared secret for a digest based STUN? I understand that in theory this
may not be too much different to implement than CMS but given the stuff
already in place, it might be different in practice.

Cullen

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Apr 2002 09:20:25 -0400

At 12:05 AM 4/25/02 -0700, Cullen Jennings wrote:
>the shared secret for a digest based STUN? 

I think something like this may be the best approach, which is
why I suggested using an authenticated Diffie-Helman the other
day.  TLS may be overkill for this application, but there's
a tradeoff here between time-to-implement and on-the-wire performance.
Given that STUN is intended to be a short-lived, stopgap protocol
we may choose to come down more on the side of time-to-implement.

Melinda