Subject: [Sip] ambiguities with S/MIME

From: Rohan Mahy <[email-masked]>
Date: Tue, 29 Jan 2002 18:01:06 -0800 (Pacific Standard Time)

Hi,

In discussions with various folks about S/MIME, I think the current text
on S/MIME is a great first start, but still too ambigous to build a robust
implementation.  Also I'm concerned that nobody has implemented this yet.
I think splitting this out until we have a few interoperable
implementations and have tested this at SIPit is a good thing.

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.

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?

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

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

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 30 Jan 2002 11:54:40 -0800

>From: Michael Thomas <[email-masked]>  
>
>A UA always has the option of speaking end to end
>which completely mitigates the MITM problem. 

Not so in the presence of NATs, with which many of us are 
afflicted.

While I tend to agree that SMIME would be better described in 
another document, I still think that we should be prepared to 
give a credible description of *a way* to use it end-to-end.  
[Since Jon went to great pains to avoid the PKI minefield 
here.]  The IESG may request the inclusion of such a 
description in bis.

We should try to identify specific problems and ambiguities 
with what Jon proposed, and preferably *solutions* and 
proposed clarifications.  If we discover insurmountable 
technical obstacles, then we can explain the specifics to the 
IESG, but at the moment we just have general objections and a 
few specific ambiguities that Jon is trying to address.

thanks,
-rohan

>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
>
>Peterson, Jon writes:
> > 
> > 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
> > 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
> > 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.
> > 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.
> > > Sip mailing list  
https://www1.ietf.org/mailman/listinfo/sip
> > Sip mailing list  
https://www1.ietf.org/mailman/listinfo/sip

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Jan 2002 16:58:47 -0600

Let me say off the bat that I agree, we need to clarify this. I think this
goes back to the integrity issue. Some headers can be modified in transit,
some cannot. If it is legitimate for a proxy server to modify a header in
transit, we can say that a change in the value of such headers should not be
considered an integrity breach (which we say in the text today). Today the
only 'mutable' headers we list (and we're drawing only from headers that
appear in bis06) are:

Request-URI
Via
Record-Route
Route
Max-Forwards
Proxy-Authorization

Everything else is potentially an integrity breach.

For encryption, you might want to treat these things differently -
presumably, your intent in encrypting a 'message/sip' is to hide the value
of some headers, so you presume that some of the headers will necessarily
have different values. Today we don't really say anything about the
applicability of this mechanism to particular headers Unclear why someone
would want to obfuscate the CSeq (grin) - maybe it would be easier to list
the headers in bis06 that it would make sense to obfuscate, which include, I
think:

To
From
Subject
Reply-To
Organization
(of course, all Content-* headers)

Then, we can say can say that for encrypted 'message/sip' bodies, any change
to headers other than these, and those included on the integrity list above,
may be an integrity breach.

Does this make sense as a way of casting the problem? Or is there a way to
get any better leverage on it? Anything that needs to be added to or
subtracted from either list above?

Jon Peterson
NeuStar, Inc.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2002 12:05 PM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; [email-masked]
> Subject: Re: [Sip] ambiguities with S/MIME
> 
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> > The question is really how you 'use' the inner headers. Most headers
> > don't
> > have any end-to-end semantic aside from the establishment 
> of a dialog
> > ID.
> 
> Well, there are things like CSeq for sequencing. OK, so here is an
> example of what I mean. A sends B an INVITE, with a signed mime body.
> They sent with CSeq 5. An attacker intercepts, modifies the outer CSeq
> to 500, changing nothing else, and keeping the signature. This arrives
> at the UAS. The UAS still uses the outer headers, so it updates the
> remote CSeq to 500. Now, the UAS will reject any subsequent messages
> from the UAC, since they will have a CSeq that is too low.
> 
> This is similar to a registration attack which I think James pointed
> out. I suppose the same argument I made there could apply here, which
> is, that the middleman could just instead through away the packet with
> the same result, and that is an insurmountable attack. 
> 
> However, the point is really that it is not obvious that there are no
> security consequences with using some of the non-informational headers
> from the outside. I don't think this is a hard problem to fix, we just
> need to think it through and make sure we know whcih ones are 
> the right
> ones to use, and if there is a general way to describe it.
> 
> 
> > On the multiple signatures thing, I agree there aren't very 
> many obvious
> > reasons for signing a message with multiple identities (any mental
> > problems
> > aside). Maybe if the originating user suspect that they 
> were known by
> > different identities to different potential recipients of 
> the request
> > (not
> > sure why that would be, admittedly), they might want to 
> sign the message
> > multiple times. Simplest answer is to limit to one 
> signature, I think.
> 
> Agreed.
> 
> -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: Rohan Mahy <[email-masked]>
Date: Wed, 30 Jan 2002 16:07:59 -0800

inline...

---- Original message ----
>Date: Wed, 30 Jan 2002 16:58:47 -0600
>From: "Peterson, Jon" <[email-masked]>  
>Subject: RE: [Sip] ambiguities with S/MIME  
>To: "'Jonathan Rosenberg'" <[email-masked]>
>Cc: "'Rohan Mahy'" <[email-masked]>, [email-masked]
>
>

I can think of valid reasons for these to be private as well:

Accept-*  (especially Accept-Language)
Authorization (username)
*-Info
Expires
In-Reply-To
Priority
Require/Supported/Unsupported
Retry-After
User-Agent/Server
Warning

The following seem to be silly to encrypt, and maybe should 
be ignored:

Call-ID
Contact
CSeq
Date
Min-Expires
MIME-Version
Proxy-*
RAck
RSeq
Timestamp
WWW-Authenticate

thanks,
-rohan