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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Jan 2002 12:17:42 -0600

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. If
the headers are merely informational (like the Subject header), then I think
it's pretty clear how you'd use them informationally: the client displays
the 'inner' one to the end user. I put in one example of inserting a
different From header in an encrypted body to provide rudimentary privacy;
we don't provide that so that you can check and make sure that the tag on
the From header is the same, but because the outer header says 'Anonymous'
and the inner one says your real name. Again, a UA could display the 'inner'
head to the user, but use the 'outer' one for all protocol activity.

This is something we need to make explicit, I agree.

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.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2002 8:52 AM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; [email-masked]
> Subject: Re: [Sip] ambiguities with S/MIME
> 
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> 
> > > 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.
> 
> Help me out here; why would I want multiple certs for signing 
> because of
> forking? 
> 
> > 
> > >
> > > 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.
> 
> 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.
> 
> 
> -- 
> 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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 15:05:27 -0500

"Peterson, Jon" wrote:
> 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.

> multiple times. Simplest answer is to limit to one signature, I think.

Agreed.

-Jonathan R.