RE: Composibility problems with refps

> But your still talking about comprimising the pipeline itself. It's not
> an attack someone could mount on the wire.

If you have complete control of all the systems that touch your packets,
then you don't have to worry.  If however the pipeline involves network
devices and systems not under your complete control, then you are at risk.
But these days not only do you not have control over all the devices that
touch your packets, but when you do multi-party SOAP messages, you're
explicitly delegating that another entity touch have a piece of the
pipeline.

For example, a message goes from A-->B-->C.  Unless you completely trust
that B is not going to inject a header (unsigned or signed, as I tried to
explain in a previous message), then A has no way to get end-to-end
security of the message.  Hop-by-hop, as in SSL, is not good enough.  A
needs to be sure that C gets all, and only, the refprop/params that it
sent, and that they arrive unmodified.

Why is this?  What are the risks?  Let me give some examples.

B could be a network device within your enterprise network, in which case
you only have to worry about insider attacks (e.g., someone bribing your
IT staff).  Most attacks involving "real money" are insider attacks.
How much would it cost to get an IT contractor -- or perhaps simpler,
an overnight cleaning staff -- to insert a bit of rogue software that
adds a new SOAP header to outgoing messages?  I remember a talk by Dan
Geer that says he could get to unattended commodities trader workstations
because he knew which elevator operator liked whiskey.

But suppose it's not a "virtual" pipeline, but is instead a mult-node SOAP
message.

B could be a third-party service run by a consulting firm, in which case
A should be concerned about anyone at the consulting firm who might have
access to B.  If the B node is hosted by a third-party hosting firm,
then A's circle of trust must now include the consulting company,
the hosting company, and perhaps the outsourced physical security service
that makes sure no other customer gets physical access to the B node.

A could be a large bank inside a "shaky" country.  B could be a national
service run by the corrupt administration, who wants to be able to audit
all financial exchanges of hard currency.  C could be the US Federal Reserve.
Or switch A and C.  Without end-to-end security, both sides must trust
B, which may be not be possible.  This is not an unrealistic scenario.

Does it now make sense why no matter what happens to a message,
end-to-end security between A and C is not only important, but
necessary?

The current SOAP binding of WS-Addressing says that refprop/params
are "pulled out" of the endpoint reference, and become standard SOAP
headers.  Once you have a "generic" set of headers that are no longer
identifiable as WS-Addressing headers, then you must either closely couple
some part of your {security,ws-addr,application} layer -- on both sender
and receiver sides -- or you lose e2e security.  I tried to explain
this in more detail in this message:
  http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0545.html
In your response to that, you agree that coupling is necessary.
I would make the decision the other way, and embed refprops/params in
something that is clearly marked as part of ws-addressing, so that I can
express the security policy in a simple, generic, manner:
	sign the message body and all ws-addressing data

Otherwise the client has to tell its runtime to:
	sign the message body, and these headers
The server side is much more complicated:
	 verify the message body, and
		if its a "foo" message, verify ... headers
                if its a "bar" message, verify ... headers
                if its a "baz" message, verify ... headers
and if headers have application default values, then we add "if present"
to each one of the headers in the ... part above.

See, for any other ws-xxx spec (again, that I know of), you can also
express the security policy very simply:
        sign the ws-xxx header

I could imagine expressing that in an ebXML CPP/CPA or a WS-Policy document.
I do not want to think about the verbosity of expressing the more
complicated foo/bar/baz ruleset.

I think that's too complicated and closely-coupled.  If a third-party
(a B node implemented as a device, or a generic security layer, or
a Sarbanes-Oaxley compliance service) can look at a SOAP Header, and
purely from that message determine which elements are addressing
data, then it can -- in a generic manner -- make sure they're secure.

Hope this helps.
        /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 23:32:52 UTC