Subject: RE: [Sip] B2BUA - Security - (Midcom Reqts?)

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Dec 2002 18:27:59 -0500

My favorite property of S/MIME protection for SDP is middlebox detection.
I'd like to know if some putatively benevolent middlebox is attempting to
'help' my session media get where it needs to go.

Although the midcom working group may favor middlebox transparency, I do not
believe that should be a goal of this working group. SIP is a peer-to-peer
protocol. While applications of SIP are free not to apply security
properties to SDP if they wish, I think it is unarguably valid for a SIP
user agent to secure SDP, even if that runs the risk of troubling
middleboxes.

In any event, there already is a secure way to allow encryption and
authentication via middleboxes - you can apply security properties to the
SDP using a certificate held by the middlebox (or its controller as the case
may be). If you actually intend for the middlebox to be in the path of your
media, this seems like a reasonable solution. I don't think we need anything
more.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 7:35 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Sip] B2BUA - Security - (Midcom Reqts?)
> 
> 
> Jonathan,
> 
> Perhaps as you say, we should take a step back.
> 
> I want to address midcom scenarios shown in the time line shown in section
> 7.1. of RFC 3303 (Midcom framework) and 2.3.1 and 2.3.2 in
> draft-ietf-midcom-scenarios-02.txt.
> 
> The current security situation in SIP makes this problematic, and I don't
> think there is any chartered item in SIP or SIPPING to address this.
> 
> I would like there to be a secure mode of operation even for midcom
systems
> that allows encryption and authentication.  I would imagine that the IESG
> would block midcom if it did not allow such security.
> 
> I think we know enough from a SIP point of view what a midcom solution
will
> need to do to a SIP system.  Therefore, I believe we should start work on
> this sooner rather than later.
> 
> Perhaps the way to go is for the midcom group to produce a requirements
> draft detailing what it needs from the SIP world (in its broadest sense)
> that can be put into SIPPING and hopefully lead to a chartered item.
> 
> To me the successful conclusion of midcom seems dependent on this sort of
> work being done.
> 
> Pete.
> 
> ----- Original Message -----
> From: "Jonathan Rosenberg" <[email-masked]>
> To: "Pete Cordell" <[email-masked]>
> Cc: "Christian Huitema" <[email-masked]>; 
> <[email-masked]>
> Sent: 06 December 2002 06:45
> Subject: Re: [Sip] B2BUA - Security
> 
> 
> > inline as always. But, first, a question. Pete - what are 
> you after? Are
> > you actually trying to convince the working group to disallow
> > encryption/authentication over SDP so that your 
> b2bua-thingy can modify
> > it?? As I have tried to argue in my session policy draft, 
> there are a
> > LOT of issues with intermediary modification of media 
> information, many
> > of them related to the kind of things OPES has been dealing 
> with. You
> > need to consider the problem more broadly.
> >
> >
> > Pete Cordell wrote:
> >
> > >>1. modifying SDP in transit to point media streams to an 
> intermediate
> > >>recording device, allowing attackers to establish wiretaps
> > >
> > >
> > > This is only partially successful.  Encryption of RTP is the only
> complete
> > > solution.
> >
> > True.
> >
> > >
> > >
> > >>2. downgrading any SRTP keying done in SDP, so that the 
> media itself is
> > >>not encrypted or integrity protected (this came up during 
> the mmusic
> > >>session in IETF as a driver for S/MIME)
> > >
> > >
> > > I don't think you need to encrypt the entire SDP body to 
> prevent key
> > > downgrading.  In the absence of any other contraints that 
> might be a
> simple
> > > route to go, but if it causes problems (as it is) then we 
> should look at
> > > other ways.
> >
> > You need to protect the key exchanges. I am trying to 
> establish that a
> > lot of the information in SDP needs to be protected e2e.
> >
> > >
> > > As an aside - This is the sort of reason I would like to 
> get this sort
> of
> > > thing on the agenda.  It's not that its not possible to 
> enable SIP to
> meet
> > > these requirements, there's just not a desire to do among 
> the core SIP
> > > people.  I know why they don't want to do it, but I also 
> think that SIP
> > > fails to address a whole class of problem as a result.  
> In the long run
> I
> > > think that will be detrimental to SIP.
> >
> > I have no idea what "it" is in this aside.
> >
> > >
> > >
> > >>3. launching a DoS attack by sending everyones voice 
> traffic to the
> > >>intended target. You get huge amplification gains here. 
> Very appealing
> > >>for hackers!
> > >
> > >
> > > Don't need SDP to do that.  I could just rip out the 
> entire SDP and put
> in a
> > > new version.  I might not get the ports right, but I 
> could probably
> cause
> > > enough damage to get my kicks.
> >
> > If you rip it out and replace it, and the UA is requiring 
> signed SDP,
> > then this won't work.
> >
> > Another interesting attack I thought of, is to modify the 
> SDP to send
> > the RTP to a relay, which does forward it to the right 
> destination, but
> > only after inserting 100ms of delay. The result is that the 
> conversation
> > takes place, but at lousy quality. Why do this? Maybe a way for one
> > provider to convince customers of another provider to 
> switch. Dropping
> > the packets outright might be too overt of an attack, but a subtle
> > increase in delays... just a thought.
> >
> > >>Confidentiality is only one property of security. I am much more
> > >>concerned about message integrity.
> > >
> > >
> > > Integrity of which bits?  And are you sure that 
> maintaining integrity
> buys
> > > you anything except for in a few special cases?
> >
> > Definitely.
> >
> > I don't want someone removing my video stream my session.
> > I don't want someone to modify my codecs, forcing me to use a lower
> > quality one when a better one would actually work.
> > I don't want someone to receive my media when I intended it for the
> > party I called.
> >
> > And so on. The above concerns are real, and cover a good set of the
> > information in SDP.
> >
> > Let me pose the question in reverse. What information in 
> SDP do you feel
> > is NOT worth protecting?
> >
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (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
> 
_______________________________________________
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