Re: Threat assessment, some dissent RE: [ebxml-msg] security problemwith ebXML MS

[Christopher Ferris <chris.ferris@sun.com>]

+1 !

Chris

Dale Moberg wrote:

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