[OAUTH-WG] Token scanning attacks in RFC 7662

Neil Madden <neil.madden@forgerock.com> Tue, 02 January 2018 12:42 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 8BBC5126D05 for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 04:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 1wIJeMGfA_HK for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 04:42:50 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 E0D1F120725 for <oauth@ietf.org>; Tue, 2 Jan 2018 04:42:49 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id f206so60590761wmf.5 for <oauth@ietf.org>; Tue, 02 Jan 2018 04:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=vc2ps+AhPrmXF+8sk80y+JcdsbPLnIE1ocRv/FmC6Ag=; b=HE0PS6uYWBx4awqm3HbHfEzZ9sZ5l5/hAdeCMVNQYoGV1jPVz4R8LzHzGk/fleDt+Y 7pLqHQRxyUalyieVfBxMwySqryAXuVx/YZh9MMsL7NBK026gguczyLkAg7McV2+jGqRN e/zlcz7YGZU2mAAbFP5u8+fzXdXK1XZakQ87I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=vc2ps+AhPrmXF+8sk80y+JcdsbPLnIE1ocRv/FmC6Ag=; b=Jf8fdfFJUyheeZav+WJlpgFKngQxmfXV08BxKM4W/nchonopU3Tyc8zSq8Hsrj0iGt P6FxoiRcSKZYytC910oq0tsoy0QRgbE2ysCe0a/0mQgs2Zh2gDh8ZvkzhZgFZHQy3Pj+ 0mfhzBUMWLY7+ZxHtYStbl8UBxM6xBtFa80Cb8B7uMb1SCBSTACl5QlvqNbWHfKFdqGJ F4mS8/H4tKHFP/5Ae2eWnLHgXFB7KzYkR9pTvY88KJxmYTV9IWnj0fIp7BEvrn7fYhxA yiHjzh6DZP8axemW3+o26X4sbyKG6FQ6RJ4ace8i25Fqe7cfMd9Gy/1Fu0CBSsWoLx/Y j8NQ==
X-Gm-Message-State: AKGB3mKoupU4JR/eWrjO0UWAPrjKfxn9fJC8j1vlyFFQ0ZEyIFj9uAV7 fwK1ZbeYW7htSCHuP3vitwDlyzAGqnMsU/iBiP4eijBvQ9zVChV1KWxWntPYtTtZkNsw0jKBfUT JIAwlcWv/C2hbtyt6jSuw44mrYDs2F0QKFHBdFjEy8gm5Cvcsnl2QmtRtqjmtFcA=
X-Google-Smtp-Source: ACJfBot9AopVnaz/E5eFCN6yrJBwGlLbos7xm+bRq6IVkwqX1ZkqRBhP5solNLKytzFgZQE/3phDuQ==
X-Received: by 10.28.30.213 with SMTP id e204mr34190064wme.40.1514896967958; Tue, 02 Jan 2018 04:42:47 -0800 (PST)
Received: from guest2s-mbp.home (53.150.32.217.dyn.plus.net. [217.32.150.53]) by smtp.gmail.com with ESMTPSA id y72sm53513898wrb.85.2018.01.02.04.42.47 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 04:42:47 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <AF1C81BC-485C-4BAB-9415-D85FAF50977D@forgerock.com>
Date: Tue, 2 Jan 2018 12:42:46 +0000
To: OAuth WG <oauth@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pMziyBFG2NMnm_z5u9ubnEme0Q8>
Subject: [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: Tue, 02 Jan 2018 12:42:52 -0000

Greetings, and Happy New Year!

I was just re-reading the OAuth 2.0 token introspection RFC 7662, and I am a bit confused by the rationale for requiring client (RS) authentication when making calls to this endpoint. The stated rationale in Section 2.1 (https://tools.ietf.org/html/rfc7662#page-5) is:

  “To prevent token scanning attacks, the endpoint MUST also require
   some form of authorization to access this endpoint, such as client
   authentication as described in OAuth 2.0 [RFC6749] or a separate
   OAuth 2.0 access token such as the bearer token described in OAuth
   2.0 Bearer Token Usage [RFC6750].”

This rationale is elaborated in the Security Considerations:

  "If left unprotected and un-throttled, the introspection endpoint
   could present a means for an attacker to poll a series of possible
   token values, fishing for a valid token.  To prevent this, the
   authorization server MUST require authentication of protected
   resources that need to access the introspection endpoint and SHOULD
   require protected resources to be specifically authorized to call the
   introspection endpoint.”

However, RFC 6749 already requires that access tokens be unguessable with a probability of successful guesses being at most 2^(-128) [https://tools.ietf.org/html/rfc6749#section-10.10]. Assuming that this means something like: if an attacker makes 2^n guesses then they have a maximum chance of guessing a particular access token of at most 2^(n-128), then I think the token scanning attacks are already taken care of aren’t they? It is not feasible for an attacker to make that many queries. Even if you consider that the attacker only needs to guess one out of the set of all valid access tokens, then I still don’t think this attack is feasible in any realistic time-frame, especially if you follow the “SHOULD" recommendation to require at most 2^(-160) probability.

Is there some other threat model being considered here? Timing side-channels maybe?

Also, I cannot find a justification in the RFC for how this threat is mitigated by requiring authentication. Is the assumption that this is a closed ecosystem where malicious parties cannot get valid credentials?

Kind regards,

Neil

--
Neil Madden
Security Director, ForgeRock Engineering.
Email: neil.madden@forgerock.com     PGP: 90F8 43DF 4EDD AC5D
Bugs/Reports: security@forgerock.com PGP: 6D19 AD77 1F43 ADAD