RE: Threat assessment, some dissent RE: [ebxml-msg] security pro blemwith ebXML MS

["Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>]

Dale,

Long and interesting message. The message leads me to believe
you are in agreement that there is a risk in not signing MIME headers, 
though you are skeptical of the cost of the risk, and wondering 
loud whether the risk is addressed otherwise. Those are very
reasonable thoughts.

1. My principal argument for supporting selective MIME header
inclusion for signing is to detect data integrity breach *within MSH*.
XMLDSIG provides a mechanism for it, 
but if we do not include all the relevant info to be signed, 
we are drilling a hole(albeit small) in the floating boat.
Some day, water will get to it, and the boat will sink.
Data integrity can be breached by MITM, and can cause
DoS or other kinds of problems. IMO, any information that
can help detect data integrity breach by an MSH should
be signed, otherwise there is no meaning in saying that
secure MSH can provide data integrity. Just using XMLDSIG
doesn't cut it unless we use it right.

2. Note that my proposal is for ensuring integrity of all 
Payload processing information that needs to be conveyed.
If it helps, view the MIME headers as processing info
that needs protection from tampering and to be detected by MSH.
Application may provide other payload processing info that need protection.

As Jim said earlier, patching in security later when we move
from peer-to-peer to multi-hop is worse than biting the bullet now.
As an implementer, I do not want to do the same thing several different
ways. Nobody wants to be in backward compatibility hell,
especially while interoperating! Let us do it right as early as possible.
It is a bit of work, but I think we can do it.

Therefore, I do believe we need to consider the problem and provide
a solution (my proposal is an attempt at it) before we have many
implementations. 

Best,
-Suresh

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Thursday, November 08, 2001 4:19 PM
To: Damodaran, Suresh; James M Galvin; Christopher Ferris; Rich Salz
Cc: ebxml-msg@lists.oasis-open.org
Subject: Threat assessment, some dissent RE: [ebxml-msg] security
problem with ebXML MS


This summary concerns whether we should be spending a lot
of time worrying about how to protect internal MIME content-*
headers for the purposes of ebXML messaging.

Jim Galvin remarked that:

"Regardless of where the MIME headers are duplicated -- whether the
manifest or in the signature element as an object -- the point is it
needs to be required, not optional."

And Rich Salz's aside that:

I deliberately didn't specify WHICH headers to encode, it's up to the
sender to determine which ones to protect.  The spec should advise, of
course.

(By the way, for what it's worth, I don't think this defense will be
necessary in real pratice.)
	/r$

I would like to support, and possibly extend,
Rich Salz's position that
while there may be a MITM threat posed by unprotected
MIME content-* headers, it is not a threat
that greatly impacts ebXML messaging. 
There might be a minor threat of 
denial of service (but this is a threat 
that signing headers will not alleviate).
The remedies adopted should not be made 
REQUIRED as urged by Jim Galvin. I also
think it is actually of marginal utility 
to even get involved
in protecting the internal bodypart headers.


Here are supporting reasons (many already mentioned):

1. (Internal) Header modification is most 
commonly a problem for one transport,
SMTP, when using Relays (or Gateways or other intermediaries).
"Helpful" CTE changes and companion header changes
are presumably not going to happen
under HTTP or HTTPS, even when intermediaries are involved,
unless they gateway into email. And simply ignore any
BEEP profile that has the problem :-) So a "MITM threat"
based on changed headers is usually not malicious, and not
universal across transports. In a way, the SMTP situation speaks
for not including headers in the scope of the signature
if we are mainly concerned with the threat of inadvertently
breaking signatures that are otherwise good. In other words,
by including headers in the scope of the signature, we
risk not getting the payload (potentially validly signed
and intact) processed, because a signature check would fail
due to the changed headers in the SMTP relay case. 
We are opening ourselves up to uninintentional 
denial of service by signing headers!
If headers were important, and they were in danger
of being maliciously changed, 
then using a Suresh/RichSalz method could
be optionally adopted (but I think simplicity would
favor not going there).

As Chris Ferris mentioned, peer to peer transports using 
transport layer encryption would frustrate header manipulation. 
Likewise, digital envelopes would discourage header manipulation, 
even when intermediaries (gateways, relays, MSHes, 
various FW proxies,etc) are involved. 
This means there exist other ways of avoiding the MITM
threat to headers when it is thought to be a live possibility.
This means that mandating some redundant encoding of
headers is not universally warranted; whether it is even
a live possibility, depends on the specifics of transport
as well as packaging.  No reason to require unconditionally.

2. There could be hijacked relays or even other 
hijacked intermediaries and they could 
change headers maliciously. One suggested change
was to alter the content-type header so that the payload
processing would benefit the hijacker somehow, 
by misdirecting it to another application handler.

However, the _routing_ function within ebXML has largely dispensed
with any strict dependence on the semantics of MIME content-*
fields. MIME is mainly being used for its generalized bundling
and unbundling capability. The diminished dependence on the
MIME apparatus is partly because whatever the service or action
element says, the ebXML payload will
most likely just have the same old content-type of "text/xml" or
"application/xml" ( or maybe "*/*+xml.") Why did we have service
and action elements, if we were going to use the MIME apparatus for
application-level routing? The MIME values were 
regarded as insufficiently fine-grained.
The MIME content-type provides a partly
redundant, insufficiently informative label, that within
ebXML messaging, can be largely ignored for app. routing
purposes anyway. So, MITM threat largely irrelevant for internal
content-type headers and the application level misrouting.
No reason to require unconditionally.

3. MITM change of headers could at least interfere 
with processing, and so be an interference with 
service attack. If the goal is interfering with service, 
however, there are a lot of other attacks that would 
be easier/faster/cheaper to undertake.
Signing headers would not in itself defeat
the interference with service, but just offer another
way to detect it. Signing provides no remedy for this
threat. No reason to require here.

4. Another possible reason to show
that the "message" had not been messed with, 
would be to discourage a certain
kind of "replay" ( payload recycling ).
By binding a SOAP envelope 
to its payload(s) by signing,
we would at least have some evidence about
the entity that was replaying the payload.
(It would not prevent it, of course. We could
always still cut and paste an independently
signed payload and repack, resign, resend.)

Interestingly, we already decided that some changes 
are "don't care" with respect to
message "integrity" (the changes intermediaries 
do to the SOAP envelope, for example). 
Given this existing agreement--which forced our use
of XMLDsig in the first place--why not just
decide to exclude the headers from within 
the scope of the signature,
and say that ebXML message "integrity"
does not guarantee that the bodypart headers 
have not changed (added, deleted,
changed case, been given wrong values, etc)? 

As Suresh pointed out, the one bodypart header 
that ebXML messagers do care about a little 
(content-id) is one whose alteration will 
most probably throw 
an exception during processing anyway,
if we are using XMLDsig. Since the
error is already detected, no reason
to require internal header signing here
either.

None of the other headers 
(content-description, -disposition,etc)
supply info that needs to be trusted in the typical
ebXML messaging case. If the payload
did happen to be some elaborate MIME
structure of many varied content types
with embedded multiparts and whatnot,
protecting all these headers could get
quite complex. Easier to just envelope 'em
if there is a viable threat of MITM.
Mandating some header protection scheme
again unwarranted.

5. Under a CPA, the packaging elements would specify
what the content types and layout are supposed 
to be for a specific conversation. The
wrong content-type headers could be detected and 
warned about. So, again, embedding and
signing a header is not universally warranted
or necesary.
 
All that said, if you still want to complicate
things by worrying about a threat with very
little real disutility, the Suresh/RichSalz procedure
seems OK as an optional 2.0 addition. I think
there is yet no compelling reason to require its
use unconditionally within ebXML messaging, however.