RE: [STF] Additional security usage scenarios - comments on firew all usage scenario

> Hugo Haas wrote:

> |   5. Firewall Processing of Messages
> 
> This is a particular case of authorization involving an intermediary.
> As a general rule, we should probably add a few scenarios underlining
> the role of intermediaries, being security-related or not.
> 
> => Look into intermediairies usage scenarios.

The firewall usage scenario strikes me as a little odd and certainly
different from the other usage scenarios in that it does not seem to be so
much a application/business/policy usage scenario as a particular security
mechanism. As a result, it is not entirely clear what sort of objectives are
being pursued. Is it to prevent denial of service? This would require a
fairly specific and tricky design and deployment strategy to be effective.
The ordinary effect of such checking would be to slow things down and thus
make DOS somewhat easier from the attacker's point of view.

Perhaps the objective is for the (hardened and error free) firewall to
intercept possible attacks on the (buggy and poorly designed) application.
However, firewalls do that today by applying heuristics (guesses) to the
content of the data, without referring to SOAP headers at all. It seems to
me that header checking would only be effective if the headers were hard to
spoof, leading to a heavy duty processing requirement at odds with the idea
of preventing DOS. Thus we may consider these two objectives to represent a
tradeoff.

A cynic might say that the purpose of this requirement is to give
organizations a warm and fuzzy feeling that all the traffic on their
internal network had been "checked" by somebody. An even more cynical
observer might say that the real purpose is to give the firewall some role
in Web Services and thus insure the perpetuation of and perhaps even new
product opportunities in this market segment.

However, whatever the objectives, I believe we should either list them
explicitly or provide more detail about the working of the usage scenario.

I agree with Hugo, that this appears to be a special case of an
intermediary, but that raises a number of points. For example, as I
understand it, SOAP headers are supposed to be labeled with the Actor/Role
of the intended consumer of that header. Is the originator or some other
party (whom?) supposed to address a header to the firewall? What if there is
no firewall? Is it required that the configuration ensure that the message
pass thru the firewall? Discussion on another thread suggests that the
presence of a header provides no guarantee that it will be processed by any
Actor/Role.

Or is the firewall allowed to look at the headers addressed to other
Actors/Roles? Which ones and are there any limits to this? As a reductio ad
absurdum consider that if the firewall only inspects information generated
for other parties, there may be no need to specify anything at all in this
area and no way to prevent the firewall from doing whatever it chooses.
However, in my experience, having two widely separated components, firewall
and application in this case, trying to enforce the same security policy on
the same data will lead to brittle systems.

I am particularly worried about the case where some of the header
information is encrypted for privacy or other reasons. If the firewall
mavens insist on the right to inspect the data, this will lead to
distributing secret keys widely, which is both costly and IMO reduces the
overall level of security.

Now suppose the firewall inspects some header and doesn't like what it sees.
Is it supposed to 1) return an error 2) silently discard 3) add to or remove
headers before forwarding? #2 is the traditional answer, but it will
certainly make it difficult to track down the source of configuration errors
in a complex transaction scenario. Suppose the firewall likes what it sees
(presumably a common case). Is it supposed to add to the headers, remove any
addressed to it, pass the message unmodified? And will end systems be
expected to check header data added by the firewall?

Without knowing the intent of the usage scenario, it is difficult to see
what the proper answers to these questions should be.

Hal