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: Seán 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 >
- [OAUTH-WG] BCP: Client collaborative attacks Denis
- Re: [OAUTH-WG] BCP: Client collaborative attacks Seán Kelleher
- Re: [OAUTH-WG] BCP: Client collaborative attacks Aaron Parecki
- Re: [OAUTH-WG] BCP: Client collaborative attacks Manger, James
- Re: [OAUTH-WG] BCP: Client collaborative attacks Neil Madden
- Re: [OAUTH-WG] BCP: Client collaborative attacks Seán Kelleher
- Re: [OAUTH-WG] BCP: Client collaborative attacks Daniel Fett
- Re: [OAUTH-WG] BCP: Client collaborative attacks Denis
- Re: [OAUTH-WG] BCP: Client collaborative attacks Manger, James