[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security pro blemwith ebXML MS
Suresh, You asked "What if another type contract is used?" That might be another can of worms but I think that we can safely put it off until version 77 since no other such contract has surfaced and Web Services hasn't yet figured out the need for agreements. So, we are dealing with the following cases: CPA Manually entered configuration information equivalent to a CPA but with no automated assurance that what both parties enter is compatible. I think that this is what most of us understand as the meaning of "no CPA". No agreement at all. The proponents of "no agreement at all" either believe that two parties can communicate without compatible configurations or that all the configuration information can be carried in the message header. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com> on 11/09/2001 05:33:48 PM To: "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, James M Galvin <galvin@drummondgroup.com>, Christopher Ferris <chris.ferris@sun.com>, Rich Salz <rsalz@zolera.com> cc: ebxml-msg@lists.oasis-open.org Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security pro blem with ebXML MS Dale, In any case, the MS spec should state clearly what kind of security it supports and what it doesn't. It definitely is not in the interest of anyone to say that ebXML MS provides certain security guarantees, when it doesn't. Possibly the security considerations section needs a good rewrite, may be other too. (Things like CPA will have Content-Type should be in MS spec. However, I am not sure MS assumes the uses a CPA. What if another type contract is used? Hope I am not opening another can of worms:-)) I do hope this subject gets discussed at the F2F. Regards, -Suresh -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Friday, November 09, 2001 12:27 PM To: Damodaran, Suresh; James M Galvin; Christopher Ferris; Rich Salz Cc: ebxml-msg@lists.oasis-open.org Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security problem with ebXML MS Jim and Suresh, 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, for that threat, these considerations still stand: 1. ebXML messaging processing does not need to trust internal MIME content-type values. 2. content-id values, if changed, will almost certainly lead to an error condition when they are used as part of XMLDsig signatures. 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!) 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). Dale ---------------------------------------------------------------- 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