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

Dick Hardt <dick.hardt@gmail.com> Fri, 10 July 2020 20:03 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32343A08EC for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 13:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1x3sbVnuQ9J for <txauth@ietfa.amsl.com>; Fri, 10 Jul 2020 13:03:20 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235153A08F6 for <txauth@ietf.org>; Fri, 10 Jul 2020 13:03:20 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id r19so7766087ljn.12 for <txauth@ietf.org>; Fri, 10 Jul 2020 13:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=znKtju4DOEbo6l3Z4nGEd0rJ/4K5ae2obTqhwNSG54Y=; b=qr5wpWJUabYF5eKT+vHXOqgZrd5QhpSB4qKyoT4o3Y3xFKevT5eE5lz4q6jIkMGUlp VgXrPiPgSRTsbmbzSdxre1aKu1oI44cun2tiovH4uFyI74hTpZVD6WSyqcC5e8ID1xcV cWmHgK85egHCeoVfTHKp8zmv9zoMl4sOLnoi6XScHmFlnKZEJL+FWWPwdns2TTbqxTqk IBE6XntPKNUQOTrfKYr8tKerprrhrpczcJ+0mf/esiFFsJHG5btlhQDzpGV4fXFnaWzC 5QLGI0INJ8NLywrAYpfvn14u1cToQmIE6L4e2JCZaf693JQvZSeBZXrGpIgBmqTew57U Dmwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=znKtju4DOEbo6l3Z4nGEd0rJ/4K5ae2obTqhwNSG54Y=; b=IjVTbsX8c5+0mllrtnj7w3zrvpOTCofqLwq4kR0bJyXiaIJ6I3H+OuraRCE/79acDE +Wk1nPtCNSXe1wL+Vw6DsfPfstOP6lEWu0wGe5is+N8TF2cXF8GNEQoc3AIYMu1jchHi GFQ9lGFuYwzjAsE1NlqlpTjcwroxKaIgPK8X2Avt21O7kJ8bVlKiBQAO+Csia57Znkbm +lgrQQLRIQL6xwS7OPupdftQdGVjmZwTjii3A7jXuHKyryRLvwArN86IPlqPyaUilJ80 hdK9cnbJ7RG4JqMrbhYDLAOmJ2+H27m0tpDqj2InnyH+ZeRIDX39wA+DZ6EmIwTCl+ve ob7Q==
X-Gm-Message-State: AOAM531UTzqiH0e+MVJtocA7EMZE1d3IYncH0A5yCQDe568DjATGLMdA 5WsuewI95i5ThNmrJZU1eIW+kvZCtOF0NNQb6ZA=
X-Google-Smtp-Source: ABdhPJxntjpaIuDFFmfIVW2dJGECiUcr9Pa531RhetIDC719avQVUTe7RA/0cgDPJEyvF7bNZMQhaUX0jCehU53OsiY=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3822701ljg.69.1594411397859; Fri, 10 Jul 2020 13:03:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-ssYwUsKYuU-wHwU8113+HFQLp6trpO5KM6W+u4hLWG5A@mail.gmail.com>
In-Reply-To: <CAD9ie-ssYwUsKYuU-wHwU8113+HFQLp6trpO5KM6W+u4hLWG5A@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 10 Jul 2020 13:02:41 -0700
Message-ID: <CAD9ie-u0o3zkoo1FncHntNmWko=DS4BkZB1CTLOH-s-Es-yOig@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org, Daniel Fett <fett@danielfett.de>
Content-Type: multipart/alternative; boundary="000000000000fecdd905aa1bd4b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/MDEfQuUqIJcxZTEE3hQVqxYt-Sc>
Subject: Re: [Txauth] Interaction capabilities vs modes (was: XYZ-08 vs XAuth-08)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2020 20:03:23 -0000

Hey Justin,

Bringing this discussion back up to the top of your stack.

In my implementation, the AS has a policy that 'write' access is only
available if the mode is 'redirect'. It was easy to not provide an mode
request, and it was clear to the Client that a 'redirect' mode is all that
is required.

Additionally, my implementation had different pre-fix paths for inbound
'redirect' and 'indirect' flows, so I could use the router to invoke
different functions depending on the use case. This is possible as the
'redirect' and 'indirect' responses from the AS each have their own URIs.

In your Medium article on interactions[1] you talk about the app to app
communication. Currently, the major two platforms are using https as a
means for the calling app to clearly identify the recipient app, and for
the platform to bind app identity to a URI. I don't see how GNAP is
going to change mobile platform behavior.

If your model is that the client is not invoking the AS app, but the AS is
invoking its own app, then there is no need for the client to know about
the interaction, although the client does need to confidently communicate
which user it is interacting with so that the AS knows which app install to
interact with. But the AS is all first party in this case, and the
interaction between the two does not need to be specified for interop.

As for the AS sending a push notification to a Client, that looks very
tricky to do. I don't know of any support for an app to specify which other
apps can send it a push. All push notifications I know of are 1st party.
3rd party pushes would require an agreement between parties, otherwise any
app could send a push to any other app.



[1] https://medium.com/@justinsecurity/xyz-interaction-a84091d2a8c8





On Tue, Jun 16, 2020 at 10:03 AM Dick Hardt <dick.hardt@gmail.com> wrote:

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