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

William Denniss <wdenniss@google.com> Tue, 02 January 2018 20:54 UTC

Return-Path: <wdenniss@google.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 25C2D1276AF for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 12:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OIksxuYFGLjx for <oauth@ietfa.amsl.com>; Tue, 2 Jan 2018 12:54:51 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 1F51D127076 for <oauth@ietf.org>; Tue, 2 Jan 2018 12:54:51 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id a82so6651557ybg.1 for <oauth@ietf.org>; Tue, 02 Jan 2018 12:54:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F8W90/dPklLAyMe8vUppwIZvq8tQGUWPcI6Qa10C39Q=; b=tpdxWB8K6Zfsv25MBp+n+I5rxpQn5H+LdiiCS5uVVqGGhV0q0dYQhXVhCDjBJ3n8ah DzlwyGFs0m/zjqahe5FXfcj7lnvCXd6CPPYj/Wwec9k75o4PXh0HXdM4+9/ScnqHYyoI r6VOYo95ctk6l4/N7v2gw+Ruw67Y/Lxq9YSCPjWzvs5k7XuHk/ej7H+kBAG6xGP7yhvv 6ZEbFAROcUf1sSxcgwyfe3caTWjU2nG8q+IXZTf/JuiiJwwloRa6f7qmjGN2unx8+EzU XCobV1+HJgbF/ORubEAghbciOk4MTIh2bOdI7b713bwLVFXJpuyf5d+2T6L8pyX7C8HG /b9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F8W90/dPklLAyMe8vUppwIZvq8tQGUWPcI6Qa10C39Q=; b=sw4+2rGvEfwl1d5yNaFaSO61ovzJP1aYiBKFayghdCwgJ1V1oYM05x/B75AMJc1Ad4 AvlRJIc/nH+sMk85qxRoCtWke07wNJiKWzkhP9VuzbCib6T1wn1jieF7oRYY7wutGuCV PnZ9nE1IIWb83uL5KNWhxpE18+R/tBOqSUyz/jt3GEGHiBDbnAGDmvw8D0nsIPOL8Q6B r1Fg7LBxmCGXjJPwXOc5phTJFjrP7ZhfaHJekl3zxIzKl0Xzwh9tbOIt41VENLb+0rr6 yk44Rq/EmlRZzouxtc5kXEgi7lmjfeNNwhhRy2PU3C5YbHIwucBbRru8hFQQBxTRX5kO W/rg==
X-Gm-Message-State: AKGB3mJO0ouJhdb5e+JUxENQKXyrWZ3M8iNUEcaW9cX72XJtYQ03YvLr AnUv/2cwrur/sHqaXTrT9DaT03jiNm0dQRwduRJzCQ==
X-Google-Smtp-Source: ACJfBosnutODk53LJwmhXV1dITtW14Eo3uZkp4RGFOhG+pTssQ6UJNUMRz8j+aU/6DoJ7SgA8TlN27Q1Gs30x6/DOAI=
X-Received: by 10.37.132.132 with SMTP id v4mr27985333ybk.512.1514926489720; Tue, 02 Jan 2018 12:54:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.146 with HTTP; Tue, 2 Jan 2018 12:54:29 -0800 (PST)
In-Reply-To: <15B4232D-F137-426D-B9B3-D33DF9B5B7A2@forgerock.com>
References: <AF1C81BC-485C-4BAB-9415-D85FAF50977D@forgerock.com> <665AE14D-F8A4-444E-88BF-B596937FF855@ve7jtb.com> <15B4232D-F137-426D-B9B3-D33DF9B5B7A2@forgerock.com>
From: William Denniss <wdenniss@google.com>
Date: Tue, 2 Jan 2018 12:54:29 -0800
Message-ID: <CAAP42hA1+XVaZ70y3COoPXS3hq5YJpB=soKMviXLGjn=odS1Jg@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="089e082c268848b0500561d14f67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IwliA-WuPFG4ivYe7IF97lAUSV4>
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 20:54:54 -0000

If you're interested in examples in the wild of token introspection without
client authentication, Google offers one and specifically recommends that
JS clients (which are public clients and thus can't use client
authentication) use it to mitigate confused deputy attacks on access
tokens. Documented here:
https://developers.google.com/identity/protocols/OAuth2UserAgent#validate-access-token
(section 5, select the "OAuth 2.0 Endpoints" tab). The endpoint doesn't
follow the spec precisely, as it pre-dated it, but it's pretty close.

Regarding that "MUST require authentication", it does seem like there are
other mitigations, including ones that the text eludes to (e.g. throttling,
high entropy, etc). I actually advocated for a watering down of the MUST at
IETF 93, but by then the document was too advanced along the publishing
process for chances to be considered. I gathered the intended use-case of
the spec was more for resource server rather than client introspection
(though I expressed a view that it could be expanded to cover both since it
was so close).

On Tue, Jan 2, 2018 at 9:01 AM, Neil Madden <neil.madden@forgerock.com>
wrote:

> The requirement on 128-bit entropy is a MUST in RFC 6749. There is a
> SHOULD for the stronger 160-bit level. How does authentication address the
> problem?
>
> Neil
>
> > On 2 Jan 2018, at 15:06, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >
> > 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
> >
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>