Subject: [Sip] bis-06 now available!

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Jan 2002 06:22:05 -0500

Folks,

I have just submitted an update to bis. Until it appears in the
archives, you can pick it up at:

http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.txt
http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.ps
http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.pdf

or

http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.txt
http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.ps
http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.pdf

This revision incorporates pretty much all of the comments we received
on bis-05, and brings to resolution nearly all of the open issues logged
against bis. To my knowledge, it also incorporates all questions,
comments, and clarifications requested on sip, sipping, and
sip-implementors from June 2001 till now. We still need to work through
the loose routing and herfp stuff some more, and so I expect that to
change between this version and bis-07 (which we plan on issuing within
one week). However, I think this is in excellent shape, and I am quite
confident that we are very near the finish line. 

We worked hard to track the changes, there are changebars and an
extensive changes in -06 section. Please do note the #1 item, which was
that TCP is now mandatory on all elements, due to our solution for bug
#184 for large messages. 

Comments, questions, and criticisms (and I'm sure people will have them)
are welcome.

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 12:44:15 -0800 (PST)

First of all, this section doesn't say what needs
to be implemented. It's only of the form "if you
use TLS, then you must do X."

More comments on the actual text.

  "Transport or network layer security encrypts signaling traffic,
   guaranteeing message confidentiality and integrity (note however that
   the originator and recipient of a session may be deducible by
   observers performing a network traffic analysis). The certificates
   used to encrypt traffic can also be used to provide a means of
   authentication in many architectures."

Certificates do nothing of the sort. They are used
as a means of proving identity, pure and simple;
they encrypt nothing. Key exchange is accomplished
by other means; authentication only answers the
question "who". Also: you are overloading the word
encryption; separate out confidentiality and
message integrity.

  "IPSec is a  set of network-layer protocol tools that can collectively
   be used  as a secure replacement for traditional IP (Internet
   Protocol). IPSec is most suited to architectures in which a set of
   SIP hosts (mingled user agents and proxy servers) or bridged
   administrative domains (possibly using security gateways) have an
   existing trust relationship with one another, although IPSec can also
   be used on a per-hop basis."

The exact same thing can be said about TLS. You
are not differentiating anything here, and if you
think you are, you are mistaken. I suspect that
there is some confusion about PKI's going on here.

   IPSec is generally implemented at an operating-system level within a
   host, and in many architectures it does not require integration with
   SIP applications. Any deployment of IPSec for SIP would require an
   IPSec profile describing the protocols tools that would be required
   to secure SIP and the modes in which they would operate. No such
   profile is given in this document.

Please, this doesn't have to be hard. ESP RFC 2406
in transport mode with HMAC-MD-5-NULL should be
all that needs to be supported to get
interoperability.

  "TLS  provides transport-layer security over connection-oriented
   protocols (for the purposes of this document, TCP); "tls" (signifying
   TLS over TCP) can be  specified as the desired transport protocol
   within a Via header field or a SIP-URI. TLS is most suited to
   architectures in which a chain of trust joins together a set of
   hosts."

Nonsense. TLS is used as a point to point protocol
primarily, and *anything* can be used to ignore
transitive trust problems. Again, you haven't
differentiated anything.

   "For example, Alice trusts her local proxy server, which in
    turn trust Bob's local proxy server, which Bob trusts, hence Bob and
    Alice can communicate securely."

This is a bug, not a feature.

   TLS must be tightly coupled with a SIP application. Note that
   transport mechanisms are specified on a hop-by-hop basis in SIP, and
   that in some deployments TLS might be used for only certain portions
   of the signaling path.

...and useless on the most vulerable part of the
signaling path.

   When TLS is used in a SIP application, implementers MUST minimally
   support the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. For purposes of
   backwards compatibility, proxy servers, redirect servers and
   registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers
   MAY also support any other ciphersuite.

Just as a general note, I object to anything which
makes RSA/PKI a requirement for a UA. 

Also: this predictably ignores the real problem
here which is UDP based UA's.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 12:55:33 -0800 (PST)

The bis-06 draft improperly conflates TLS with a
transport protocol. This is incorret as it should
be obvious if you want to use TLS over SCTP. Any
conflation of this kind should be removed. HTTP
got this wrong too. Better would be to have some
sort of naming scheme which says: "SIP over
transport protected by security protocol".

		    Mike

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 28 Jan 2002 16:25:07 -0600

FYI

>http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.txt

and, maybe it's just me, but pages ~224-238 have too many characters per line
on many of the lines. For example, line ~ 6 on page 226 ("user-unreserved")
appears to be approximately 126 characters wide... many others are much wider
than the typical ~76 characters per line. 

Don't know if this matters, but it seems odd...

>Comments, questions, and criticisms (and I'm sure people will have them)

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 28 Jan 2002 19:56:48 -0500

Very strange. The section should have / instead of |, too. I suspect
that CVS acted up on us.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 12:07:13 -0500

> transport protected by security protocol".

Are you arguing that instead of:

sip:user@domain;transport=tls

it should be:

sip:user@domain;transport=sip-over-tcp-protected-by-tls?

I think "tls" is better since its 3 bytes, compared to 29. 

I suppose what you really mean is that the text needs to indicate that
TLS is not a transport, but we use the transport=tls parameter to
indicate that the UAC needs to use TCP protected by TLS. 

Or are you arguing something else?

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Jan 2002 09:33:56 -0800 (PST)

> Or are you arguing something else?

   I'm saying that your taxonomy is wrong. It should
   be something of the form:

   transport=tls.tcp or transport= tls.sctp

   then you can also have things like:

   transport=ipsec.tcp or transport=foo.udp

   Even if you don't like the ipsec part, we already
   need to consider tls over sctp. What's currently in
   bis makes adding that pretty kludgey.

		   Mike