Understanding the Session Fixation Attack on UMA Claims-Gathering and the Provided Mitigation

...

• The state parameter provides no support to distinguish the attacker's transaction context and the victim's context. The victim's client simply fails when attempting to continue seeking access because the session was initiated by the attacker. The transaction context of record is the attacker's.
• The ticket parameter provides no support to distinguish the two contexts because UMA V1.0 and V1.0.1 (and possible future minor versions) require its value to be the same across the entire process of claims-gathering when a requesting party is seeking access to a particular resource. It could be said that the root problem of the session fixation is in the "fixed" nature of permission tickets in the cycle of 1) requesting party claims endpoint usage with a ticket parameter and 2) the response from the AS with the same ticket parameter repeated.

Discussion of the Provided Mitigation and Others Considered

The UMA Work Group has provided a mitigation of this attack in the form of an extension specification (add link).

...

• Adding a new query parameter to the authorization server response URI: It is possible to keep the permission ticket value static and add a wholly new query parameter to add the needed entropy. The Work Group rejected this solution because it would likely add complexity to the client. Through implementation testing, it was confirmed that the solution chosen can actually reduce client complexity. UMA's design principle 10 prefers for complexity to be borne by the authorization server instead of the client.
• Refactoring the UMA flow to remove the requesting party claims endpoint: It has been suggested in a different context to remove the requesting party claims endpoint altogether by collapsing it into a "standard OAuth" endpoint, which presents an opportunity to mitigate the attack a different way. Although this idea will be examined at a later date, the work item is sufficiently unrelated and large as to stand in the way of an expeditious mitigation for this attack.
• Combining trust elevation methods: As the extension specification notes, only the requesting party claims endpoint is susceptible to the session fixation attack. It is possible for the authorization server to combine claims-gathering and authentication context-based trust elevation in a single overall UMA flow (through a sequence of need_info responses) as a method of sufficiently distinguishing attacker and victim transaction context to mitigate the session fixation attack. For example, if the authorization server needed requesting party Bob to meet two policy conditions, one regarding his strongly authenticated identity which could be met through knowledge of AAT session context, and another regarding his current professional certification status which could only be met through an interactive claims-gathering flow at a certifying body, this combination could be apropos. However, the authentication context-based method must be sufficient to deny access to the attacker; not every UMA ecosystem will find such combinations fit for their trust elevation purposes, ; and even in those cases, no formal specification of this method of mitigating the attack seems warranted.

To read about other types of attacks for which strong authentication through authentication context-based trust elevation may apply, see this section of the UMA Security Considerations.