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

["Pete Cordell" <[e-mail]>]

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" <[e-mail]>
To: "Pete Cordell" <[e-mail]>
Cc: "Christian Huitema" <[e-mail]>; <[e-mail]>
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
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip