Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

Denis <denis.ietf@free.fr> Tue, 14 April 2020 15:23 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DFC3A0901 for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 08:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 745rNSaNvTnw for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 08:23:11 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C173A08FF for <oauth@ietf.org>; Tue, 14 Apr 2020 08:23:10 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d22 with ME id SfP72200b4FMSmm03fP8Vq; Tue, 14 Apr 2020 17:23:09 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 14 Apr 2020 17:23:09 +0200
X-ME-IP: 86.238.65.197
To: George Fletcher <gffletch@aol.com>, oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com> <CAGL6epJ6W6AKptXw72cw2eaO+582_iYhKSK5h6BGBWeDJW9zNg@mail.gmail.com> <CAGL6epJc4CGDy9DwL3-BJh6MrELY3C-RUmcH716WN4k3Un11FA@mail.gmail.com> <361d7891-01be-8e22-7765-613e727b2bc1@free.fr> <CAD9ie-u4xaoRmNG3Sgj+cNWG4M8BzaM1YFF4Oy4Q2A6gdFWDhw@mail.gmail.com> <CAGBSGjpV=QNHPJfXXLcxHwYwHZrKXEQVjf3eJg+b8z=qpRAJcA@mail.gmail.com> <CAO_FVe67Ta_c1stGAH2b6mC_9FcfcZ_Vs6OdD4S4--vOac_y-g@mail.gmail.com> <CAO_FVe7hZH+83=OzU3b-c_b1XkCKbbKe+EVQ5vs++HO31orWkg@mail.gmail.com> <CAD9ie-ucnSnE=yW6PM6BFke7aS+Hs6z5DrE3zg0YLiikeK=9Ww@mail.gmail.com> <CAO_FVe7Ki=9+GGGRQUb3+shEiNkn4Dvpa9S6ukCZvkPOOKBHhQ@mail.gmail.com> <60478f63-257c-a05a-1587-505b9190205e@free.fr> <871581ba-ab3e-da6f-90f2-083803defbea@aol.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr>
Date: Tue, 14 Apr 2020 17:23:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <871581ba-ab3e-da6f-90f2-083803defbea@aol.com>
Content-Type: multipart/alternative; boundary="------------E0C604B01AC1B9F3E7F1C8F1"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BBXESpVo1doQzu-PNzVON7rJdEU>
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 15:23:13 -0000

George,

I disagree with you:

    The 'sub' claim must be unique (local to the issuer or globally)
    with every issued token.

In addition, inter-API correlation prevention does not necessarily 
require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used 
during the whole session (during successive calls).

Denis

>
>
> On 4/14/20 10:23 AM, Denis wrote:
>> Unfortunately, this is not possible since RFC 7519 (4.1.2) states:
>>
>>         The subject value MUST either be scoped to be *locally unique 
>> in the context of the issuer or be globally unique*.
> Regarding this phrase from RFC 7519, I don't agree that it prevents 
> the solution Vittorio suggested. While for any token issued the 'sub' 
> claim must be unique (local to the issuer or globally); that doesn't 
> mean it can't be different with every issued token. This would require 
> the client to request a new token before every API invocation but it 
> would suffice to protect against the suggested privacy correlation 
> issues.
>
> Note that inter-API correlation prevention is VERY difficult and 
> really requires a unique token for every API call as the token itself 
> can be a correlation handle (e.g. hash the token and it becomes the 
> correlation identifier if the token is being reused for multiple API 
> calls).
>
> Thanks,
> George
>