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

From: [email-masked]
Date: Thu, 25 Apr 2002 14:16:45 -0400

I was using a figure of speech.

If the purpose of the securing of STUN is to prevent a rogue STUN server
from hijacking a connection, wouldn't this solve the problem. Are there
other purposes that are being served by the securing of STUN?

Melinda Shore <[email-masked]> on 04/25/2002 01:43:02 PM

To:   <[email-masked]>
cc:   [email-masked]

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

At 01:26 PM 4/25/02 -0400, [email-masked] wrote:
>The range of addresses which are reasonable might even be the 'shared
>secret' that is spoken of in other messages to this list.  These can
either
>be pre-configured or delivered by a protocol. Why not, it would make STUN
>completely indifferent to cryptography?

It would be a nearly no-entropy secret.  That's not a secret.

Melinda

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Apr 2002 14:28:05 -0400

At 02:16 PM 4/25/02 -0400, [email-masked] wrote:
>from hijacking a connection, wouldn't this solve the problem. 

No, because keying material needs to be as random as possible.

Melinda

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 26 Apr 2002 12:09:44 +0100

I think what Tom is saying is, if you can deliver a secret, you can probably
also deliver a list of valid answers.

While this will not be used in the same way as a secret, it can get you to
the same result... knowing that the MAPPED-ADDRESS is an appropriate value.

One difference is who supplies the information.  In the secret case, it is
the STUN server doing the job, in the valid addresses case it is some local
device / service provider.  This difference may imply different mechanisms.

Possibly the big difference is that maybe we assume that the local
authorities are not playing the game, and so we can't rely on them providing
information.

Pete.