Subject: RE: [Sip] New I-D on compression of SIP - security issues

From: Euchner Martin <[email-masked]>
Date: Wed, 25 Jul 2001 18:19:32 +0200

Security experts,

my understanding of draft SIP udpcomp is, that the compression occurs on lower protocol layers (as indicated in chapter 2). However, I do not see how this would make sense when assuming that the SIP message to be compressed has been integrity protected and/or possibly encrypted on a SIP application protocol layer above the compression scheme. It is well known that once a message has been encrypted there is no way for compression afterwards; thus, compression must come before encryption. My recommendation is, that the SIP compression scheme be applied before any SIP message security processing takes place.

Ignoring encryption for the moment, how would the UDPcompression scheme perform, when SIP messages were cryptographically integrity protected with a message-dependant hash-code? I could easily imagine, that the piece of hash-code couldn't be compressed significantly. 
If the hash-code negatively impacts the compression performance, then it might at least be wise to skip and not compress the hash-codes. 

There is also question how the compression-protocol with transmission of the context and tokens relates to security? I would rather assume, that at least the WRITE entries deserve the same protection as the SIP message does.

To conclude, I really doubt the statement in section 7, that the compression protocol would not introduce any additional security considerations but see much reasons to further investigate the mentioned issues.

Kind Regards,

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 722 55790
| Martin Euchner                 Fax  : +49 89 722 46841
| Siemens AG
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet: 
| D-81359 Muenchen               Internet: http://www.siemens.de
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Michael Thomas [mailto:[email-masked]] 
Sent:	Saturday, July 21, 2001 6:18 PM
To:	Jonathan Rosenberg
Cc:	[email-masked]'; [email-masked]'
Subject:	[Sip] New I-D on compression of SIP

Jonathan Rosenberg writes:
 > Folks,
 > 
 > I've just submitted a new I-D on compression of SIP messages, particularly
 > for wireless links. Until the draft appears in the archives, you can pick up
 > a copy at:

Jonathan,

To follow up on my passing comments, it should be
noted that IPsec already has compression
transforms which work in combination with
encryption/message integrity. I'm not sure if TLS
has this capability, but I wouldn't be surprised
(nor do I think it would be hard to add if
not). Thus, there's at least some amount of wheel
reinvention going on here.

That said, it may be interesting to consider
taking the same tack as IPsec compression for SIP
security which has the same problem as all
encryption/compression schemes which is that you
must compress before encrypting to do anything
useful. Thus, it would be natural for secure SIP
headers and bodies (attachments, as I propose) to
allow compression transforms as well.

The synergy between our two drafts, I think, may
lie in something that I've been toying with: the
ability to have a complete SIP application layer
security scheme which not only deals with the
problem which is clearly in the SIP domain (crypto
for parts of the SIP payload), but could also be
used to provide hop-by-hop
encryption/authentication as well negating the
need to require a base level secure transport
mechanism (eg, IPsec, TLS).  I think this is
possible by extending my current proposal to
insert a shim layer much like you propose in this
draft here. I haven't included this in the current
draft (mostly because it's not a baked idea), but
it would make sense to my mind that if we allow
compression, we ought to fold it into the security
framework mainly because of the compress-then-encrypt
problem.

		Mike

_______________________________________________
Sip mailing list  http://www.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  http://www.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: Mon, 30 Jul 2001 18:32:53 -0400

> From: Euchner Martin [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 12:20 PM
> To: 'Michael Thomas'; Jonathan Rosenberg; Euchner Martin
> Subject: RE: [Sip] New I-D on compression of SIP - security issues
> 
> 
> Security experts,
> 
> my understanding of draft SIP udpcomp is, that the 
> compression occurs on lower protocol layers (as indicated in 
> chapter 2). However, I do not see how this would make sense 
> when assuming that the SIP message to be compressed has been 
> integrity protected and/or possibly encrypted on a SIP 
> application protocol layer above the compression scheme. It 
> is well known that once a message has been encrypted there is 
> no way for compression afterwards; thus, compression must 
> come before encryption. My recommendation is, that the SIP 
> compression scheme be applied before any SIP message security 
> processing takes place.

Sure, that is obviously what you want. Unfortunately, doing SIP-layer
compression first, followed by SIP-layer encryption, breaks the nice, clean
transport-layer model in the draft I have proposed. Fixing that depends on
how the SIP layer encryption is done.

Mike Thomas has proposed a framework for such a thing in:
http://search.ietf.org/internet-drafts/draft-thomas-sip-sec-framework-00.txt

His approach uses multiparts to convey compressed entities. An interesting
idea is to treat each multiparty as a "transport stream" in its own right. A
multipart is associated with a compression context. You compress it within
that context, and the resulting thing is then encrypted and placed into the
message. Whats interesting is that the compression context would then exist
between the sender of the message and the recipient of the specific
multipart (Mike has used a new To-field construct, X-SIP-SECURE-TO to
designate this). That means that support for compression would need to
extend to proxies beyond the outbound proxy for the mobile.

Now, all of this is an issue if you think that sip layer encryption is a
common thing. I suspect most of the times, transport layer encryption is
more common (IPSec or TLS). THose would happen after the compression has
been applied, so there is no problem.

-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