Re: Problems with the SOAP binding

Jonathan Marsh wrote:
> Like I said, I'm not a security expert, but I'm not aware of anything in
> WSS that implies that all security features must be expressed through
> WSS.  Do you have a reference to the part of WSS that you're concerned
> about?

If you read Section 5 of the WSS spec it's not unreasonable to assume 
that everything related to message security belong inside WSS.  It is 
clearly open to interpretation, which is why I asked Gudge for his opinion.

More explicitly, the WS-I basic security profile says (R3207 in section 
9.1.2), that all xenc:EncryptedKeys must be a child of the WSS header.
So if a server wants to "statelessly" encrypt a refP so that it can 
decrypt it later, if has to put some information into the WSS header. 
I.e., encrypted refP's imply tight coupling to WSS.

> Expanding on my earlier post, to statelessly secure a refP against
> modification, one could:
> - insert within the refP itself the security measures such as 
>   a DSig that enable the service to verify that the refP hasn't 
>   been changed since issued, or
> - insert a second refP containing security measures and pointing to
>   the header (or headers) to be secured.

In previous email I've tried to show that it's not as simple as that, 
and requires some pretty close coupling between the WSS, WS-Addr, and 
client or server application layers.  I can dig up links to those 
messages if necessary.  But my overall comment is that making sure that 
the server gets back unmodified refP's isn't enough.  You have to make 
sure that the client doesn't get fooled into sending things it shouldn't 
(adversary modifies the EPR before client gets it), and that the server 
gets only, and exactly, the refP's that it should.

> This is similar to statelessly securing HTTP cookies.  The cookie
> transfer mechanism is defined in a general spec but how cookies ensure
> clients don't modify their contents is out-of-scope.  Just as you don't
> use TLS to prevent clients from altering cookies you don't use WSS to
> prevent clients from altering headers.

I don't think the analogy is accurate.  A server concerned about 
interception and modification of cookies can just send base64 blob of 
data that, when it gets it back and decrypts it, can include a digest. 
For refP's, the goal is that the headers *not* be a binary blob, in 
order to leverage the SOAP header processing model.  If you want to do 
the equivalent of an encrypted cookie, then WSS WS-I say to use XML 
Encryption and WSS, no?

There's another problem, if the refP includes headers that are targeted 
*to intermediaries,* then securing them requires their own signature, 
and they cna't be bundled into the signature that covers the refP's 
intended for the ultimate recipient.

I don't think this is at all out of scope.  We must at least document 
the security considerations.

> ID attribute collisions seem indeed to be a problem, regardless of
> whether refPs are wrapped or not - this is a general problem when
> combining chunks of XML.  We should look at this more closely, but on a
> practical level I might try to make sure any ID values I stuck in my
> refPs were unlikely to cause conflicts, e.g. something like an embedded
> GUID value xml:id="guid-1234-1234-1234-12345678".

Yes.  But again, we also need to document the potential conflict problem.

	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

Received on Monday, 3 January 2005 20:25:54 UTC