Re: [OAUTH-WG] Token scanning attacks in RFC 7662

Neil Madden <neil.madden@forgerock.com> Wed, 03 January 2018 14:09 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 4CAD9126B72 for <oauth@ietfa.amsl.com>; Wed, 3 Jan 2018 06:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 LF_ILm93x4MP for <oauth@ietfa.amsl.com>; Wed, 3 Jan 2018 06:09:54 -0800 (PST)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 7EED71201F8 for <oauth@ietf.org>; Wed, 3 Jan 2018 06:09:54 -0800 (PST)
Received: by mail-wr0-x232.google.com with SMTP id w68so1687915wrc.10 for <oauth@ietf.org>; Wed, 03 Jan 2018 06:09:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J1GCO6DZjKZiocaI0QzgAM+Q65ogbUXgWgldnoUlE9Y=; b=gxV/hUamUtr0NnTrD+hmkOkPhlrtpyza+3VVkNRv6pkvXwNcnfKEQfqeVgY5GFZp/a IpmrQ/zqIrGv5WGi5llUclNcMxg5tj+DTLELlOsYflebKMv5Wd8YYQv+Ce/wQcTasb3w Vo/3v8ba6SuSqANrLIrDzI/0cQGtfzdYaUSK4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J1GCO6DZjKZiocaI0QzgAM+Q65ogbUXgWgldnoUlE9Y=; b=mDsXZsBSXojsuJpgSlXZqfiP+3s0a8meuDA65kH1L7ZPPPg04+sTftJhUcC5IcPgA/ jBOnBA0rnh7zQ0OHCPZvhUpnvXqdrN5h7IHJWbB8RuesRZMoPYrj4+ilLuiLg1UZbva6 Hc4mphOYyMRstohtOSSKn5sAElOHx+TxMxsBJyrfA55WFvo90jf9ZEXVpe8GaisZD3Zl 2iQ4WFJUjudrqCdq0u4udIeIl1LPM4TACUhVfp15etSbkKweqF0tP7JH1j2ZwKqy11H6 zBkFAmEQ4IOBzUL9ovlDyAbxR6wzOKrXkvo4H0WPqXKA/bOGZf9+PoUEDWvl+LcgzDyn rNtw==
X-Gm-Message-State: AKGB3mKB9V/PpymO9xEZbVp8OZIYku783XFGFDyWOw5x4hRtstrcbpYV yod4bS9rCHbCdh/haQfuo7nCIrBcsds=
X-Google-Smtp-Source: ACJfBou1H2SH9FJqAdMA3YdO1zSdbdLTcEvQ6LOyTjPSgsBdtjioEhW7Bp85SMr34fiRiQhh4l2Fvw==
X-Received: by 10.223.179.77 with SMTP id k13mr1675578wrd.116.1514988592835; Wed, 03 Jan 2018 06:09:52 -0800 (PST)
Received: from guest2s-mbp.home.gateway (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id z5sm1011917wre.94.2018.01.03.06.09.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 06:09:51 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <34D0BF67-FBE7-499D-9132-948D35E71D1B@forgerock.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_25F2BAB0-3228-4FB4-8150-B802C9A68233"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 03 Jan 2018 14:09:50 +0000
In-Reply-To: <7594cea3-ea12-ffa7-6696-0e2347e70be6@connect2id.com>
Cc: OAuth WG <oauth@ietf.org>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
References: <AF1C81BC-485C-4BAB-9415-D85FAF50977D@forgerock.com> <665AE14D-F8A4-444E-88BF-B596937FF855@ve7jtb.com> <15B4232D-F137-426D-B9B3-D33DF9B5B7A2@forgerock.com> <7594cea3-ea12-ffa7-6696-0e2347e70be6@connect2id.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6En02o_TSsYOHiii2PyZVKF8MiQ>
Subject: Re: [OAUTH-WG] Token scanning attacks in RFC 7662
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 03 Jan 2018 14:09:57 -0000

On 3 Jan 2018, at 07:07, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
> 
> 
> On 02/01/18 19:01, Neil Madden wrote:
>> How does authentication address the problem?
> Authentication increases the effective entropy. An attacker fist has to be break the client secret, then successfully guess the token.


Authentication of parties using the introspection endpoint doesn’t increase entropy. If I have a 1 in 2^128 chance of correctly guessing an access token before you add authentication to the endpoint, then I still have the same probability of success afterwards. You’ve just made it harder for me to check my answers. But I can just try and actually use the token to see if it works. If access token guessing is a problem for token introspection, then it is a problem for essentially every part of the OAuth 2.0 ecosystem.

There is also the issue that attackers may have valid credentials anyway. If this attack is valid in the first place, then it is also valid to consider a malicious RS trying to compromise tokens for a different resource server. Unless you have a completely closed environment where all valid parties trust each other, then authentication doesn’t make much difference.

But the token scanning attack is already ruled out by the entropy requirements on access tokens. For example, suppose your application produces access tokens at a rate of 1 million per second, and they each last for 2 years. You will have a maximum of just over 63 trillion access tokens in circulation (~2^46). Assuming an attacker doesn’t care about which access token they compromise, then with the minimum entropy requirements of 128 bits they will require effort of approximately 2^(128-46) = 2^82 to guess any one of those access tokens. That should still be beyond the likely capabilities of anybody to achieve in a 2 year timespan. If you use the recommendation for 160-bit entropy, then they have effort of 2^114, which is comfortably beyond practical for the foreseeable future. (All assuming that you do not leak tokens by other means).

It is not a bad idea to require authentication on the token introspection endpoint, for other reasons mentioned in this thread. So I don’t think the RFC is wrong to recommend it, or even require it. But the stated rationale seems incorrect to me.

Regards,

Neil