Association Handles and Service URIs

[Marius Scurtescu]

On 25-Aug-06, at 10:52 AM, Kevin Turner wrote:

> On Thu, 2006-08-24 at 17:49 -0700, Marius Scurtescu wrote:
>
>> The only party interested in verifying the assertion is the RP. Why
>> would the RP send something else than its real URI? It cannot steal
>> associations made with other RPs since a new one will be generated.
>
> Then, at the very least, I could DoS communications between a relying
> party and an IdP by repeatedly asking that IdP for new associations  
> with
> that RP's address, thus expiring any association that RP was actually
> using.

True, DoS would be very easy in this case.

>
>>> The RP needs that handle to distinguish between other associations
>>> issued by that IdP, as associations may expire or be otherwise
>>> invalidated.
>>
>> True, but only one active association exists at any give time for
>> each IdP. Is there a need to track expired or invalid associations?
>
> You're right, there is typically only one active association.  I  
> suppose
> there is a borderline case where the RP sends a request with one
> association handle, but in the time between when you make the request
> and get a response, a new association has been established...  but  
> since
> new associations are typically only established when the old one  
> becomes
> invalid, it's questionable if you should accept the response in that
> case anyway.

You bring up a good point, what happens if a new association is  
established while there are active transactions? If you don't accept  
the transaction then this leads to bad user experience. I can see two  
solutions here:
- if the association based verification fails then fall back to  
direct verification (this would also prevent the DoS attack described  
above), but the spec should allow you to do this
- allow multiple associations to be active, you will ask for a new  
association before the previous one expired and then unfinished  
transactions can still complete properly, this complicates  
association management a bit

>
>
>>> The RP also needs that handle because that's the only way it can
>>> talk to
>>> the IdP about which handle to use.  (because, as discussed above,  
>>> the
>>> IdP cannot look up a handle from a return_to or trust root.)
>>
>> As far as I can tell the IdP could use the return_to or the trust  
>> root.
>
> I think it is useful to know whether the IdP and the RP have the same
> idea of the "current" association.  If you do not issue new handles to
> new associations, but always use the RP's address instead, when a
> signature doesn't check out you can't tell if it's because you're  
> using
> the wrong association, or if it's because the message was corrupted.
> That seems like a worthwhile distinction to be able to make.

Yes, I agree. Thanks for the clarifications.

Marius