Your bullet number 1 seems reasonable.
Regarding bullet 2, I am not sure, since an attacker who
knows the ID's of the legitimate SP's could type it herself. In order to verify
the legitimacy of ID, one would need to verify signatures on the assertion,
which is a relatively computationally heavy operation, and can lead to DOS
attacks as well.
Yes. However, it’s pretty easy to throw out messages
with bad IDs without having to even look at the signature. They key
point being: Do the least costly checks first and only after they pass,
move onto the more costly checks.
Third bullet seems fine too :).
Fourth one, as I understood, suggests, in case of heavy
processing load on IDP, prior to validating any assertion, IDP should directly
authenticate the users who carry these assertions, that makes sense --if user
authentication is less computationally expensive operation than verifying the
assertion validity; which I doubt--, however only in the case, when the IDP's
sole purpose is user authentication, else a typical IDP would need a means to
differentiate whether the user is redirected to her as a part of SSO session,
or is just doing some surfing.
First off, IdPs are there for SSO sessions which are typically
rooted in an authenticated session with the IdP. So I have no problems
saying that an IdP can authenciate the user.
I do think that the typical authentication of the user is
cheaper than the processing and validation of signed AuthnRequests.
As far as the User experience, yes it will be a less than
desirable user experience. That’s why I said that the IdP should do
this when they thought they were under attack, not as a normal means of
business. It is reasonable to provide a lesser, but still usable,
experience when you think you’re under attach (rather than just refusing
service to all).
Conor
Giorgi.
"Cahill, Conor P" <conor.p.cahill@intel.com>
wrote:
I haven’t done any deep research on responding to DOS
attacks at a SAML IdP so take some of this with a grain of salt, but some of
the SAML related kinds of things I think might be useful could include:
- Validate that the
incoming request is reasonably sized *before* handing it to any
parsing module. One of the easiest DOS attacks is to send large XML
messages that get parsed before validation. A reasonably sized
AuthnRequest is pretty small.
- Validate the
SPProviderID is one of the SPs with which the IdP is willing to federate
with (e.g. is in the circle of trust) before doing anything else with the
message
- Give scheduling
preference to incoming requests that come with session information from
the IdP (e.g. they are associated with an existing session at the IdP via
some cookie you stored in the browser) these are less likely to be part of
the DOS attack.
- If the threat level
is increasing at the IdP (e.g. your processing load at the IdP is getting
near DOS stage) you might want to prompt for successful user
authentication prior to signing the message and possibly even prior to
parsing the incoming request as the validation of the credential could be
a much lower cost request/response than dealing with. I
wouldn’t do this as a normal course of business as it could result
in less than optimal user experience, but it may be a good reaction to a
concerted attack that will allow you to still give a reasonable level of
service to the users who can authenticate.
And, of course, there’s all the standard DOS prevention
techniques you can use that are not SAML specific (rate limiting, etc.).
From: giorgi moniava
[mailto:giorgimoniava@yahoo.com]
Sent: Friday, June 06, 2008 5:41 AM
To: saml-dev@lists.oasis-open.org
Subject: [saml-dev] SAML 2.0 DOS attacks
I would
like to ask one question if possible.
Namely,
how can and IdP protect against DOS attacks,
by
restricting allowed authentication requests from certain
SP's,
when an attacker can easily spoof IP addresses? --
i.e. is
there another way, to limit the set of SP's that can initiate user
authentication with the IdP? (I don't look at the cases hen one can use IPSec,
in order to prevent spoofing IP addresses-- that's one answer I guess, but I
wonder if there are other ways as well).
|