Potential ticket injection attack?

[jricher]

In §3.6.2 the spec states:

ticket
  The permission ticket that was in the client's request for authorization data. 
  If the authorization server provides the "redirect_user" property, it MUST also 
  provide the "ticket" property. This helps the client avoid maintaining this state 
  information after the redirect.

If a client keeps no state on what ticket it's trying to process from this request, what's to prevent a rogue AS (or impostor) from injecting a new ticket in the response? As in, the client gets a valid ticket, then in the response a new, unrelated ticket is returned which the client then goes to attach claims to. This could be used to trick a client into getting its RqP to attach claims for a ticket ultimately destined for another (malicious) client.

I'm not sure of the exact attack vector or its consequences, so this may be moot in a practical sense. However: if the server is required to return the same ticket, the client should be encouraged to verify this. If the server is not required to return the same ticket, then the client should be told that this is a possibility and it should not ever check the value.

[xmlgrrl]

I see your point...theoretically. The only practical consequences I can think of are that the client might end up getting some set of authorization data that is more than, less than (including zero), or different from what it thought it was trying to access. Since "more than" should be okay, and "less than" (including "zero") is always a possibility, and "different from" will be perceived as "zero" wrt the currently sought resource, it does seem moot. Of course, a rogue AS is still not a good thing!

But since the point of the ticket return was client convenience, if we think the client "SHOULD" or "MUST" be checking that the value is the same, there's no point including it in the response.

[xmlgrrl]

In UMA ad hoc telecon 2015-09-08 (which had quorum), this was the discussion -- no conclusion yet:

"Since the client in the “one-down” position of having to trust the AS more than the AS trusts the client, the realistic business risk (vs. the “raw” threat) is quite low. Given that, and given the fact that if we don’t require clients to doublecheck the AS’s work they won’t do it :-), should we just keep the current spec wording? Then again, maybe the AS is just broken, and not malicious. Should we add an in-line note that the client SHOULD check that the ticket is the same? In that case, our rationale for having the AS save the client work is pointless.

If we force the client to save the state, then the AS doesn’t have to do anything, and there’s nothing to get wrong! It means the client has to do a bit more work, guaranteed, but it was looking like it had to anyway. IOW, if it had to save state to check the AS’s work, which the AS did in order to save the client some work, then the client saved no work…

Is there any other rationale at all for the AS returning the ticket? We don’t think so.

But taking away a MUST would be backwards-incompatible. So let’s discuss this on Thursday."