[WG-UMA] Discussion on Github Issue #99

George Fletcher george.fletcher at teamaol.com
Thu Aug 28 13:35:36 CDT 2014

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 <mailto: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

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

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

More information about the WG-UMA mailing list