Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 25 Feb 2002 23:05:03 -0600

Forbidding proxies to modify message bodies does not improve security; it's
the other way around. The fact that we can secure messages bodies end-to-end
entails that proxies may not be entitled to modify bodies.

Mostly, this just reinforces the fact that bodies are intended for
end-to-end use. Many of the misconceptions about this issue arise from a
belief that the operators of proxy servers are necessarily a privileged
participant in a SIP network. Actually, if you are a 'network operator', and
you want to inspect and modify bodies, you must have a trust relationship
with users - they must accept that you, the network operator, are the
appropriate recipient of SIP message bodies, and they must secure MIME
bodies with that expectation (any encrypted bodies must be explicitly
intended to be decrypted by the network operator). In that sense, the
network operator becomes the destination of the request, and thus more or
less a user - and this is why the discussion naturally transitions to
B2BUAs. I think this in no way diminishes the value of network-based service
that require access to SIP message bodies - it just shows that if you want
to offer these sorts of services, you require that users trust you in a way
that they aren't asked to trust proxy servers, which operate only on
headers.

Jon Peterson
NeuStar, Inc.

_______________________________________________
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: Wed, 27 Feb 2002 10:29:30 -0000

I keep thinking about SMTP, which has survived for years without any real
security being applied, even though there have been quite a few masquerading
viruses out there, and security solutions do exist.

As a result I actually think there is more trust floating around than there
at first appears.

Mail works most of the time because, when I give my message to an outbound
proxy, I'm implicitly saying that I trust you to do the right thing with
this (or maybe the administrator does), otherwise I wouldn't send the
message there.  Likewise, the outbound proxy may decide to send the message
to a firewall proxy because it trusts it to do the right thing.

At the other end, (after leaping through cyberspace) the recipient has
typically chosen to be referred to as [email-masked], and in so doing
has also said I trust you (wacky-service.com) to do the right thing,
otherwise they wouldn't use it.  The same arrangement exists as the mail
filters through the enterprise network.

Much the same arrangement exists for SIP.  Hence there is a lot more
implicit declaration of trust than a pure worst case threat model might
suggest.

One reason why security might not have been successful in e-mail is that the
viruses work by compromising the user's mail client.  Chances are, if the
mail client is compromised, then all the authentication and integrity
mechanisms will be compromised also, and so not actually offer any benefit.
Whether this also applies to SIP remains to be seen.

Hence, to use Dean's analogy, there is a place for security, but maybe it
should be considered a medicine for when things are going wrong, and
generally you wouldn't want to use the medicine all the time as, as we've
discussed, there are a number of side effects to it.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 27 Feb 2002 09:30:57 -0000

Jon,

> end-to-end use.

I don't deny that it is anybodies right to encrypt message bodies, but I do
feel that people should be aware that if they encrypt message bodies then
they may not be able to do some things that they would be able to do if they
didn't encrypt the body.

For example, there is firewall opening pinholes case mentioned in the draft
(BTW, although SIP aware firewalls are rare at the moment I don't think the
text should imply they will always be rare.  There are many, many firewalls
out there, and hopefully some day SIP and firewalls will not be immiscible.
If the draft encourages it to become the norm to encrypt what firewalls need
to look at to operate successfully then there is little motive for firewall
vendors to make their firewalls SIP aware.)

This does not require changing of SDP or anything like that, but if you
encrypt this, the firewall will not be able to help.  I agree that this is a
user decision, but people need to have all the arguments in order to make an
informed decision.

I also don't feel that it follows that just because message bodies can be
secured end-to-end then that means message bodies should never be changed.
Almost the opposite, securing the message body is a good way of saying don't
mess with my body, whereas not securing it means you can do with my body
what you feel you need to (Almost back to Dean land here !).

To put that in some context, I feel that preventing somebody modifying your
SDP by integrity checking actually achieves very little.  All SDP says is
'If you send packets to this address I will receive them.'  But if the media
needs to go through a NAT that case won't be true.  Even in the absence of
NATs, there may be routing problems that prevent a UA receiving packets that
it said it could receive on.  I may even be able to do some nasty things
with BGP (so I'm told).  What you really need it to say is 'stuff you
receive identified as such and such is me'.

The bigger problem is that, even if the SDP meant something useful, I could
just attack the system at the RTP level.  I can just send malicious packets
to the specified addresses and cause trouble that way.

Thus in the case of bodies that are references to other resources (e.g.
SDP), there is little point in integrity checking it.  Instead you have to
secure what is referenced (e.g. use SRTP).

Naturally there are bodies that are the final thing and don't point to
things (such as IM), and typically these are worth integrity checking.

The good thing is that it the mechanisms to do this are already in the
standard, but (in my world !) some guidance would be useful.  i.e. if the
body refers to some other resource(s) then there is little point in using
auth_int, and it may even be unhelpful.  If the body does not refer to other
resources, then you may wish to use auth_int.

Pete.