OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC