Please explain what this means: "In any case you have just now stated that
MIME headers are important,
since the CPA is going to check/use them." The CPA doesn't check or use
anything. It is a passive object that defines the IT configurations of two
parties. It may specify that MIME headers are to be used but it is the
sending MSH that sets them up and the receiving MSH that checks them.
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
*************************************************************************************
James M Galvin <galvin@drummondgroup.com> on 11/09/2001 09:13:39 PM
To: Dale Moberg <dmoberg@cyclonecommerce.com>
cc: "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>, Christopher
Ferris <chris.ferris@sun.com>, Rich Salz <rsalz@zolera.com>,
ebxml-msg@lists.oasis-open.org
Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security
problem with ebXML MS
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>