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

From: [email-masked]
Date: Wed, 24 Apr 2002 10:55:07 -0500

Depends on the manual. A free, public STUN service (I do hope there
will be such things!) might still require a password for some reason,
but publish it for all the world to know. Similarly, company internal
"setup" information on services that the company has contracted for
often includes, e.g., access passwords.

Do we need some explicitly stated requriements here so that we can
evaluate alternatives and otherwise guide our thoughts and discussions?

Jim

"Christian Huitema" <[email-masked]>@ietf.org on 04/23/2002
03:07:24 PM

Sent by:  [email-masked]

To:   "Peterson, Jon" <[email-masked]>, "Melinda Shore"
      <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: [midcom] Working group last call - STUN (security)

>
> And I must reiterate that midcom-stun-00 already assumes enough of a
> pre-existing relationship that a client is provisioned with the domain
of
> a
> server - and if that's the case, that's all the relationship we need
for
> the
> client to also be provisioned with a shared secret.

Not true. I can provision the client by copying the same string in each
of them, e.g. "stun.example.com." The string can be copied from a user
manual. Do you suggest to copy the shared secret from that same manual?

-- Christian Huitema

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

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Apr 2002 15:56:45 -0400

At 10:55 AM 4/24/02 -0500, [email-masked] wrote:
>A free, public STUN service (I do hope there
>but publish it for all the world to know.

A free, public STUN service is the one we need to be most
concerned about authenticating.  When you talk about publishing
it for all the world to know you're necessarily talking about
asymmetric crypto which brings us back to where we are.  ssh-
style host keys may be one approach but it's too easy to get
people who should know better to blindly accept new keys.

I am not ordinarily much of a fan of PGP, but this may be
an appropriate application (depending on its current status
and on the availability of trustworthy key servers).

Melinda