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

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

Jon,

Whether we are a minority or not, I stand with you, at least on the
issue of the CMS for STUN being overkill. Aside from pure STUN issues,
I am also concerned about possibly setting a precedent for MIDCOM.

I may disagree with you on other things, but this one I'm with ya. I
had not chimed in until now because you so eloquently and accurately
expressed my thoughts. :-)

Jim

"Peterson, Jon" <[email-masked]>@ietf.org on 04/23/2002 05:15:46
PM

Sent by:  [email-masked]

To:   "'Melinda Shore'" <[email-masked]>
cc:   "'midcom @ietf.org'" <[email-masked]>
Subject:  RE: [midcom] Working group last call - STUN (security)

As for whether or not there's a pre-existing relationship between STUN
clients and servers - well, I'm just citing midcom-stun-00, and I'm
certainly not trying to take a hostile reading. Is there another way the
draft should be understood?

I think managing key freshness is not that scary when compared with using
CMS, considering that:

- You might also have to change your STUN domain periodically (for a while
there, the average lifespan of a web service provider seems to be about two
months) by reconfiguring your client. In some environments, it sounds like
people might even want to configure STUN on a per-service basis. In short,
I
think you will already have to reconfigure STUN clients sometimes.
- My various passwords for Internet services change with some regularity
without radically inconveniencing me. Whether or not updating a secret is
inconvenient is an interface question. STUN servers could probably even
push
fresh secrets to clients at intervals in a new STUN attribute, if we really
felt that we needed some STUN-specific way of keeping keys fresh.
- Additionally, certificates also have durations, get revoked, and so on. I
assume STUN clients will have support for certificate revocation
mechanisms?
Using PKI doesn't make these problems go away - it just moves around the
pieces a bit.

I know this must be getting tiresome, but I feel compelled to place the
difficulty of confronting these problems in the perspective of implementing
CMS (and at the heart of it, PKI). If even Christian, one of the authors of
STUN, is recommending that clients forgo the STUN security mechanism, then
I
hope you can see why I lean toward an alternative to CMS.

I do understand that I seem to be in a minority on this point, though.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 1:01 PM
> To: Peterson, Jon
> Cc: [email-masked]'
> Subject: RE: [midcom] Working group last call - STUN (security)
>
>
> At 01:50 PM 4/23/02 -0500, Peterson, Jon wrote:
> >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.
>
> I'm not sure I agree with your basic premise (pre-existing
relationships),
> and leaving aside, for the moment, scaling issues, key freshness is a
serious
> issue with manually provisioned shared secrets and one that can't be
> addressed in the scenario you describe.
>
> I think that we can probably agree that we can cut the overhead on the
> packet down to adding an HMAC or digest, but the keying problem remains
> and I'd really like to focus on that.
>
> Melinda
>
>

_______________________________________________
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 12:08:35 -0400

>I am also concerned about possibly setting a precedent for MIDCOM.

I'm more concerned about following an unfortunate precedent,
namely that because security is inconvenient we punt and let
the users deal with the consequences.  

At this point it would be helpful to hear alternative 
proposals that do not assume a pre-existing relationship 
between a server and a client.  We can do it without CMS, 
but the nature of the problem is such that we can't do it 
without involving some sort of trust broker.

Melinda