OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [wss] ISSUE: denial of service attacks

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]