Subject: RE: [Sip] B2BUA

From: "Christian Huitema" <[email-masked]>
Date: Tue, 3 Dec 2002 08:35:28 -0800

> > [MB]: Some of this, of course, will lead us back to the
> > list of the reasons why some folks consider these things "evil", ...
> 
> I do not remember whether anyone has ever said that B2BUA is evil
> things. What I remember is that the dumping of the B2BUA functionality
> in the name of SIP Proxy is an evil thing.

The real issue in all this is security. Many security folks believe
that, in order to get proper security, the body of the signaling
messages should be signed, and possibly encrypted. In that logic, the
proxies only manipulate the information exposed in the SIP header, which
can be as little as the pair of source and destination URL.

Any intermediary that attempts to "rewrite the SDP" has to somehow
insert itself in the end-to-end security exchange; many security folks
will resent that as "breaking end-to-end security". Insofar as SDP
rewriting attempts to provide a legitimate service, the challenge is
thus to provide the service in such a way that it does not require
breaking end-to-end encryption.

-- Christian Huitema
_______________________________________________
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: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 12:55:18 -0000

Christian,

I'm afraid I think that end-to-end security of SDP is a complete red
herring.

I would say that encrypting and / or integrity checking of SDP alone
achieves absolutely no security benefit.

SDP really does two things.  It specifies transport addresses and chosen
codecs.

Let's assume that you do encrypt the SDP and I can't read it.

I can have a good guess at the transport addresses in use from many of the
other fields in SIP such as via lines, To, From, uri, contact, route etc.

By analysing the RTP traffic, I can easily find out what codec is being
used, either because the packet tells me, or from other statistical
characteristics.

I have therefore discovered, with very little effort most of what I would
find useful in SDP.  (Ironically sending stuff to a media relay would make
this slightly harder!!!)

If you want security of the media, then you have to encrypt and integrity
check the RTP.

Encrypting SDP simply burns CPU cycles!!!

(Put another way, encrypting SDP is another form of security by obscurity.
And we all know what that means.)

(Note that it may make sense to encrypt other bodies types, such as those
that contain HTML, but this is a different case.)

Pete.

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "Roy, Radhika R, ALASO" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: 03 December 2002 16:35
Subject: RE: [Sip] B2BUA

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 05 Dec 2002 09:45:06 -0500

> SDP really does two things.  It specifies transport addresses and chosen
...and carries keys for SRTP...hmmmmmmmm........

> other fields in SIP such as via lines, To, From, uri, contact, route etc.
Uh huh, sure. My experience is that you can only guess with reasonable 
probability by knowing the implementation details of the UAs. I remember we 
changed the RTP port allocation algorithm on IOS and all of a sudden people 
started screaming because their ACL filters "stopped working". Trying to 
beat the devil seem a pretty poor direction.

> used, either because the packet tells me, or from other statistical
Really? Maybe for the standard codecs but why on earth bother?

> If you want security of the media, then you have to encrypt and integrity
or put it through an IPSEC tunnel. What's the point?

> Encrypting SDP simply burns CPU cycles!!!
No, it prevents media hijacking by a MITM.

> And we all know what that means.)
Disagree vociferously.

> that contain HTML, but this is a different case.)
Dave.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Dec 2002 11:28:27 -0500

> achieves absolutely no security benefit.

Really?? Wow. I actually think it prevents the most devastating attacks 
against SIP. These include:

1. modifying SDP in transit to point media streams to an intermediate 
recording device, allowing attackers to establish wiretaps

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)

3. launching a DoS attack by sending everyones voice traffic to the 
intended target. You get huge amplification gains here. Very appealing 
for hackers!

> other fields in SIP such as via lines, To, From, uri, contact, route etc.

Confidentiality is only one property of security. I am much more 
concerned about message integrity.

> And we all know what that means.)

I have no idea how you would arrive at such a conclusion. Security 
through obscurity means that information is not cryptographically 
protected, but encoded with a known process that is just a bit 
complicated. By definition, this is not encryption. Perhaps you have 
discovered some new flaws in encryption technology?

-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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Dec 2002 19:16:20 +0200

> recording device, allowing attackers to establish wiretaps

True. But if you are worried about this, perhaps you should use
strong end-to-end media security instead of just relying on the
IP addresses to stay unchanged?

If the attacker is there to change the SDP, he can be there to intercept
the cleartext media streams as well.

> session in IETF as a driver for S/MIME)

I think all SRTP keying mechanisms should be written to be secure
against downgrade attacks. And as far as I know, they are. (With the
exception of downgrade between MIKEY and a hypothetical future key
management protocol that also runs within SDP. But that issue is being
addressed as we speak...)

> intended target. You get huge amplification gains here. Very appealing 

Yes. This is serious. Interesting attack!

Jari

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 17:05:12 -0000

Dave,

Please see inline...

Pete.

----- Original Message -----
From: "David R. Oran" <[email-masked]>
To: "Pete Cordell" <[email-masked]>; "Christian Huitema"
<[email-masked]>
Cc: <[email-masked]>
Sent: 05 December 2002 14:45
Subject: Re: [Sip] B2BUA - Security

> ...and carries keys for SRTP...hmmmmmmmm........

I assumed the keying used some sort of Diffee-Hellman type technique, and so
this wouldn't be an issue.  I will look into this.  Maybe that area of SDP
usage could be improved.

> beat the devil seem a pretty poor direction.

Real time ACL control is very different issue to working out which RTP
stream goes with what SIP session at some point.

> Really? Maybe for the standard codecs but why on earth bother?

Your point is?

> or put it through an IPSEC tunnel. What's the point?

IPSEC would have trouble with NATs etc.  The point is to encrypt the media
some way.  I'm not seeing your point.

> No, it prevents media hijacking by a MITM.

No - not really.  It helps in some MITM situations but it is not a complete
solution.

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 17:19:59 -0000

Jonathan,

Please see in-line...

Pete.

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "Christian Huitema" <[email-masked]>; <[email-masked]>
Sent: 05 December 2002 16:28
Subject: Re: [Sip] B2BUA - Security

> recording device, allowing attackers to establish wiretaps

This is only partially successful.  Encryption of RTP is the only complete
solution.

> 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.

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.

> intended target. You get huge amplification gains here. Very appealing

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.

> 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?

> complicated. By definition, this is not encryption.

That's what I meant - yes.  Hiding the SDP does not get you security.

> Perhaps you have

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Dec 2002 01:45:45 -0500

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.

> This is only partially successful.  Encryption of RTP is the only complete

True.

> route to go, but if it causes problems (as it is) then we should look at

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.

> think that will be detrimental to SIP.

I have no idea what "it" is in this aside.

> 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.

> 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.

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 6 Dec 2002 15:35:04 -0000

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.

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Dec 2002 16:29:13 -0800

> this wouldn't be an issue.  I will look into this.  Maybe that area of 

see draft-baugher-mmusic-sdpmediasec-00.txt

thx,
-r

>>> I can have a good guess at the transport addresses in use from many 
>>> of
> the
>> probability by knowing the implementation details of the UAs. I 
>> remember
> we