[WG-UMA] Discussion on Github Issue #99

Eve Maler eve at xmlgrrl.com
Thu Aug 28 20:38:16 CDT 2014


Regarding the DoS problem: My thinking was that an entirely untrusted client that hasn't done any work itself could force an RS and AS to do a lot of work for no reason if the spec demanded eager issuance of permission tickets. As you note, to get an RPT, the client has to get client credentials and then also get an AAT, which -- particularly if the latter involved the user explicitly -- is a fairly high bar. Is there any equivalent situation in OAuth or OIDC today that we could look at for comparison, I wonder?

Regarding single-RS vs. multi-RS scoping of RPTs: Maciej and I were speaking earlier today, and he felt that the privacy concern takes a back seat to the larger security/protection concern of controlling the token's scope. This is akin to your "audience" point, I think. Also, he reminded me how the NuveAM implementation associates an RPT with the RS. It actually has two ways. It does make available an extension feature to provide a "host id" (it has a different name) for doing the association at the time of RPT issuance, but its regular UMA-compliant flow simply waits until the client presents the ticket along with the RPT in the header when it's looking to add authorization data the first time, and uses the ticket to do the association. So in fact the current spec does support a way to do what we've said is necessary... We could still examine whether we want to have a different/additional way, but I was very glad to get this reminder. :)

	Eve

On 28 Aug 2014, at 11:35 AM, George Fletcher <george.fletcher at teamaol.com> wrote:

> More inline...
> 
> On 8/28/14, 1:40 PM, Eve Maler wrote:
>> On 28 Aug 2014, at 8:56 AM, George Fletcher <george.fletcher at teamaol.com> wrote:
>> 
>>> A few thoughts..
>>> 
>>> 1. I'm not sure that returning the permissions ticket on a request with no RPT is more susceptible to a DDoS attack. Especially if the model for RPT is that it is not bound to the RS in any way. Possibly the AS will need to create more permission tickets but these should be pretty light weight. 
>> 
>> The thinking was that an untrusted C could approach a protected resource repeatedly and require the RS to "do work":
>> 
>> C->RS: resource, please
>> RS->AS: ticket, please
>> AS->RS: ticket
>> RS->C: here's a ticket, go to AS
>> C (maliciously)->RS: same resource, please
>> ...
>> 
>> I guess there's a pretty easy mitigation: Only get the ticket once in repeated identical attempts. But then we'd have to say something about that if we forced the RS in "normal" circumstances to register the ticket eagerly...
> OK, from a DDoS perspective this is a little easier to implement than...
> 
> Malicious C gets an empty RPT for bogus user
> C - (with RPT) -> RS: resource, please
> RS->AS: ticket, please
> AS->RS: ticket
> RS->C: here's a ticket, go to AS
> <repeat>
> 
> Seems pretty easy to script into a BotNet and execute. There's not much protection for the RS in this case. As for the AS, the only protection it has is in granting AATs (required to get the RPT). If the AS does a good job, it may be able to limit the number of Cs dynamically registered and RPTs issued. However, I don't think this is going to make much of a dent if someone wants to execute a DDoS attack.
> 
> Maybe I'm missing something?
>> 
>>> 3. Related to #2, are there any security concerns if an RPT is not bound to an RS such that a given C could send the RPT to a completely different RS and it might work? In order to protect against unauthorized access the AS will need to manage an ACL of which C's can access the resource. Then if C is not on the ACL, a new permissions ticket will be generated to get authorization for C to access the resource.
>> 
>> Let's see. Going through the logic... The AS likely needs the client's identity as part of the policy decision-making state anyway (the RO will likely want to make policy around it, as Maciej's sample apps demonstrate). The RPT functions as a bearer token (as this profile's name indicates!) when presented at the RS, in that the RS doesn't make the client provide PoP in any way. This profile defines the on-the-wire token as an artifact that needs to be dereferenced. If the "wrong" RS asks for introspection of a token that doesn't match up with its PAT, then the AS would throw an error. Before we started using Justin's draft, I think we had a special error for, essentially, "wrong token for this PAT". Now it should just be an invalid token (for this RS). Should we say something explicit in the spec about this situation?
> OK, I think I missed something... in what context did the RPT get bound to the RS PAT? Is that by virtue of the associated permissions-tickets that have been authorized/associated with the RPT? I don't remember that being implied by the spec. If the AS treats the RPT as "claims for Bob at C" (e.g. verified email is bob at gmail.com) it's possible enough claims exist for the RPT to pass authorization policy at another RS without getting an error. If the AS needs to ensure that an RPT is only valid for the permissions-tickets requested via the RPT then we should list that, at a minimum, in the security considerations. 
> 
> This plus the general good hygiene of 'audience' have me leaning toward requiring RPTs to be bound to an RS. Hopefully if there are compelling use cases to the contrary someone will highlight them:)
> 
>> 
>>> 
>>> 4. I'm ok with optionality in the spec as long as we have good use cases to support it and the spec is updated to clearly reflect the optionality and potentially when a given option might/should be used.
>>> 
>>> Thanks,
>>> George
>>> 
>>> On 8/15/14, 4:06 PM, Casey Gilray wrote:
>>>> As issue #99 stands now there is an open question as to whether it would be better to automatically send a ticket along with an RPT to the clients instead of forcing them to request a ticket separately. Currently the client must request a resource from the RS and be sent an error requesting that the client get an RPT. The client obtains the RPT and tries the request again in order gain a permission ticket. The proposed work around is for the RS to obtain the RPT and automatically register the sought permissions, then return the new RPT along with the permissions ticket.
>>>> 
>>>> There are valid reasons to have both paths available. Issuing the ticket automatically may tie up more resources on the server side but this also frees the client from making several requests. This leaves the server more vulnerable to denial of service attacks at this endpoint. If you are not a high value target for DDoS or are otherwise not worried about attacks then having the server automatically issue the ticket along with the RPT would be a valid solution.
>>>> 
>>>> The second part of issue #99 deals with the binding between an RPT and the RS. When a client obtains an RPT there is no notion of which RS this RPT will be used with. It was suggested that the Client pass a host ID, a identifying token which is known by the AS. These hostID tokens could be stored dynamically or have static “trusted” host IDs depending on the security demands of the implementation.
>>>> 
>>>> In an attempt to open discussion to close issue #99 I will pose the following question: Would it be possible to add into the spec the option for the RS to either obtain and create tickets for requests automatically or make the client obtain and re-request with a new RPT OR, leave the spec as is where the client is forced to obtain their RPT from the AS, then attempt the request again to get the permissions ticket.
>>>> 
>>>> Secondly, In regards to binding could the RPT request include a host_id parameter that could match to a list of known and trusted RS’s, thus binding each RPT to one specific RS?
>>>> 
>>>> Link to issue #99: https://github.com/xmlgrrl/UMA-Specifications/issues/99
>>>> 
>> 
>> 
>> Eve Maler                                  http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>> 
> 
> -- 
> Chief Architect                   AIM:  gffletch
> Identity Services Engineering     Work: george.fletcher at teamaol.com
> AOL Inc.                          Home: gffletch at aol.com
> Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
> Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140828/7d55e59c/attachment-0001.html>


More information about the WG-UMA mailing list