Next in thread → Next in month →

RE: [saml-dev] SAML 2.0 DOS attacks

From
Cahill, Conor P <>
Date
2008-06-06T12:08:18+00:00
ID
Thread
RE: [saml-dev] SAML 2.0 DOS attacks
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

 

Best Regards,

Giorgi.

"Cahill, Conor P" <>
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.).

 

Conor

 

From: giorgi moniava
[mailto:] 

Sent: Friday, June 06, 2008 5:41 AM

To: 

Subject: [saml-dev] SAML 2.0 DOS attacks

 

Hello.

 

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).

Thank you.

Kind
Regards,

Giorgi.
Next in thread → Next in month →