Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

Neil Madden <neil.madden@forgerock.com> Wed, 10 February 2021 08:15 UTC

Return-Path: <neil.madden@forgerock.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 2A3AB3A0E22 for <oauth@ietfa.amsl.com>; Wed, 10 Feb 2021 00:15:57 -0800 (PST)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 faqDY9-KS4C7 for <oauth@ietfa.amsl.com>; Wed, 10 Feb 2021 00:15:54 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 156C63A0E23 for <oauth@ietf.org>; Wed, 10 Feb 2021 00:15:53 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id 7so1464732wrz.0 for <oauth@ietf.org>; Wed, 10 Feb 2021 00:15:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=aQK6JyGn4Cz8QxtBhgVOIw1Dx56jmEWfcuPiqGIZWVI=; b=P6IzviEk+2krpUXyAV7GZ56fmFAdwfJBhd4oCneba6t4clhFvz2tChiW48zspMlo67 E7sT4f6736x1xEBptKCOr7KW168937VMjYKLD2BDkBaEaNwOI3G72MCeD6O/0r+3bEvb D36sGhbdEkki/ks2OoR4O1VUmxD2Ay0dMQVts=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=aQK6JyGn4Cz8QxtBhgVOIw1Dx56jmEWfcuPiqGIZWVI=; b=rThEdSyUFCrPmKjYpV2nqE4lKWwqmpnKRVImQxE7Uzh5jNrLovKAfsZJrZNDIKOUP4 idHXJDNO5l6Eha+oR8j6ae25Jzn6dek0vPZX48tHQXIXti7bj/vZ9D2YD/AlfoIfbDSV 6aq49WBbz4F0jYZdKdjvfhm97ZR3lYMig0dr/o+H24EnbyVab052Nx3D48FYUFEpMRxl A/tH0AYNZSD6I/mwojUj/tP82IfmHxaBTyCIqFyhhieFKv0AiJVj6Psz0+snywogqG3Y orUAF32ZwlqJr4M925T907HXWseGASWoLi7IBeeobL9rG3YPzBRF1zeu5FacvcmdYgFz qujg==
X-Gm-Message-State: AOAM530fesOyg4nKW2Fb7xed212ntHnVRj64Qt7SUhPdBXegMDp+ZazH 2E82+OO8dy2Qb4yKiACBdHyKu4DKORfn11MiEJAqITnFjdDDWHnXSpZeCCS7660oeL/dErI/JA= =
X-Google-Smtp-Source: ABdhPJwkOOhhfWlA0hrdoHicWLkwC6/9UIQ22p2H1tG83RYU5dTfytNleQM4qvn5CGdWsvefWjgGGA==
X-Received: by 2002:a5d:654f:: with SMTP id z15mr2258925wrv.46.1612944952172; Wed, 10 Feb 2021 00:15:52 -0800 (PST)
Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y63sm1484847wmd.21.2021.02.10.00.15.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Feb 2021 00:15:51 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 10 Feb 2021 08:15:49 +0000
Message-Id: <54711021-47F1-4F69-8CCC-D96271A47474@forgerock.com>
References: <CALkShcsVGaqfmbimpaVdJS-r1yDpJhunjMi2UGV6+5tt4ZG_rA@mail.gmail.com>
Cc: oauth <oauth@ietf.org>, draft-ietf-oauth-jwt-introspection-response@ietf.org
In-Reply-To: <CALkShcsVGaqfmbimpaVdJS-r1yDpJhunjMi2UGV6+5tt4ZG_rA@mail.gmail.com>
To: Andrii Deinega <andrii.deinega@gmail.com>
X-Mailer: iPhone Mail (18C66)
Content-Type: multipart/alternative; boundary=Apple-Mail-A7A93B8D-03F1-40FA-8D45-85AF193B89AC
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xv_rGlqutIJ-iYuBGdkcDIxzb7Q>
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce
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: Wed, 10 Feb 2021 08:15:57 -0000

> On 9 Feb 2021, at 22:04, Andrii Deinega <andrii.deinega@gmail.com> wrote:
> 
> 
> I still don't see how your #1 and #3 points mitigate the replay attack when an attacker somehow eavesdrops a successful response from an AS (yes, it's signed by a public key) and then starts to replay it for other requests from the same client.

The point of #1 is that an attacker that has compromised the communication channel between the AS and client can do much more than replay introspection responses. In particular they can replace the AS’s public key with their own and then sign their own introspection JWTs, with whatever nonce in them that they like (they can easily see the nonce in the request). 

They can also steal access tokens and almost certainly also steal user session cookies and manipulate authorization responses from users to change the scopes that are approved for different requests. 

It’s absolutely essential that ASs and clients ensure the TLS connection between them is secure. 

The stated purpose of JWT introspection responses is for non-repudiation. It’s not intended as a replacement for TLS. Within that context “iat” is sufficient proof of freshness. 

> 
> The main problem here is that the client doesn't have a way to correlate the introspection response with the initial introspection request.

In a properly secured environment this guaranteed by TLS (and even TCP). 

> 
> Regarding #2, it's true that there are many proxies that do this and that. In practice, you don't always have control over the infrastructure where you may run your AS as I was saying before.

Right - so trying to solve this issue by replacing TLS with another technology that is just as susceptible to the problem is not a real solution. 

— Neil

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>