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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: RE: Artifact binding -- Most effective binding against DOS attacks


Ahh… After re-reading, you’re examining using artifact model for the AuthnRequest.   I guess that is possible with the new artifact->message binding in 2.0, though I haven’t seen anybody actually implement it that way.   This would reduce the processing at the IdP of the AuthnRequest message to only doing so for trusted SPs but it also requires that the SP maintain an artifact resolution service – in most deployments they work to ease the requirements on the SP since there typically are more SPs than IdPs, so I wouldn’t see them easily adopting the overhead to deal with an artifact resolution service (it’s not simple).

 

Conor

 

From: Cahill, Conor P
Sent: Monday, June 30, 2008 8:46 AM
To: giorgimoniava@yahoo.com; saml-dev@lists.oasis-open.org
Subject: RE: Artifact binding -- Most effective binding against DOS attacks

 

The IdP must expose a means by which an SP can obtain the artifact.  This is the standard AuthnReqest entry point (I don’t know the metadata element off the top of my head) where the SP redirects the browser to in order to initiate SSO from the IdP.    That’s still needed in the artifact model (which typically involves SP sending AuthnRequest to IdP through users browser, IdP responding to SP with Artifact through user’s browser, and finally SP dereferencing artifact on back channel directly with IdP).

 

So, even if you use the Artifact profile, you still need the browser based AuthnRequest exchange in order to get the artifact to the SP.    Since the IdP has to support AuthnRequest, the attacker could still use this channel for a direct DOS attack.

 

Conor

 

From: giorgi moniava [mailto:giorgimoniava@yahoo.com]
Sent: Monday, June 30, 2008 7:18 AM
To: saml-dev@lists.oasis-open.org; Cahill, Conor P
Subject: RE: Artifact binding -- Most effective binding against DOS attacks

 

Hi Conor.

 

With point (b) you make a good point about implicit DOS attacks in SAML 2.0.

 

However, I don't get your statement: "The IDP still has a AuthnRequest entry point for SSO requests and must process the request as necessary and thus that interface could still be used for enabling a DOS attack by flooding the IdP with bazillions of AuthnRequests long before you ever get to the stage of artifact dereference. "

 

To my knowledge, an IdP first receives an artifact (using an HTTP redirect), and then, it

contacts the corresponding SP (who is the owner of the artifact), and aks to resolve the

received artifact. If at this stage, authentication and access control are combined, then

IdP will make sure that she won't receive any resolved messages from illegimitate SPs'. Also, once an SP will be recorded as malicious, IdP will refure to resolve artifacts from that SP in the future.

 

Further, just wondering, why could not SAML 2.0 design artifacts such that, at the time of their receival, both parties could be able to make sure that the received artifact was generated by a legitimate party. This way, DOS attacks would be efficiently and effectively avoided -- i.e. without the need to contact partner entities for resolving invalid artifacts.

 

Giorgi.

--- On Mon, 6/30/08, Cahill, Conor P <conor.p.cahill@intel.com> wrote:

From: Cahill, Conor P <conor.p.cahill@intel.com>
Subject: RE: Artifact binding -- Most effective binding against DOS attacks
To: giorgimoniava@yahoo.com, saml-dev@lists.oasis-open.org
Date: Monday, June 30, 2008, 4:05 AM

In reality, I think that the artifact profile will have limited, if any, impact on DOS attacks.   The IDP still has a AuthnRequest entry point for SSO requests and must process the request as necessary and thus that interface could still be used for enabling a DOS attack by flooding the IdP with bazillions of AuthnRequests long before you ever get to the stage of artifact dereference. 

 

At first glance one might think that the artifact profile will save the IdP from having to generate the signed Assertion since attackers are not trusted SPs.  However, a) in a DOS attack the IdP usually wonąt be generating an assertion anyway since the logins will typically fail, and b) if the attacker does have good credentials (so the IdP would end up creating a good authn session and have to generate assertions at some point), they could still get the assertions to be generated by doing an indirect DOS attack using a multitude of good SPs and driving the IdP attack through those SPs (the attacker essentially initiates Authn sessions at the SPs causing the SPs to flood the IdP with authnRequests & artifact resolutions).

 

So, from a DOS point of view, I think it doesnąt make a difference.

 

Of course, there are many other good reasons to use the artifact profile.

 

Conor

 

From: giorgi moniava [mailto:giorgimoniava@yahoo.com]
Sent: Monday, June 30, 2008 3:48 AM
To: saml-dev@lists.oasis-open.org; Cahill, Conor P
Subject: Artifact binding -- Most effective binding against DOS attacks

 

Hi all.

Just wanted to ask your opinion about following statement. I think that
artifact based binding has the highest chances to be effectively secured
against DOS attacks. Since, when an IdP received an artifact, which comes
from an malicious SP, and tries to contat her in order to retrieve the corresponding
message using SOAP binding, she will use SSL/TLS with bilateral authentication,
clearly, if she looks up the identitied of the available parties then, requests from
malicious SPs will be blocked (i.e. IdP wont receive SAML 2.0 messages from
them, just artifacts). With POST and GET bindings, IdP is forced to process
a SAML 2.0 message before she can take any action for protecting against DOS.
Does what I wrote make sense?

Thanks!.

Giorgi.

 

 



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