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

Vittorio Bertocci <vittorio.bertocci@auth0.com> Tue, 14 April 2020 18:07 UTC

Return-Path: <vittorio.bertocci@auth0.com>
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 B44AF3A08C1 for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 11:07:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=auth0.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 JpCDy_pbQACX for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 11:07:48 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 D7A0B3A08BB for <oauth@ietf.org>; Tue, 14 Apr 2020 11:07:48 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id w11so234178pga.12 for <oauth@ietf.org>; Tue, 14 Apr 2020 11:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=3EcUr8ownSZObdFSDDTEXdrn3kiavKVZsVTii8lnnh4=; b=kl6QGYyJn9f2b0+E11agRxObac6Wqzs2T1zsizU+4QV0lsA7e1nWPgL58c+LL+5cwH oPL/p5bMeVWdcn6gksw4P6A2PhdVBpiw4EQkzoC+0Mh77/lFrtAnV26D0fhbRKv8Cn3w QiIJGtAJ7x4LTMILlO83WFyb30nCMrkWDfEdSuIRM8eHN/Ag1zbeNoOs9e1zEG/GrslL 3tLCSiIt+1zos9Nu+Bq6kvf0K6yDp5gKmt9zc+aqjvvFWPPJAqYq4fmPCcYi30273Y5p v9pbS65Vf3YtCLh/9puQesLAdx92a4YoTaVt+HpqTrLziFgBBNYclPf1tvcXNCY9rxku fW9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=3EcUr8ownSZObdFSDDTEXdrn3kiavKVZsVTii8lnnh4=; b=bEIZ3NMLuZncl3uTyKpk1RcUltFyW8QRqgHXobn2dAXB5t3/+knfCB0iok56eix8AA OgLBARNBj1vgYsIlyRZKCDWSxL4N5GOURppTCk+VEspMPXSXL6bFB886pPl5NU442odK B24QG/r1AQhkbUcOG5ZP9kz+xk+tuRK1o9VXnOf2U/fZdP2ATdZsmTUFEGSnIgxfsib2 dSVCoMPlG82f7L8z9GQ5y6gfz7d+QpMmwKxhEdik6KIwwkt+AW1U29E7G3/BESS+D1V/ WysmxckBpZeWYN3Bx3hknTw6lwwXjH6hbtEq4aBsmvNJpuf2T7S244XGEP8Uk+xBXENN WEkQ==
X-Gm-Message-State: AGi0PuZNGnf5Nq9af2X8axj86v++ItmxKZ2xdoebpGvPMI6+8EyELR74 lebpfwPy4NMlz+JMTJeZtfZQOw==
X-Google-Smtp-Source: APiQypLv8jINRCHT3kkXrbBKJPrehMfTLspp70Lv7nEaa32QJXBEzAKXZY+fMkGf5NIrxPdso8J8/A==
X-Received: by 2002:a62:3144:: with SMTP id x65mr15374868pfx.66.1586887667754; Tue, 14 Apr 2020 11:07:47 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id r189sm10683159pgr.31.2020.04.14.11.07.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2020 11:07:42 -0700 (PDT)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>, Denis <denis.ietf@free.fr>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
Thread-Index: ATM1ODU3+R1ahTgRmb+LKJAgdDe1pmdHaXc2QVdDQkMxNzY4MXdRYSthQWJFeFFnNFpiYWcrYi1Id1k2QlNRWkQzPWU5OGEzYTBmZGFkZTgxY2M0MTdhn/2gfK8=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 14 Apr 2020 18:07:41 +0000
Message-ID: <MWHPR19MB1501AB7EB499AECDC1D8001CAEDA0@MWHPR19MB1501.namprd19.prod.outlook.com>
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> <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr> <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com>
In-Reply-To: <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB1501AB7EB499AECDC1D8001CAEDA0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/840wun-vNBQT5TEHxfnRJ4ecpuc>
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 18:07:51 -0000

Thanks George, you described exactly what I was thinking.
I agree with your conclusions throughout the thread. Now that we have JTI mandatory, preventing tracking intra-API could be achieved only by issuing a new token for every transaction regardless of the presence of a sub, and a sub whose values change at every issuance would achieve the same.
One subtlety that perhaps is worth spelling out is that “unique” in this context shouldn’t be interpreted as “singleton”. An identifier is unique if it cannot be used to indicate any entity other than the intended one, but that doesn’t prevent the same entity from having multiple unique identifiers as long as they all satisfy that uniqueness criterion. And again, I maintain that preventing intra-API tracking is a non-goal in most scenarios.

That said, this was a great discussion. I am going to add explicit language in the privacy considerations warning readers about the possibility of correlation, and hinting at some of the measures described here as possible mitigations.
Thanks everyone!
V.

From: OAuth <oauth-bounces@ietf.org> on behalf of George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Date: Tuesday, April 14, 2020 at 08:35
To: Denis <denis.ietf@free.fr>fr>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

Hi Denis,

If the same token is used (within a session) for multiple API calls then all those API calls can be correlated together even if the token does not have a 'sub' claim because the token itself is the correlating identifier (same is true for the session identifier).

In regards to the AS issuing a token with a 'sub' claim, after re-reading the spec (rfc 7519) I believe the AS could issue the 'sub' value as "urn:anonymous:<large random number>" and create a new value with every token that is issued. This is similar to how Shibboleth supports attribute based access control with SAML assertions. Given it appears we disagree in our interpretations of the spec, I'm fine agreeing to disagree :)

Thanks,
George
On 4/14/20 11:23 AM, Denis wrote:
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