RE: [wss] Recently discover WSS security threat

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

"DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM> wrote on 
06/02/2005 07:15:48 PM:

> ] 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.
> 
> Believe me, your point that "all the information a receiver needs is
> there" is not lost on me, and I have no doubt you could provide such
> information in signature form.
> 
> Do you think that the same could not be done with the style of signature
> I am recommending?

I think it could.

> The difference I think between the two proposals comes down to a) which
> is normative behaviour according to DSIG and b) which can be more easily
> generalized to account for other transforms.

I think you should throw in c) which can be more efficiently implemented, 
and
d) which more closely approximates the semantics some once expected from 
IDREF
signatures.

> I think preserving any necessary location information in the data object
> to be signed is better suited for both a) and b).

I disagree. I think my proposal depends on only normative behavior and 
behaves
in a series of transports exactly like an IDREF alternative would.

> Consider I have a header that looks like this:
> 
> <my:header>
>   <my:integer>32</my:integer>
> </my:header>
> 
> Now suppose I reference the envelope, run an XPath as you described to
> select just my:header and all its descendents, and then run a custom
> transform to increment all integers by 1.  The signed data looks like
> this:
> 
> Reference 1:
> <my:header>
>   <my:integer>33</my:integer>
> </my:header>
> Reference 2:
> <soap:Body>...<soap:Body>
> 
> What does the application see as the authentic data?  32 or 33?
> According to the DSIG spec, the answer is 33.

I disagree. The DSIG specification discribes how to create and verify
signatures. It does not discribe what gets passed to applications.

> But now let me ask you,
> if a receiver follows the processing model you described, where does it
> determine that the 33 resides in the message?

I don't think most people would use transforms specified for signature
verification to obfuscate data. I don't think most implementations use the
result of the transforms for anything other than input to the digest
operation. This concept it does raise interesting possibilities. For
instance why not just implement encryption as a signature transform?

How about this scenario. An environment where application processing 
is performed either before or concurrently with signature verification. 
The transaction is committed only after signature verification
completes successfully. 

> And what is its location-relationship to the soap:Body?

Since the security policy requires an absolute path XPath transform,
the security header processing verifies the location has not changed
between the time the message was signed and when it was verified.

> Now consider the same example message, except this time the signature is
> constructed using a reference to the envelope, a transform to select the
> envelope, header, body, and my:header, and a custom transform to
> increment all integers by 1.  The signed data looks like this:
> 
> Reference 1:
> <soap:Envelope>
>   <soap:Header>
>     <my:header>
>       <my:integer>33</my:integer>
>     </my:header>
>   </soap:Header>
>   <soap:Body>...</soap:Body>
> </soap:Envelope>
> 
> I see no more room for ambiguity.  Clearly the authentic data is 33 and
> its relationship to the soap:Body is specified by the soap:Envelope.

So using your alternative if there where multiple References in the 
signature
the application would receive a complete SOAP Envelope for each?

So forgetting the issue with the transform that modifies the data and 
expects
the application to see the transformed data...

I think your solution provides the same level of protection as the simple 
XPath.
However, your solution requires a more complex XPath expression and is 
therefore
harder to use and probably less efficient.

My intent was to provide an expression that provided the same properties 
as
an IDREF with the added property that any attempt to move the signed 
element 
would be detected. I think my solution is more suitable for that purpose.

While your solution my be more suitable for the scenario you've described 
I don't
think the scenario is realistic and it would require modifications to the 
entire
processing model.

>
> &Thomas.
> 
> 
> ---------------------------------------------------------------------
> 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 
>