Re: [OAUTH-WG] BCP: Client collaborative attacks

Seán Kelleher <sean@trustap.com> Tue, 27 October 2020 09:00 UTC

Return-Path: <sean@trustap.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 1B11C3A1656 for <oauth@ietfa.amsl.com>; Tue, 27 Oct 2020 02:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=trustap-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 PdAtY6oB9b5z for <oauth@ietfa.amsl.com>; Tue, 27 Oct 2020 02:00:02 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 82B4D3A1655 for <oauth@ietf.org>; Tue, 27 Oct 2020 02:00:02 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id bn26so1091537ejb.6 for <oauth@ietf.org>; Tue, 27 Oct 2020 02:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustap-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/12DVFhAiDj6+W26dEL3MZVFBylD1yQ9VVh734lz0dA=; b=y6gJXHXhfcb5s9E77MIohyurkOkBJuz2VJdxKW0arVTzBKrXR3gLIrcRevqAecU5U+ /7c+FGhD6+7TvkoSV5EIU3vO2sDlmrL3m5Q6fzgtBocPYYQmGJRxwZ3s5D+Quxg1Qh5C 2Znx18meDwKMBkAmCf1l3mOED0pJHo6o9n18mXIqvF0rbK4gP+1PPtHTFTWjsqoNwxsf 6KJ0pGHBhgA5HbN2neVQlfooTqcJ1krbyG5R0bXEACM3SigyOKBQWVKtOlB1J+n5c8U2 6Xa8EWwZYw4/q7t+Liz/NmQhmDp0wXKuVpi/PnmpTQ46nxa9E3zrp1b6GRwxUaikDG5x fxbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/12DVFhAiDj6+W26dEL3MZVFBylD1yQ9VVh734lz0dA=; b=XBSg+U1NEMSit7JmLfsACKF2N4p2MKabqbd6g+zJ9FIe2Ev/cpXDlgz5HpZRCCrwQx 5e4TUKfsTpYNoF6uGMiqMm4RsDgwI2BR1Prg4LtXqQD0jzjFGX7iv2f0+GeZjs9kp4gm q9HtTVOm3XZrL821Gn8piJWOH/5tzYkbFnm9Jc00pKOy5iht+KoMN31ghK1bLIQE3MAM 6Oy28ZUuYa/hFQawN0LZMZAIe4f99YyrVdbs1dkBtAJcDrzauXDGNHCf7DzjTyNzFcvg AsfgJaVCBLHJOmePO8tEEkw3r0relz8OLor1NcoiWPwKnlRczhJ9nLDGxMSycovDgr65 wMDQ==
X-Gm-Message-State: AOAM532yf8kL8rzwQoWboqHl5FrLJkBQBAz7NugAzFeUKB5p4Ph62Mum nJ4Bv7b+crJm4re3VZSM8T2GunbsV9KwwjqZPXk6Kw==
X-Google-Smtp-Source: ABdhPJw6a7vwCq40Sadwbw6Cda+9zTq4gVguaBMADyt5ifapCZzizMwXAZuO/+lIB95gnPUoaL5e2jqYUVnBIoLc+O4=
X-Received: by 2002:a17:906:1e08:: with SMTP id g8mr1363278ejj.358.1603789200879; Tue, 27 Oct 2020 02:00:00 -0700 (PDT)
MIME-Version: 1.0
References: <ME2PR01MB3011145F49559C4996B7E1E0E5160@ME2PR01MB3011.ausprd01.prod.outlook.com> <BD7EE048-1BBC-48D8-831A-6BA02CE01F40@forgerock.com>
In-Reply-To: <BD7EE048-1BBC-48D8-831A-6BA02CE01F40@forgerock.com>
From: =?UTF-8?Q?Se=C3=A1n_Kelleher?= <sean@trustap.com>
Date: Tue, 27 Oct 2020 08:59:49 +0000
Message-ID: <CAPLh0AOaAQx3CGQLigLKFedqumGG_PfWJZKtO4X3C2m5WL=96g@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, Denis <denis.ietf@free.fr>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d1d1705b2a345ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Jv35Yfc8-iIVG4NGPMWg0eUBse8>
Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks
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: Tue, 27 Oct 2020 09:00:05 -0000

@James


> While this text from Seán may be true, it is bad advice. It implies we
> should make access tokens as dangerous as possible (conveying all a
> person’s authority) just to discourage sharing.
>

Is this implied because storing IDs with access logs means that ATs
necessarily carry user ID information (possibly indirectly through an
introspection endpoint)? I would note that the AT doesn't need to carry ID
information itself, just enough information has to be stored with request
logs to be able to later associate user IDs with requests. As a naive
example, ATs could be stored with requests and mappings from user IDs to
issued ATs could be stored on the AS. Ignoring the potential
inefficiency/insecurity of such an approach, it allows user IDs to later be
associated with requests without carrying such information in the AT itself.

Staff accessing a company’s whistle-blower service could be an example:
> need a {staff:true} claim to combat spam/gossip; but definitely don’t want
> to include a staff id.
>

I think this is a good example of a scenario of wanting authZ without
authN, thanks.

What is applicable widely enough to mention in a BCP?


And I would add, specific enough. It seems more like something that should
exist in the "Security Considerations" section of a regular standard.

@Neil

But this can only discourage, not prevent, delegation. OAuth is after all a
> delegation protocol.
>

Following on from your side quote, this is why I would say that it only
reduces authZ sharing to authN sharing, because delegation can still be
done even if it's "discouraged".

If the RS allows anonymous requests then there is obviously no
> accountability. Does that need to be explicitly mentioned?


I think this is the crux of the issue. The "attack" then boils down to "if
you don't have a means of identifying individuals that have made requests,
then different individuals that know this might pretend to be the same
individual". At which point the follow on would seem: if you care about
this then add a "means of identifying individuals that have made requests".

On Tue, 27 Oct 2020 at 06:26, Neil Madden <neil.madden@forgerock.com> wrote:

> It sounds like we’re trying to redefine cooperation/delegation as an
> “attack”. People delegate and you can’t generally prevent it without
> incarceration. Anything Bob could do with Alice’s access token he could
> also do by asking Alice to do it on his behalf. In other words, any
> credential/token sharing can be replaced by proxying: If Alice wants to
> help underage Bob buy liquor she doesn’t have to share her access token,
> she can just buy it herself and give it to him.
>
> If the RS cares about accountability then the token (or some other means)
> should identify the user - perhaps pseudonymously like OIDC pairwise
> identifiers - and this should be logged for audit. But this can only
> discourage, not prevent, delegation. OAuth is after all a delegation
> protocol.
>
> (In the post-shame world we now live in, the idea that you can enforce
> norms through identification seems almost quaint, but I’m not sure I’m
> ready to be that cynical).
>
> If the RS allows anonymous requests then there is obviously no
> accountability. Does that need to be explicitly mentioned?
>
> — Neil
>
> On 27 Oct 2020, at 01:04, Manger, James <James.H.Manger@team.telstra.com>
> wrote:
>
> 
>
> It is worth mentioning “client collaborative attacks” or “authorization
> sharing attacks” because OAuth can make them easier (by packaging authority
> into an access token), compared to the alternative of user’s signing-in to
> an RS directly. But it is tricky to describe; none of the suggestions are
> quite right; and the “right” solution heavily depends on the context.
>
>
>
> >> If access tokens are used to identify individuals, and such
> identifying information (ideally user IDs) is stored with access logs for
> auditing purposes, then this reduces this attack to an authentication
> sharing attack.
>
>
>
> While this text from Seán may be true, it is bad advice. It implies we
> should make access tokens as dangerous as possible (conveying all a
> person’s authority) just to discourage sharing.
>
>
>
> > Since OAuth 2.0 does not mandate the use of cryptographic devices, this
> kind of attack cannot be countered in the general case.
>
>
>
> Even crypto devices aren’t a full solution. Alice can share her
> authorization with Bob & Chris by signing-in with their crypto devices.
>
>
>
> > an access token … only stating that the holder … is over 21 … should
> not be accepted by the RS
>
>
>
> While this may generally be true for an “over 21” claim, it will not
> always be true for other claims. In some situations the privacy risk of
> being personally identified is far more important than any risk of client
> collaboration. Staff accessing a company’s whistle-blower service could be
> an example: need a {staff:true} claim to combat spam/gossip; but definitely
> don’t want to include a staff id.
>
>
>
>
>
> A handful of partial strategies appropriate in various circumstances (but
> all with downsides) could include:
>
> 1. The AS ensures there is only 1 valid access token (or just a few) at
> any point in time for a specific claim of a given user.
>
> 2. Access token bound to a crypto key locked to one device.
>
> 3. Each access token is unique (eg includes a "jti" claim) so an RS can
> notice if the same token is presented in different contexts.
>
> 4. Access token with "sub" (or provides "sub" via token introspection) to
> aid accountability (even if only in a later audit/investigation).
>
> 5. Frequent token replacement.
>
> 6. Nothing (beyond minimal necessary claims) – to maximize privacy.
>
>
>
> What is applicable widely enough to mention in a BCP?
>
>
>
> --
>
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>