wss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [wss] ISSUE: denial of service attacks
- From: Jerry Schwarz <jerry.schwarz@oracle.com>
- To: Web Services Security <wss@lists.oasis-open.org>
- Date: Thu, 13 Mar 2003 15:02:11 -0800
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]