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

[James M Galvin <galvin@drummondgroup.com>]

On Fri, 9 Nov 2001, Dale Moberg wrote:

    In my earlier long message I tried to summarize:
    
    1. what kind of threats
    might be provided
    2. under what transport/packaging conditions
    given the typical processing of
    3. ebXML messages.

    I considered a number of possible kinds
    of threats. Apparently Jim thinks it
    is only the threat of misdirection that
    should be of concern. So, 

Well, no, not at all.  I understand that you might think that if you
were reading only my last message.  My last message was reacting to what
I perceived to be a common thread in all of your prior message, that is,
all threats that are detected by what is being proposed can be reduced
to denial of service.  Since we offer no protection for denial of
service and accept that there is very little, if anything, we could do
even if we wanted, let's not do what it is being proposed.

    for that threat, these considerations still
    stand:
    
    1. ebXML messaging processing does
    not need to trust internal MIME content-type
    values.

If this is true then the specification needs to address this as part of
its integration of security services.  To do this it needs to make
explicit that MIME packaging is just that, packaging, and all other
information (except the Content-ID) needs to be ignored from the point
of view of ebXML.  To further emphasize this point then all MIME
content-type headers should be set to "application/octet-stream", since
the MSH will know the correct type from the manifest.

If you don't do this then some implementation will no doubt use some
information from the MIME headers.  As soon as it does this -- and you
have to assume it will be done in a risk analysis -- you have created a
vulnerability.  It is my opinion this vulnerability is easily protected
and, in fact, it should be.

    2. content-id values, if changed, will almost
    certainly lead to an error condition when
    they are used as part of XMLDsig signatures.

I'm not yet convinced of this as I haven't yet worked through the all
the scenarios of re-ordering body parts and mixing and matching
Content-ID: headers with payloads.

    3. CPA based agreements can be used to:
     a. check that internal mime content-types
        are as expected. MIME error can be thrown
        if enforced.
     b. add digital enveloping that can encrypt the entire
         MIME chunk, including the headers
        (using 1847 security packaging if you like, Jim!)

It concerns me when you want to use CPA-based agreements to solve the
problems.  It bothers me because it suggests we don't really know the
answer and let's make it someone else's problem.

In any case you have just now stated that MIME headers are important,
since the CPA is going to check/use them.  This should mean they need to
be protected, right?

    Given all of this existing apparatus permitting
    strong counters for the situation of MITM header
    tweaking, if you still wish to mandate an
    additional new security mechanism, I urged you
    to hold off until the next iteration. By then,
    maybe XMLEncryption will be stable or other
    security proposals may have emerged that can
    be cited. Maybe a tweak to the mid: or cid: URIs
    that would permit mid: sub-segments-- who knows?

    ebXML messaging is IMO not primarily engaged in
    inventing new security solutions and countermeasures,
    but instead is involved in adopting 
    existing stable solutions to achieve
    an acceptable coverage for the standard threats
    (spoofing, alteration, and sniffing). 
    I would rather retrofit to a dedicated
    security groups carefully examined spec.
    than try to throw something together at the last minute
    (and we are at the last minute for 1.1). 

I'm sorry but I can not support this position.  With more than 10 years
of experience with IETF Security Standards one thing I've learned is you
can not retrofit security.

My concern is that security is hard enough to get right without having
to figure out how to make it right with a protocol that wasn't designed
to be secure in the first place.  I agree we have a lot of tools
available to us but there are issues with respect to how those tools are
used to achieve a desired goal and to ensure interoperability.  That is
my only real point.  We need to make sure we have it right and now is
the time to do it.

I'm sorry that I am coming in to this rather late in the game.  I'm not
trying to make this difficult or cause a significant delay, but I do
think this issue is important.

Jim