Subject: [midcom] Open issue in STUN

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Mar 2002 12:24:27 -0500

Folks,

As I mentioned previously, I managed to get a rev of stun in before the
I-D deadline. Until it appears, you can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-01.txt

The changes since -00 are:

* alignment of parameters on natural boundaries (previously, 32 bit
addresses were not 32 bit aligned). Note that this will result in
incompatibility between implementations based on -00 and -01.

* addressing UNSAF considerations

* CMS and TCP SYN attack style prevention stuff

* added some missing attribute values

* clarified semantic of CHANGED_ADDRESS

* split reference section, IANA considerations, general prep for IESG
consideration

One issue worth broader list discussion, was the design teams
conclusions on security. stun-00 had no security mechanisms. However, we
found a security vulnerability that needed addressing. An attacker could
inject a fake stun response, containing a MAPPED-ADDRESS that pointed to
itself. THis would allow the attacker to fool the victim into giving out
the wrong address. The attacker could use this to steal phone calls, for
example, by having the media and/or signaling get routed to them instead
of the caller. 

To address this, we decided that the appropriate mechanism was to
provide authentication and itegrity of the response. Since the response
will be coming from a server, typically run by a service provider on the
public Internet, we chose to provide for a CMS-based public key
signature mechanism over the response. There is no client
authentication. However, to avoid DDoS attacks where an attacker can
force a public key operation with an unauthenticated request, we added
support for a cookie mechanism, similar to that used to prevent TCP SYN
attacks.

We debated, but chose not to additionally provide a shared-secret based
integrity/authentication scheme, since we felt it was not approrpriate
or scalable for network servers to autehnticate themselves to end users
with a shared secret. We also wanted to reduce the set of options. 

Sadly, the CMS aspect of the protocol will be the most complex to
implement, far harder than the protocol itself. However, no one ever
said security was easy.

The design team felt it was important to get broader group input on this
design choice. I think most of the remaining changes in stun do not
require any discussion, but comments are welcome of course.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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