[wss] ISSUE: denial of service attacks

[Jerry Schwarz <jerry.schwarz@oracle.com>]

Version 11 [line 1478]

These can be grouped into two classes of errors: unsupported and failure. For the case of

unsupported errors, the recipient MAY provide a response that informs the sender of supported

formats, etc. For failure errors, the recipient MAY choose not to respond, as this may be a form

of Denial of Service (DOS) or cryptographic attack. We combine signature and encryption

failures to mitigate certain types of attacks

If a failure is returned to a sender then the failure MUST be reported using SOAP's Fault

mechanism. The following tables outline the predefined security fault codes. The "unsupported"

class of errors are:

First, the argument against a must for failure errors doesn't apply
to the "unsupported errors", so I think the first MAY should be
changed to be a MUST

With regards to denial of service attacks, I mentioned the above on an
email list that was discussing whether specific responses should be
required to certain ill-formed messages and the general consensus of (the
non security experts) there was that they should require responses within
their protocol, and that anything that was done to defeat a denial of
service attack would be outside the scope of their spec.  I agreed
with them and I think the same argument applies to WSS. 

With regards to crypto attacks I can be corrected by the crypto experts,
but I think crypo attacks can be dealt with by providing a generic
wsse:InvalidSecurity response that provides no more information than does
a failure to respond.

So I propose that the above paragraphs be replaced by something like

If a service does not perform its normal operation because of the contents of the Security header, then that MUST be reported using SOAP's Fault Mechanism.  However, this specification does not preclude action being taken by a site to suppress processing of messages that appear to be part of a denial of service or cryptographic attack.