Subject: [midcom] New charter

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Mar 2002 16:10:55 -0500

Our charter revision has been approved and posted, and the new
version includes the pre-midcom deliverables.  Please take a gander:
http://www.ietf.org/html.charters/midcom-charter.html

Melinda

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 12 Mar 2002 08:57:50 -0800

Is there any need to run STUN over TCP? A few places in the 01 draft make it
sound like this is possible.

Cullen

---

From: Melinda Shore <[email-masked]>
Date: Tue, 12 Mar 2002 13:28:06 -0500

>sound like this is possible.

What's driving that is security mechanism.  We absolutely
need to authenticate server responses, and adding a signature
runs the considerable risk of pushing the packet size up beyond
the MTU.  

Melinda

---

From: "Email Administrator" <[email-masked]>
Date: Tue, 12 Mar 2002 12:14:37 -0700

All;

The additional burden of implementing the security features in -01.txt are
quite notable. Agreed that TCP would be preferable for MTU considerations,
but, as an author of a STUN sample implementation, I ask:

Does anyone have any pointers to libraries to aid in implementing the
signature authentication? I see this as being a very heavy bit of code.
Especially where embedded devices are concerned and where footprint size of
the client software is critical.  Unless I overlooked something in -01, I
feel that this could easily increase the code size and implementation effort
for the STUN client by an order of magnitude.

Comments? Pointers?  I have read RFC 2630 and feel very unenlightened. ;)

Alan Hawrylyshen

bcc: STUN mailing list. (address omitted, see
http://www.polyphase.ca/software/stun/ )

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Melinda Shore
Sent: 12-Mar-2002 11:28
To: Cullen Jennings; [email-masked]
Subject: Re: [midcom] STUN over TCP?

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 12 Mar 2002 15:00:42 -0500

>signature authentication? I see this as being a very heavy bit of code.

It overwhelms the rest of the protocol, but it's necessary.
Without it you've got a serious exposure that's trivial to
implement.  Note that we're going to have the same problem with
the midcom protocol.

The canonical place to go for free crypto code is OpenSSL.

Melinda

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Mar 2002 04:32:21 -0500

> >signature authentication? I see this as being a very heavy bit of code.

I understand your frustration, and you are correct that the CMS stuff
will be easily an order of magnitude more complex than the protocol it
protects.

However, there are very serious security risks unless STUN responses are
well protected. If I could inject a fake stun response, containing my
own IP address and port in the MAPPED-ADDRESS attribute, I can steal
peoples phone calls, re-route media, and so on. All sorts of really bad
things. It would be an effective back door to break security of any
application protocols that would use STUN. 

Now, we debated whether or not to use a public key mechanism to sign the
responses, or shared secret. The latter would allow us to use a simple
keyed HMAC, much, much less complicated. However, its not practical. A
server does not authenticate itself to a user with a shared secret. On
the web, its with server certificates in TLS/SSL. The simple fact is
that you will want to use stun servers in domains you don't even have a
shared secret with at all.

-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