Re: Security Consideration section for MTOM

Gudge,

I think this is fine as far as it goes, but I have an additional 
suggestion for an area to be covered.  Specifically, I think there are a 
number of potential attacks relating to malicous data provided at the 
sender or receiver.   What I have in mind is along the following lines:

===========
MESSAGE INTEGRITY

This specification provides explicit mechanisms to protect against 
inadvertent serialization of certain erroneous data.  Specifically, 
section 4.2 [1] requires that senders "Ensure that the Original Data Model contains no Element Node with a 
node-name of  http://www.w3.org/2003/12/xop/include;Include}."  This rule protects against the possibility that sending software would 
maliciously or inadvertently introduce a XOP link to data that did 
correspond to the original envelope input, and in particular protects 
against generation of links that might result in security exposures upon 
dereference.   Also, section 4.1 [2] makes clear that elements to be 
optimized " MUST have type equal to xs:base64Binary , and (that) the return value of 
the dm:string-value accessor of such Nodes must be in the canonical 
lexical representation of that type as described in Errata in XML Schema, 
E2-54."  In so doing, the specification protects against potentially malicious 
attempts to force data conversions on erroneous data.

Thus, currectly written serializers will produce streams that can be 
deserialized using the mechanisms described by this recommendation, but 
there is still in some circumstances the risk that malicious or erroneous 
software would present for deserialization a stream that does not conform 
to the rules of this recommendation.  As with any such software, XOP 
deserializers should be written to check for and to decline to deserialize 
such erroneous input.  In addition to the checks that would usually be 
done in parsing a multipart MIME package and a (root) part of media type 
"application/xxxx+xml", XOP deserializers SHOULD ensure that the href 
attribute on each xbinc:Include properly resolves to a part within the 
multipart-related package.  Links to (representations of) other resources 
are erroneous and SHOULD NOT be followed. 
===========

Or some such.   Make sense?

Noah

[1] http://www.w3.org/TR/2004/WD-xop10-20040209/#creating_xop_packages
[2] http://www.w3.org/TR/2004/WD-xop10-20040209/#creating_xop_packages

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Martin Gudgin" <mgudgin@microsoft.com>
Sent by: xml-dist-app-request@w3.org
02/10/2004 02:32 AM

 
        To:     <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Security Consideration section for MTOM



I took an action on the 2004-02-03 call to write up a security
considerations section for MTOM. Here's a first cut. Comments welcome.

Cheers

Gudge


Message Integrity

The integrity of SOAP messages transmitted using the MTOM HTTP Binding
may need to be ensured. As such messages can be transformed to an XML
Information Set, from which an XPath 1.0 Data Model can be inferred,
existing XML Digital Signature techniques can be used to protect such
messages. Digests computed for this purpose would be over the base64
characters rather than the xbinc:Include elements. Existing
canonicalization algorithms[C14N,EXCC14N] do not permit computing
digests over the binary octets directly. Future canonicalization
algorithms could describe a more efficient algorithm.

Care should be taken when constructing an XPath node set as input to a
canonicalization algorithm. Specifically, node sets where adjacent nodes
are text nodes containing base64 characters should be avoided as an
attacker could move base64 characters from one node to another without
changing the digest value.


Message Confidentiality

The confidentiality of SOAP messages transmitted using the MTOM HTTP
Binding may need to be ensured. As such messages can be transformed to
an XML Information Set existing XML Encryption techniques can be used to
protect such messages. Any part of a message can be encrypted, whether
it includes base64 characters or not. The resulting CipherData can then
be optimized because the content of such an element is base64
characters.

In future a transform algorithm for use with xenc:CipherReference could
provide a more efficient processing model where the raw octets are
encrypted directly.

Received on Monday, 16 February 2004 21:32:08 UTC