RE: [ebxml-msg] security problem with ebXML MS

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

Chris,

Jim has eloquently addressed the interesting points you raised.
Let me address some relevant issues that were touched upon earlier.

1. We are ONLY addressing the "data integrity" problem (RFC 2828 is the
glossary
for all security terms I am using). To detect a data integrity breach,
it is sufficient for some "processor" in the chain to throw an "error." Note
that signature serves the same purpose. Let us apply the same logic to MIME
message.

In MIME, the payloads are referenced using Content-ID. If the Content-ID of
the first payload (referenced by "start") is changed, then the MIME
processor or ebXML Envelope processor would throw an error. If any of the
Content-ID of the other payloads
is changed, either MIME processor will throw an error, or ds:Signature
verifier will throw an error. An interesting conclusion is that Content-ID
need not be repeated and signed in eb:Manifest. (I will reflect this in my
earlier proposal unless anybody has objections)

2. The MIME headers of the SOAP envelope of interest (Content-Type) is
text/xml,
and is standard. Content-ID, as discussed in (1) above, is not of interest.
Therefore, I do not see the need to secure the MIME headers of the SOAP
envelope. It would be a prudent thing to check that the Content-Type is
indeed "text/xml" for SOAP envelope. (I will add a note to this effect in
the proposal)
 
3. The real threat is that the application payload headers may be changed,
and we don't have a way to detect that. The problem is real, and this
proposal addresses exactly that problem.

Cheers,
-Suresh

-----Original Message-----
From: James M Galvin [mailto:galvin@drummondgroup.com]
Sent: Wednesday, November 07, 2001 10:51 AM
To: Christopher Ferris
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] security problem with ebXML MS



On Wed, 7 Nov 2001, Christopher Ferris wrote:

    This proposal seems to imply that MIME processing/parsing of the
    message is limited exclusively to the first body part of the
    multipart/related MIME object (the SOAP Envelope) and that all
    subsequent processing of the multipart/related object is driven by
    the contents of the MIME header info contained within the Manifest.

I'm not speaking for Suresh but based on my discussions with him your
understanding is not the intent.  The intent is what you would expect,
thus we simply need to clarify the text.

All MIME processing can and should proceed as before.  At issue is
simply the fact that the MIME headers for the body parts that comprise
payloads inside the outermost multipart/related are not protected.  This
is a security problem.

What Suresh is proposing is that the MIME headers (appropriately
canonicalized) for body parts that are payloads in the outermost
multipart/related should be duplicated in the SOAP Envelope.  This
ensures they receive the same protection as the SOAP Envelope itself.

The only other additional step, which David described, is to decide if
these MIME headers are to be compared to the received MIME headers by
the receiving agent or, perhaps, they should simply replace the received
headers.  Of course, both of these options mean that the Content-ID:
header of the actual payload has to be believed regardless, but if it's
been modified later security checks will fail anyway.

    In addition,
    the issue raised suggests that ALL MIME headers, including
    those that comprise the multipart/related "envelope" and
    those of the start object (the SOAP Envelope) would need
    to be protected, or maybe I'm missing something.

Yes, my wording is ambiguous but in fact the the two sets of MIME
headers of which you speak need not be protected.  The outermost headers
(those of the multipart/related) don't need to be protected because if
they've been modified your threat is denial of service.  Since there is
no protection for this anyway there is no issue.

The MIME headers on the first body part do not need to be protected
because you can simply ignore them.  By definition the first body part
of the outermost multipart/related is the SOAP Envelope and as long as
you process it that way there is no additional threat.

    Further, I don't think that it is the responsibility of
    the OASIS ebXML Messaging TC to specify MIME header C14N. I would
    think that if this s to be done at all that the ownership
    and responsibility for this would belong squarely in the IETF camp.

This is a minor process issue in my opinion.  In fact canonicalizing
MIME headers is not an issue for the MIME community (and has not yet
been an issue for any other community in the IETF).  The reason is
because MIME has support for security services and the issue the ebXML
community is having is addressed differently.

As author of that specification (RFC1847) I can tell you that the reason
MIME does not have this problem is because the first body part of a
multipart/signed is defined to be immutable, which includes both header
and content.  Thus, signatures are not at risk of having the MIME
headers defining the content changed.

ebXML has this problem because you are mixing technologies, specifically
XML and MIME.  It is always true in security that when you mix
technologies you will have issues with the relationship and
integration.  What we are doing here is acknowledging those issues and
offering a solution for them.

The reason it is a minor process issue is because I believe there is no
problem with this group defining the "transform" it needs to
canonicalize MIME headers for its purposes.  In fact, I think this is
the right solution because canonicalization for this group means to not
include headers whose purpose is solely for "transport".  In particular,
canonicalization for this group would exclude duplicating the
Content-Transfer-Encoding: header.  If the IETF were to specify
canonicalization it would indicate how to canonicalize this header and
then you would still need your own "transform" because you would still
want to exclude this header.

Jim


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>