Subject: RE: [Sip] ambiguities with S/MIME

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 29 Jan 2002 23:15:41 -0600

Our decision to include more substantial text for S/MIME usage in bis06 was
motivated by the absence of the PGP mechanism that appeared in RFC 2543, and
by a set of known threats connected to the inspection or modification of
bodies by intermediaries. Let's face it - not too many protocols grant as
many opportunities as SIP for men-in-the-proverbial-middle to muck with
messages. There was a general feeling that securing things end-to-end should
happen at the level of MIME bodies, and S/MIME is sort of the natural (read:
only) choice. We feared that without any mechanism for body security (or
some mere lip-service along the lines of the bis05 text) it could be argued
that the SIP standard doesn't provide a reasonable overall security story.

On these grounds, despite the fact that the text undoubtedly has some
blemishes, I think we should try to go forward with it. I think we can
address the specific ambiguities you raise below without terrific effort
(some notes below). I think our best bet is to get this text into as good a
shape as we can and to go forward with it. We'd definitely appreciate any
further comments along these lines.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 6:01 PM
> To: [email-masked]
> Subject: [Sip] ambiguities with S/MIME
> 
> 
[snip]
> example ambiguities:
> 
> it might be useful (especially with forking) to send the same 
> message/sip
> signed with various certs that all correspond to me.  how a UA would
> handle multiple message/sip bodies is unclear.

This has been raised a couple of times in connection with the S/MIME
mechanism. Probably the simplest way of resolving this concern is to
recommend that each S/MIME body be signed with only one cert, and to leave
any behavior for handling multiple certs undefined (or at best suggesting
that the outermost signature be treated as the single cert for this body).
Same for multiple 'message/sip' bodies.

> 
> if I can replace the "outer" To and From headers, which tags 
> do I use in a
> Replaces header?  If I receive an authenticated reINVITE in the clear
> which operates on the "inside" To/From/Callid/tags, is this valid?
> 

This is good - I certainly wouldn't want someone to get the impression that
tunneling a message means that we're trying to set up some sort of second
session based on the encapsulated signaling, or something. We should
probably add a notice that the headers of an encapsulated 'message/sip' body
are there for informational purposes and have no session semantics - they
don't have dialog IDs or literally constitute some sort of tunneled session
or what have you. Any session operations, including using things like
Replaces, target the 'outer' headers. The value of using a transport
protocol (in this instance SIP) to tunnel a SIP dialog between two fixed
endpoints has been discussed in the past (notably in SIMPLE recently), and
not really found very useful - two fixed endpoints don't really need the
sorts of services that SIP provides; they might as well just trade MIME
bodies.

> obviously some headers shouldn't get replaced:
> Via, Route, Record-Route  are there any more?

There is some text in 21.4.1 that speaks to the fact that some headers can
be modified in transit without this constituting a breach in integrity.
Realistically, this text should be popped up the stack to 21.4, since it
applies to both types of tunneling. All of these headers are mentioned
there.

> 
> thoughts?
> 
> thanks,
> -rohan
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 30 Jan 2002 10:36:28 -0500

"Peterson, Jon" wrote:

> many opportunities as SIP for men-in-the-proverbial-middle to muck with

Well, minor protocols like HTTP or SMTP come to mind, but I guess they
are not widely used :-)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 11:31:46 -0500

> Well, minor protocols like HTTP or SMTP come to mind, but I guess they

In Jon's defense, a user-to-user protocol like SIP has far more
vulnerabilities than HTTP; after all, if it were as easy as HTTP, why
would we need anything beyond TLS+digest? I think  we all agree we do
need more than that. I'll further add that SIP is also harder than SMTP
because (1) of its reach all the way to the user, (2) its creation of
session/dialog state which can be affected by subsequent messages. The
second point being the real rub.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 11:51:45 -0500

"Peterson, Jon" wrote:

> Same for multiple 'message/sip' bodies.

Help me out here; why would I want multiple certs for signing because of
forking? 

> sorts of services that SIP provides; they might as well just trade MIME

Hmm, I think this one requires more thought. If you never actually use
the inner headers, how does that prevent against an attack where an
attacker modifies the outer ones in transit? Of course, there are legit
cases where such things might happen (b2bua, for example); I suppose in
these cases, a B2BUA shouldn't try to carry signatures through it
though. 

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Jan 2002 10:40:45 -0800 (PST)

A UA always has the option of speaking end to end
which completely mitigates the MITM problem. Since
SMIME is imperfect, its unintended consequences
are not well understood, and the actual need for
e2e transport is questionable vs the end to middle
problem where there is pretty clear evidence of
need (cf the privacy thread), I think that SMIME
should be removed from the bis draft and taken up
later. It's removal right now would not prevent
anybody with experimenting with its use. Normative
text could do a great deal of damage if it is
wrong. Considering how late this has been added, I
will without hesitation say that the 06 text for
SMIME will get many things wrong; this is just a
trusim of computer engineering.

		Mike