RE: [wss] Recently discover WSS security threat

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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.

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.

&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
] >