Subject: [Sipping] e2m security open issue: label for the target body

From: Kumiko Ono <[email-masked]>
Date: Tue, 26 Oct 2004 19:09:49 +0900

Hi,

I've submitted an update draft of the e2m security mechanism (http://www.
ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-03.txt). 
There are two major open issues on the mechanism of end-to-middle 
security. I would like to hear your opinions on these. 

Open issue#1: How to label the target body.

In order for a proxy server to easily determine whether to process MIME 
bodies and which one, UA needs a way to label the body targeted at a 
particular proxy server(s). 

After receiving many comments at the last IETF meeting about this, I 
gave it some thought and came up with some conclusion, so I want to 
share with you my preference in accomplishing the labeling and the 
reason behind my preference.

Options for labeling:
A-1. a new SIP header, i.e.: "Proxy-Required-Body".
A-2. a new parameter in a SIP header, i.e.: "content-id" param in "Route" 
header.
B-1. a new MIME header, i.e.: "Content-Target".
B-2. a new parameter in a MIME header, i.e.: "required-entity" param in 
"Content-Disposition".

When a message has a target body destined for a proxy server, MIME 
header options (B) shows a greater performance than SIP header options 
(A) in searching the target body. This is because options A require the 
inspection of the SIP header and "Content-ID" MIME header, while options 
B only require the inspection of the MIME header.

When a message has no target body destined for a proxy server, it is 
easier for SIP header options (A) to determine that fact, as it only 
needs to look at the SIP header. 

However, if integrity protection of the label is required, inner headers 
need to be created using sipfrag attached with a signature. And the 
validation of the signature would reduce the advantage of the ease in 
determining the needs to search the body. If the security level of the 
label is considered to be the same as that of routing headers, use of 
TLS would satisfy the integrity requirements which will allow the SIP 
header options (A) to retain their advantage.

Since few of messages in all the traffic through a proxy server will 
likely utilize e2m security, the ease in determining the needs to search 
the body overweighs the performance in searching the target body. 
Therefore, I changed the proposed option, from MIME header options to 
SIP headers. Since a new parameter in Route header has more impact on a 
proxy server, I believe Option A-1, with a new SIP header the best 
choice.

Your feedback is very welcome.

Thanks in advance,
Kumiko
--
Kumiko Ono
NTT Network Service Systems Labs.
Tel +81 422 59 4508/Fax +81 422 60 4012

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David R Oran <[email-masked]>
Date: Wed, 27 Oct 2004 11:15:16 -0400

Thanks for a cogent analysis and the time to investigate the options. I 
find your conclusion to use SIP rather than MIME headers persuasive and 
agree with it.

In addition to the reasons cited I would add two:
1) Modifying MIME seems less attractive because we are not solving a 
MIME problem here - it's a SIP problem. The MIME guys would have ??? 
over their heads as to why MIME would need this functionality.

2) The integrity issues cited about using unprotected SIP headers to 
indicate which bodies to process don't strike me as a problem in 
practice. There are two cases: (a)changing/removing the SIP header so 
that a proxy that should process a MIME body doesn't, and 
(b)adding/changing a SIP header so that proxy that shouldn't process 
the header does.

In case (a) no security is violated since the only reason the proxy 
should look at the body is because the UA *wants* it to - if the body 
isn't processed the UA might not get some service it otherwise would 
get, and/or  the request might fail because of that. This represents a 
DoS attack, but such an attack could be trivially mounted by just 
scribbling on the MIME body itself. In case (b) nothing bad happens 
functionally, but as you point out the proxy/proxies are coerced into 
doing extra work for no reason. Since there are probably about 100 
other ways to make proxies do extra work this one seems no more 
troublesome.

There is a minor issue of detectability of the attack, but I'm not 
convinced that is worth worrying about to the extent of the bother and 
overhead of using SIPFRAG.

Between option A-1 and A-2 I find A-2 (add content-ids to route header) 
more elegant. Hovever, we've had discussions in the past about whether 
extending the Route header for other things might cause 
backward-compatibility issues and avoided it on that basis. It might be 
good to poll the implementers to look at their route header handling 
code to gauge the practical impact.

Thanks and regards, Dave.

> Your feedback is very welcome.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Kumiko Ono <[email-masked]>
Date: Fri, 29 Oct 2004 21:26:50 +0900

Thanks for your useful comments.
See inline.

>over their heads as to why MIME would need this functionality.

I agree. Since all parts of multipart MIME usually target the same 
entities, it is not necessary to indicate the targeted entity of each 
part of MIME in general.

>overhead of using SIPFRAG.

I was worrying about case(a). My concern was how the UA knows if the 
body is processed properly. However, I find that it is a issue about 
acknowlegement of the UA's request rather than an issue of security. 

>Thanks and regards, Dave.

I agree that it's good idea to poll the implementers about the practical 
impact. Actually, I have encountered the problem at the SIPit event. Our 
client/proxy couldn't process the Route header that had unknown 
parameters.:-)

Thank you so much,
Kumiko