[Txauth] Interaction capabilities vs modes (was: XYZ-08 vs XAuth-08)

Dick Hardt <dick.hardt@gmail.com> Tue, 16 June 2020 17:04 UTC

MIME-Version: 1.0
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 16 Jun 2020 10:03:57 -0700
Message-ID: <CAD9ie-ssYwUsKYuU-wHwU8113+HFQLp6trpO5KM6W+u4hLWG5A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org, Daniel Fett <fett@danielfett.de>
Content-Type: multipart/alternative; boundary="000000000000f7055905a8368835"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7ORftYAAHc4>
Subject: [Txauth] Interaction capabilities vs modes (was: XYZ-08 vs XAuth-08)
Precedence: list

Forking this thread to a new subject ...

+ Daniel for the security concern on preventing a session fixation attack.

On Mon, Jun 15, 2020 at 5:19 PM Dick Hardt <dick.hardt@gmail.com> wrote:

>
> On Wed, Jun 10, 2020 at 7:54 AM Justin Richer <jricher@mit.edu> wrote:
>
>> On Jun 9, 2020, at 4:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>
>> On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> wrote:
>>
>>>
>>>
>>> On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>
>>> <snip>

> In XAuth, if the server wants to protect itself from a session fixation
>>> attack in a given request, and it wants to support both "redirect" and
>>> "user_code" modes,
>>> the server will return only those two modes and not "indirect". The
>>>
>>> In XAuth, if the server wants to protect itself from a session fixation
>>> attack in a given request, and it wants to support both "redirect" and
>>> "user_code" modes,
>>> the server MUST return callback, redirect, and user_code. The client
>>> does not know that the "indirect" mode is not supported, and may try that.
>>>
>>>
>>> In XYZ, if the server wants to protect against a session fixation
>>> attack, it will reject a request that doesn’t have a “callback” field in
>>> it. The AS always gets to choose which things it supports for any given
>>> request. If the client wants to support both “redirect” and “user_code’
>>> modes AND has the ability to handle session fixation issues, it sends the
>>> “redirect”, “user_code’, and “callback” fields in its interaction request.
>>>
>>
>> If the client chooses to present the interaction_url as a scannable
>> barcode, which is an option if it receives one, it will then get an error
>> when it tries to do a transaction continue request as the AS protects
>> itself. Unfortunately the user has scanned the barcode and is now at the
>> AS. I don't see how the client learns it is not able to do what I call an
>> "indirect" mode interaction. Would you explain how this situation is
>> prevented in XYZ?
>>
>>
>> If the client has made a request with “redirect” and “callback” in its
>> request, and then decides to display the interaction URL as a scannable
>> code, then the AS will just redirect to the client’s callback URL when it’s
>> done, whatever that URL was. If the client sends a “callback” URL that it
>> can’t get information from, then that’s a poorly-written client, isn’t it?
>>
>
> Let me provide more clarity on the scenario.
>
> The client is a web app that can redirect the user to the AS, and receive
> a callback, it can display a code and URI to enter the code, or it can show
> a scannable code for the user to scan on their mobile phone. The user may
> be using the web app on a PC, and the AS is on their phone. The user
> chooses to scan the barcode with their phone. After authenticating with the
> AS, the AS redirects back to the callback URL. But the webpage is now on
> the user's mobile device, not the web app on the PC.
>
>
>>
>> If the client can’t get to the information in the callback URL unless
>> it’s on the same device, then the client isn’t going to show the user a
>> scannable code to be read by a secondary device. Why would it?
>>
>
> Because it is a better experience for the user per above.
>
> The AS parameters don't differentiate between a scannable URL and a URL
> that can only be redirected, so the client will think it can do anything.
>
> Additionally, in XAuth, the client can provide an informational URI for
> the AS to redirect after a scannable code or a user code flow.
>
>
I'll add additional clarity on what happens when the user experience
switches between the PC browser and the mobile browser. The client loses
context of which user the client is interacting with. An attacker can take
the interaction URL and trick a victim user into clicking on it (a session
fixation attack). The client does not know the difference between a real
user on the mobile device, and a victim on a mobile device. Neither
scenario has any session state from the original user interaction at the
client.

Providing a clear signal to the client that the AS won't support a
scannable code (or any other redirection to the AS that does not have a
redirection back to the same instance of the client).

/Dick

[Txauth] Interaction capabilities vs modes (was: … Dick Hardt
Re: [Txauth] Interaction capabilities vs modes (w… Dick Hardt