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

John Bradley <ve7jtb@ve7jtb.com> Tue, 02 January 2018 15:06 UTC

Return-Path: <ve7jtb@ve7jtb.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 F3030126CD8 for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 07:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 HtXZujFavgVg for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 07:06:31 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 B7377124BAC for <oauth@ietf.org>; Tue, 2 Jan 2018 07:06:31 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id l19so27494356qke.5 for <oauth@ietf.org>; Tue, 02 Jan 2018 07:06:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=bOhdZRCLaiST7tevfsQyl20394St3Vj8MAPeOIU/p+E=; b=LOXTwiQHuCwkSkl1Y7SH3IpVPLMCZHlh+3AWSWpN/0c2tjzQurFu3YlhtfQxGWldjH x3unTpm+xSHq3/3ZaP5iuV7KSkTcmy7stxs7m1ysrsapgHaR1peHzUIFj9uFls50fzZe Eq2mCpiis75lEBGbst2GRtUI4eh6pmRQFtTGPvcyJC+xRQmOVcSWlI2VE3OfWjs6I0eq NVKv/QEHsK9ynS6QAQ0j/j/R98yScz4kmWZFzU7HrtaTNxJfhssrZ2XdIkZeabchDwbs yL7w+ld22/U1ILLLiWJXNoMEdn3l+r4rnoLZJ1kodLYdRZjvTCJHiCSkjFmt+Koy21ye OiKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=bOhdZRCLaiST7tevfsQyl20394St3Vj8MAPeOIU/p+E=; b=Q28aDdxIrcF6MiArtyPz2Vjk9+NQhp8zQJZGwnK8uRrKLZg6KDJGI5Z+6pXUSQBmzX ROzaodww3oUjOFqGKHQkxZuA+lo01ZMRLYkbEmSioPyi1MvOhSng0lRE/XcVLMslPVb8 +x5TrJ/GuAQNFL7hB1hyy/KyN6SlSXIrD8Qs9pBHQiTDWyl20oMCTUHluW/RSeOu5e1d BaIkI7qCaHZtfPEKK6PZcoMl/qHP2IJTO++fGfG99DuIBi5JJ63aVlrkPv3Ycnnt0E92 JGUeJgZorXzMtMrLGAzZs0uvm9Ymtna9aaM65Kz9c2BqnSUtCvfE71FoeDLWyNzN2aWY n2eA==
X-Gm-Message-State: AKGB3mLY4iMPBGa6Qwnls/kgcVTFDqtwb3zBCn7s6sjS1mY62qgkC1Ex u5FsNWUTT2wsPNgdHwG+P7bqh6HRDYw=
X-Google-Smtp-Source: ACJfBov+P33mRTxnoD4dX1caSAN/2DPx05i8O4N+g9dKaLsNh7NUc+IkwyNbztpz13x411yeToT4iA==
X-Received: by 10.55.101.198 with SMTP id z189mr58885211qkb.46.1514905590164; Tue, 02 Jan 2018 07:06:30 -0800 (PST)
Received: from [192.168.8.100] ([181.201.182.19]) by smtp.gmail.com with ESMTPSA id o36sm26753318qko.80.2018.01.02.07.06.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 07:06:28 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <AF1C81BC-485C-4BAB-9415-D85FAF50977D@forgerock.com>
Date: Tue, 2 Jan 2018 12:06:25 -0300
Cc: OAuth WG <oauth@ietf.org>
Message-Id: <665AE14D-F8A4-444E-88BF-B596937FF855@ve7jtb.com>
References: <AF1C81BC-485C-4BAB-9415-D85FAF50977D@forgerock.com>
To: Neil Madden <neil.madden@forgerock.com>
X-Mailer: Apple Mail (2.3445.5.20)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11482ffa9ec7e30561cc71a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3TVnHF70DAEcr0oo02KPnaoJqNM>
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: Tue, 02 Jan 2018 15:06:35 -0000

In reality people developers may not always be putting that much entropy into a token.   It is only a SHOULD and hard to enforce.  I may have come up with the min entropy number.

There may also be side channel attacks if you allow introspection of encrypted or signed tokens. 

There is also a potential privacy issue if you return a bunch of PII in the token response.  If the token leaked it perhaps can’t be used if it isa POP token but you may still leak PII via introspection.

In general I am not a big fan of introspection.  We didn’t include it in Connect.  However the pattern is used in a number of commercial products to have the RS introspect tokens at the AS. 
It was decided by the WG that having a standard would reduce the number of things people need to support when you have things like a DataPower talking to Ping Fed or something like that.

Given that this is mostly used by RS I think the decision was made to err on the side of caution, as authentication is not a huge burden. 
I recall it being discussed and some people didn’t want to do authentication.

It is not cut and perhaps in some cases it might not be required, however that would introduce a option that people may get wrong in implementations.

Happy New Year 
John B.

> On Jan 2, 2018, at 9:42 AM, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> 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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth