RE: [wss] Recently discover WSS security threat

[Michael McIntosh <mikemci@us.ibm.com>]

"DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM> wrote on 
06/02/2005 04:36:39 PM:

> Section 3.2.1 of the DSIG spec says
> 
> -- begin quote --
> 3.2.1 Reference Validation 
>  1. Canonicalize the SignedInfo element based on the
>     CanonicalizationMethod in SignedInfo. 
>  2. For each Reference in SignedInfo: 
>      1. Obtain the data object to be digested. (For
>         example, the signature application may dereference
>         the URI and execute Transforms provided by the
>         signer in the Reference element, or it may obtain
>         the content through other means such as a local
>         cache.) 
>      2. Digest the resulting data object using the
>         DigestMethod specified in its Reference
>         specification.
>      3. Compare the generated digest value against
>         DigestValue in the SignedInfo Reference; if there
>         is any mismatch, validation fails.
> -- end quote --
> 
> Section 3.2.2 of the DSIG spec says
> 
> -- begin quote --
> 3.2.2 Signature Validation 
>  1. Obtain the keying information from KeyInfo or from an
>     external source. 
>  2. Obtain the canonical form of the SignatureMethod using
>     the CanonicalizationMethod and use the result (and
>     previously obtained KeyInfo) to confirm the
>     SignatureValue over the SignedInfo element.
> -- end quote --
> 
> Tell me, which of these steps says, "Verifies that the data object to be
> digested is located at the place indicated in the ds:Transform element?"
> 
> In fact, it seems to me 3.2.1.2.1 says the exact opposite.

It does not say the opposite. It says "Obtain the data object to be
digested. (For example, the signature application may dereference
the URI and execute Transforms provided by the signer in the Reference
element ... "

The rest of the paragraph intends to cover the case where there is no need
to dereference the URI and/or apply transformsn to get the signed data. An
example would be a URI to an external peice of data that does not vary
between requests (e.g the WSDL for the service, the XML Schema for the
document, some contract between the partners).

If the data object can ONLY be obtained by dereferencing the URI and
executing the transforms, and the set of transforms includes an
absolute path XPath expression, then it does translate to "Verifies that
the data object to be digested is located at the place indicated in the
ds:Transform element".

Bottom line, I contend that if you can provide an XML Document, I can
provide an associated ds:Signature that will allow a receiver to detect
whether any element (your choice) was moved/altered/removed within that
document.

> The implementation I'm thinking of gets a message in to the security
> layer, finds the appropriate signature according to application policy,
> verifies that signature, making sure that the digest method used in
> 3.2.1.2.2 and signature method used in 3.2.2.2 satisfy application
> policy, and finally forwards to the application layer A) an array of the
> data objects used in 3.2.1.2.1 and B) the keying information used in
> 3.2.2.1.  It then throws everything else away, so as not to contaminate
> the application.
> 
> This behaviour seems to be the kind of behaviour recommended by the DSIG
> spec.  So, to use an example, lets say there were three references, one
> to the body, which says "send 1 case of soda"; one to an xml element
> that says "the sky is blue"; and one to a nonce, which says "123".  Now
> this is perfectly fine.  Each data object has clear semantics on its own
> and does not depend on its *location* related to the other data objects.
> 
> Consider a different example.  Lets say there are again three reference,
> one to the body, which says "send 1 case of soda"; one to an xml element
> that says "if used in the Header element of an Envelope, the Body in
> that Envelope has urgent priority"; and one to a nonce, which says
> "124".  Now this is *not* fine.  The application has no way to know what
> the semantics of the second data object is because it does not know
> whether it was contained in a Header in an Envelope and, if it was, what
> the Body of that Envelope was.  The application could reject this
> message as being too vague.
> 
> The same example could be better done with two references, one to the
> envelope, including the body and the header and their relation to each
> other, and one to the nonce.  Now the application can understand the
> semantics of the first data object according to the Envelope semantics
> and can understand the nonce.  This is fine.
> 
> Optionally, the example could be done with one reference to the
> envelope, including the body and the header and the nonce and their
> relation to each other.  This is fine too.
> 
> It doesn't matter to me whether we use XPath or xmldsig-filter2 or just
> URI, as long as we can build applications that don't have to go mucking
> around in the original message trying to figure out the correspondence
> between the data objects that were signed and the possibly-different
> pre-transformed data and their respective locations in the message.  If
> the application needs to know a location-correspondence between two
> pieces of data, those two pieces of data and that
> location-correspondence should all be in the same signed data object.

As long as the location-correspondence and data values are protected then
the application does not care what was signed.

> 
> &Thomas.
> 
> ] -----Original Message-----
> ] From: Michael McIntosh [mailto:mikemci@us.ibm.com]
> ] Sent: Saturday, May 28, 2005 8:04 AM
> ] To: DeMartini, Thomas
> ] Cc: Hal Lockhart; Rich Salz; wss@lists.oasis-open.org
> ] Subject: RE: [wss] Recently discover WSS security threat
> ] 
> ] Thomas,
> ] 
> ] I think the part you reference does not apply in this context.
> ] The Reference Validation step will ensure the referenced element has
> not
> ] been altered.
> ] The Signature Validation step will ensure that the ds:Transform
> element
> ] has not been modified.
> ] The Transform is part of the SignedInfo.
> ] 
> ] Thanks,
> ] Mike
> ] 
> ] "DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM> wrote on
> ] 05/27/2005 10:26:22 PM:
> ] 
> ] > According to the DSIG spec, "core validation behavior does not
> confirm
> ] > that the signed data was obtained by applying each step of the
> indicated
> ] > transforms" (http://www.w3.org/TR/xmldsig-core/#sec-Security).
> ] > Therefore, unless your post-transform data includes the fact that
> the
> ] > abc header is a direct child of the soap:header element, core
> validation
> ] > behaviour does not confirm that it is.
> ] >
> ] > So whatever transform you use, the *output* of the transform has to
> look
> ] > like:
> ] > <soap:Envelope>
> ] >   <soap:Header>
> ] >     <my:header wsu:id="abc">
> ] >        ...
> ] >     </my:header>
> ] >   </soap:Header>
> ] >   <soap:Body>
> ] >     ...
> ] >   </soap:Body>
> ] > </soap:Envelope>
> ] >
> ] > You can write such a transform using the regular xpath transform
> instead
> ] > of the xmldsig-filter2 transform, but it is much more complicated,
> as
> ] > discussed in the xmldsig-filter2 spec.  It would have to look
> something
> ] > like this (not debugged):
> ] >
> ] > (ancestor-or-self::soap:Envelope and not (ancestor::soap:Header)) or
> ] > ancestor-or-self::my:header[wsu:id='abc']
> ] >
> ] > (Recall that the regular XPath transform returns all nodes for which
> the
> ] > XPath evaluates to true.  Contrast this with the xmldsig-filter2
> ] > transform which returns all nodes that are selected by the XPath.)
> ] >
> ] > &Thomas.
> ] >
> ] > ] -----Original Message-----
> ] > ] From: Rich Salz [mailto:rsalz@datapower.com]
> ] > ] Sent: Friday, May 27, 2005 5:57 PM
> ] > ] To: DeMartini, Thomas
> ] > ] Cc: Hal Lockhart; wss@lists.oasis-open.org
> ] > ] Subject: RE: [wss] Recently discover WSS security threat
> ] > ]
> ] > ] > Then you're still just signing the header and not the fact that
> the
> ] > ] > header is *directly* inside the soap:Header element.
> ] > ]
> ] > ] I don't see it.
> ] > ]    /soap:envelope/soap:header/*[wsu:id='abc']
> ] > ] As a simple XPath transform will find only nodes that are direct
> ] > children
> ] > ] of the header and who have the wsu:id attribute with the right
> value.
> ] > ]
> ] > ] In other words, you can do it with a simple XPath transform, not
> the
> ] > more
> ] > ] complicated XPath2 transform. Right?
> ] > ]
> ] > ]    /r$
> ] > ]
> ] > ] --
> ] > ] Rich Salz                  Chief Security Architect
> ] > ] DataPower Technology       http://www.datapower.com
> ] > ] XS40 XML Security Gateway
> http://www.datapower.com/products/xs40.html
> ] >
> ] >
> ] >
> ---------------------------------------------------------------------
> ] > To unsubscribe from this mail list, you must leave the OASIS TC that
> ] > generates this mail.  You may a link to this group and all your TCs
> in
> ] OASIS
> ] > at:
> ] >
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ] >
>