Re: Composibility problems with refps

It's probably the case that you haven't seen my message yet, but with 
all the spam filters around you never know.  And anyway, I like this 
writeup better.

The risk is that an adversary inject an unsigned header.  Since you 
cannot sign an entire SOAP Header, but only individual Header elements, 
you have to have a close coupling among at least two of the security 
layer, the ws-addressing layer, and the application layer, in order to 
know what headers have been signed, and/or what headers must be signed.

A more subtle attack would be for the adversary to insert signed 
headers, but signed by someone else.  If the recipient is following the 
standard Internet trust model of "must be a Verisign cert," then it is 
quite likely that this would escape detection.  Even if the recipient is 
quite careful, however, it is difficult for current systems to support 
the concept of multiple signers; throwing in the concept of "some 
trusted, some not" is probably beyond the pale.  If not, it requires 
further linkage between the layers, because now the application must 
tell the security system who is authorized to sign what parts of a 
message, or the security layer must pass back the signer identity on a 
per-element basis.

If you don't want to accept this kind of linkage then you need to make 
it obvious to all layers when something is an endpoint param or ref. 
There are a couple of ways to do this:
	Put them inside the endpoint reference
	Put them in a wrapper
	Use actor/role to target them

Not only is self-description good, it seems here to be a security 
requirement.
	/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 Wednesday, 24 November 2004 18:06:29 UTC