[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] security problem with ebXML MS
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC