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

Aaron Parecki <aaron@parecki.com> Mon, 26 October 2020 21:25 UTC

Return-Path: <aaron@parecki.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 792D93A0656 for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 14:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=parecki.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 ZNNDFsKD9l2b for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 14:25:31 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 3C7923A0489 for <oauth@ietf.org>; Mon, 26 Oct 2020 14:25:30 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id x20so4939441ilj.8 for <oauth@ietf.org>; Mon, 26 Oct 2020 14:25:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ETHBXM+89lXPfM96JXJKJeGFjtl5dcjCi8Ej8rvM72c=; b=oU3L16F4CCMjYuwOokNQW4EhaccxARWWV1H8Ny8/aCLfnG1RVbURdrcSdIrD7o6T6b n7wWg3UPQiuUrL4NTGXelID9NMIJyvoIatv69/Ip2nT78VIZxQQ8re86iAQwXypIsIQE SHusjGnQbMHC6xNmuQgGl2jwfj+tvR8E2T1ld6ddbJN3vbNEXFiKerRttmFQnzWsdYMS AIk4MUg8XgS7nD5zQnlQi47fDjA7tGU+pgbaxaJqTW8iygB9ePNsq2COVAuviZLoIcsr b2aU8XRq/wX38EIocQ2geermqX79dl4n34nQ9MFn0ph52QDgAYTngQheviuYcOfN5FHg HbrQ==
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=ETHBXM+89lXPfM96JXJKJeGFjtl5dcjCi8Ej8rvM72c=; b=mE7SUAt2G8Oghk584azO3xyD4VKPdJ+zjAgpbRdX+PKuicE72daNFoI8+DBtNQ0Ml6 oDtf0bC9OPgvdu5mzXigHsXSkWdWv8GPvWyxnaxVU1Bg6b3UOLmpulMYNsPhP2PHGJU1 If7UGDA0C5IfHCDkd0AwQUD/4IJxUqB+lNnmXw96PgDic1ocwEhU/u6/KDRcpTro3NN5 sck9PYWF3Qm6F7X+GAL/Q4nvuOShL363ZpyjbSIc8pA7HG5lwzDGUY/OE38iHzIjU5Sv RGqqpIJ4g34zCcRzdJIuGTpLtEt06GWQyy6ygHfmo/dkF7McUwIoXdWdrwjFlpf4WMSD o6vg==
X-Gm-Message-State: AOAM531lv2iSbTYqqJnV/wK6K2R0ue0Pmue/xCS+agCWPhCa2dX5GtMb iHe5PAPqQ8oFDyUjPfCHNx8DaRBMY9CDnQ==
X-Google-Smtp-Source: ABdhPJzCcX7wzYzaXCZ0oyh5xPbJ9+CB06/cFwPSasIYWTOQ9FEXAv3DwYq8CzliG7fVK0MvCdMu6w==
X-Received: by 2002:a92:670e:: with SMTP id b14mr12443897ilc.36.1603747529874; Mon, 26 Oct 2020 14:25:29 -0700 (PDT)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id w22sm5886140iob.32.2020.10.26.14.25.28 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 14:25:29 -0700 (PDT)
Received: by mail-io1-f47.google.com with SMTP id u19so12309799ion.3 for <oauth@ietf.org>; Mon, 26 Oct 2020 14:25:28 -0700 (PDT)
X-Received: by 2002:a6b:fa0e:: with SMTP id p14mr11873800ioh.208.1603747528397; Mon, 26 Oct 2020 14:25:28 -0700 (PDT)
MIME-Version: 1.0
References: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> <CAPLh0AOqegW07_6vSPsmmp9YtPTh6G71=v_tUqA2GjhwZ6iKSw@mail.gmail.com>
In-Reply-To: <CAPLh0AOqegW07_6vSPsmmp9YtPTh6G71=v_tUqA2GjhwZ6iKSw@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Mon, 26 Oct 2020 14:25:17 -0700
X-Gmail-Original-Message-ID: <CAGBSGjqqk+AxR1u6wn=BPr1dqaVJQ+wpSCRB022oNNVx4XG7Cw@mail.gmail.com>
Message-ID: <CAGBSGjqqk+AxR1u6wn=BPr1dqaVJQ+wpSCRB022oNNVx4XG7Cw@mail.gmail.com>
To: =?UTF-8?Q?Se=C3=A1n_Kelleher?= <sean@trustap.com>
Cc: Denis <denis.ietf@free.fr>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd5ada05b29991f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uVJwyNNFKl8q1scNZ8PKm2FNTIw>
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: Mon, 26 Oct 2020 21:25:34 -0000

Thank you Seán, this is an excellent analysis and makes this attack much
easier to understand. I completely agree with your rewritten text, both
that it better describes the situation as well as the conclusion that it
ends up being a bit too general for the BCP.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Mon, Oct 26, 2020 at 2:19 PM Seán Kelleher <sean@trustap.com> wrote:

> I hadn't come across this idea before, it's an interesting angle and for
> me it's a nice new example to help highlight the difference between authZ
> and authN. It reminds me of sharing access cards to get into computer labs
> in college. Some thoughts:
>
>    - It took me a while to figure out the agent, victim, intent and
>    impact for the attack based on its name and description. The presented term
>    may already be accepted, but if not, would you consider the term
>    "authorization sharing attack"? I feel that this conveys the intent and
>    impact of the attack a bit more clearly.
>
> However, if the access token contains claims that allow the RS to uniquely
>> identify the legitimate holder of the access token
>> and if the RS only accepts access tokens that are able to uniquely
>> identify the legitimate holder of the access token, then
>> this attack can be mitigated since the client collaborative attack
>> becomes an impersonation attack.
>
>
>    - Being pedantic, I don't think this mitigates the attack so much as
>    it reduces it to the mentioned impersonation attack. However, I'm not sure
>    that "impersonation attack" is the right term to use here, as this scenario
>    seems to imply that the subject consents to the impersonation, which is in
>    contrast to the standard impersonation attack where the subject is the
>    victim.
>
> For mitigating the collaborative attack, either a "sub" claim must be
>> present or any combination of other claims allowing for the RS
>> to uniquely identify the holder of the access token must be present
>> inside an access token
>>
>
>    - A more general phrasing of this could be that "it should be possible
>    to use an access token to uniquely identify an individual". I say this
>    because this kind of identification can also be done using opaque tokens,
>    in which case the claims are not necessarily "inside" the access token.
>
> Under these conditions, it should be observed that the first user might be
>> unlikely to be willing to collaborate since the other user would be able
>> to perform actions on behalf of the first user and the first user would
>> be held responsible of the actions of the second user.
>
>
>    - This seems to be the main justification as to why the above
>    mitigations are considered as such. I don't agree with the conclusion
>    because I feel it's based on debateable assumptions, the main one being
>    that the "first user might be unlikely to be willing to collaborate" if
>    they know that their access token identifies them, which tries to predict
>    human behaviour. It also depends on the user knowing whether access tokens
>    can be used to identify them.
>    - I'm again being pedantic, but I would also note that just being able
>    to identify a user from an access token is unlikely to be a sufficient
>    deterrent, it would need to be coupled with logging of all access token
>    usages for auditing purposes. Again though, this assumes that we can
>    predict human behaviour.
>    - Following on from one of my above points, I would remove the user
>    element from this section, and avoid calling it a mitigation. I'd instead
>    outline that if access tokens can be used to identify individuals then it
>    reduces possible authZ sharing attacks to authN sharing attacks.
>
> I think this is an interesting attack vector, particularly because it
> requires the authZ sharer to have internal knowledge of how the RS
> operates, and so has relatively niche applications. It also seems to assume
> that the RS in question doesn't store user IDs with access logs, at which
> point, is it simpler to just recommend that authN'd requests to an RS
> should be logged with user IDs?
>
> I've written up an alternative for consideration:
>
> Authorization sharing attack
>>
>> If access tokens are not used to identify individuals, and if this
>> information is known to an individual, then such an individual may use
>> knowledge of this to share the authorization granted to them by access
>> tokens. This may be done by sharing access tokens across clients and
>> individuals, at which point the RS will not be able to distinguish between
>> different subjects and clients using the same access token.
>>
>> 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.
>>
>
> I think it's a bit too general for a BCP, and too vague around the notion
> of an "individual", but it might give some food for further thought.
>
> Kind regards,
>
> Seán.
>
>>
> On Mon, 26 Oct 2020 at 18:19, Denis <denis.ietf@free.fr> wrote:
>
>> Hi Daniel,
>>
>> Following the conversation we had today, hereafter is a proposal for
>> addressing client collaborative attacks.
>> I propose to add a new section 4.16.
>>
>>
>> 4.16 Client collaborative attacks
>>
>> Two clients may agree to collaborate. In such a situation, one client
>> transmits to another client an access token
>> that it legitimately got and also accepts to perform all the
>> cryptographic computations that the other client needs
>> to use the access token, including when the access token is
>> cryptographically bound to a key.
>>
>> Since OAuth 2.0 does not mandate the use of cryptographic devices, this
>> kind of attack cannot be countered in the general case.
>>
>> However, if the access token contains claims that allow the RS to
>> uniquely identify the legitimate holder of the access token
>> and if the RS only accepts access tokens that are able to uniquely
>> identify the legitimate holder of the access token, then
>> this attack can be mitigated since the client collaborative attack
>> becomes an impersonation attack.
>>
>> For mitigating the collaborative attack, either a "sub" claim must be
>> present or any combination of other claims allowing for the RS
>> to uniquely identify the holder of the access token must be present
>> inside an access token, for example OpenID claims like: name,
>> family_name, given_name, middle_name, nickname, preferred_username,
>> gender, birthdate, email, email_verified, phone_number,
>> phone_number_verified or address.
>>
>> On the contrary, for example, an access token that would only contain a
>> claim stating that the holder of the access token is over 21
>> or a birthdate without any claim allowing the RS to uniquely identify
>> the legitimate holder of the access token, should not be accepted by the RS.
>>
>> Under these conditions, it should be observed that the first user might
>> be unlikely to be willing to collaborate since the other user would be able
>> to perform actions on behalf of the first user and the first user would
>> be held responsible of the actions of the second user.
>>
>>
>>
>> *Comment on section 4: "Validating JWT Access Tokens" *
>> The JWT profile for OAuth 2.0 access tokens
>> [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into
>> an access token.
>> However, this section does not mandate the RS to verify that claims
>> allowing for the RS to uniquely identify the holder of the access token
>> are indeed be present inside an access token.
>>
>> It might be useful to add it, so that the above text can refer to it.
>>
>> Denis
>>
>> _______________________________________________
>> 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
>