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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 30 Apr 2002 15:11:03 -0500

Actually, I think STUN has applicability beyond SIP - if STUN were
SIP-specific, I wouldn't have raised any concerns about CMS (since
personally I would like to encourage all SIP entities to support S/MIME).
But STUN is really targeted at a whole class of UDP applications - that
suggests to me right off the bat that mandating TCP for STUN might limit the
potential applicability of the protocol. I hope, Christian, that your
ambitions for this protocol are also larger than just SIP.

As far as I can tell (since this question was raised), the main difference
between Christian's proposal and mine is that Christian wants to mandate a
particular way of acquiring the shared secret, a way that I find a little
too expensive (still comparable to the original CMS mechanism, really). I
have a hard time seeing why the acquisition of the shared secret is not a
separable issue - though I agree there is a requirement that the acquisition
itself be appropriately secure. I see no immediate incentive to mandate any
single way of acquiring a secret.

But aside from that, I haven't detected any opposition to the actual use of
the shared secret in STUN. I think agreement on how exactly this shared
secret will be used (i.e. one-way or mutual auth, etc) should be our first
important work item in exploring this proposal. I think this question of how
you learn of keys should be a subsequent work item. In fact, I suspect a
proposal along Christian's lines would best be designed as a separate
protocol unrelated to STUN.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 12:40 PM
> To: Jonathan Rosenberg; Melinda Shore
> Cc: [email-masked]
> Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN
> 
> 
> > However, I am still confused about whether this proposal (TLS to obtain
> > shared secrets) solves the problems Jon raised. It does not eliminate
> > the need for TCP, certs, or any of the other "heavy" stuff. If you allow
> > for provisioned shared secrets rather than using TLS to obtain a
> > short-lived one, it does solve his objection of the need for PKI under
> > all conditions, although all servers would need to implement it for
> > sure...
> 
> The main advantage of the TLS proposal is that you can reuse well known
> software components, and also that you perform a lesser number of public
> key operations. In a SIP context, TLS is pretty much a "must implement"
> anyhow, so I don't think it creates a particular burden to 
> the endpoint.
> 
> <soapbox>
> I don't know whether Jon really believes that he can go away with a UDP
> only implementation of SIP, but if that is the case the security of STUN
> should be the least of his concerns. SIP over UDP can be attacked in
> dozen of creative ways, without even having to resort to fake STUN
> messages.
> </soapbox>
> 
> -- 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: Ted Hardie <[email-masked]>
Date: Tue, 30 Apr 2002 14:16:14 -0700

On Tue, Apr 30, 2002 at 03:11:03PM -0500, Peterson, Jon wrote:
> But STUN is really targeted at a whole class of UDP applications 

Before we start thinking about whole classes of UDP applications,
let's remind ourselves that developing STUN is interim work.  Taken
from the charter:

"In the interim, a solution is needed that allows applications to
operate in the presence of midcom-unaware middleboxes. To support
this, the midcom group will develop or document a protocol or approach
that allows clients to indirectly obtain address bindings from midcom-
unaware middleboxes, through communications with server elements on
the public side of the middlebox. The key goals for this effort are
rapid delivery of a simple solution (since it is an interim solution),
consistency with the midcom framework, and security. In particular,
any proposed interim approaches will address (and document) the
architectural and pragmatic concerns described in [UNSAF]."

The architectural and pragmatic concerns that are documented in
http://search.ietf.org/internet-drafts/draft-iab-unsaf-considerations-01.txt
are meant to apply to this work.  In particular, see Architectural
Considerations (Section 4.) bullet 1.:

  Precise definition of a specific, limited-scope problem that is
  to be solved with the UNSAF proposal.   A short term fix should
  not be generalized to solve other problems; this is why  "short
  term fixes usually aren't".

				regards,
					Ted Hardie