Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack)

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 13 November 2016 06:08 UTC

Return-Path: <torsten@lodderstedt.net>
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 74C0D129582 for <oauth@ietfa.amsl.com>; Sat, 12 Nov 2016 22:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4McwT89kyDsd for <oauth@ietfa.amsl.com>; Sat, 12 Nov 2016 22:08:36 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D199128874 for <oauth@ietf.org>; Sat, 12 Nov 2016 22:08:35 -0800 (PST)
Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1c5nxw-0001cF-Al; Sun, 13 Nov 2016 07:08:33 +0100
To: Nat Sakimura <sakimura@gmail.com>, Denis <denis.ietf@free.fr>, oauth@ietf.org
References: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> <CABzCy2BUT_ndUpccH_JB39-rOu1MDt95=3kn0bzZE37f95UKcA@mail.gmail.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-ID: <5828035C.801@lodderstedt.net>
Date: Sun, 13 Nov 2016 15:08:28 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CABzCy2BUT_ndUpccH_JB39-rOu1MDt95=3kn0bzZE37f95UKcA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------050808000303080902090908"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7iriv5M8FX9-TgOKvQruvu63s9Y>
Subject: Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 13 Nov 2016 06:08:39 -0000

I agree, we should analyse the threat. From my first impression it feels 
like injection with some specialties.

@Denis:
So far, I'm struggeling to understand how this attack is performed from 
a practical perspective. Every token/assertion issued to the uncle is 
bound to its identity. So it the niece wants to "upgrade" her age, she 
would need to somehow mix identity data for two identities (her's and 
her uncle's identity) into a single token, which needs to be signed by 
the respective AS. How is this gone work?

kind regards,
Torsten.

Am 11.11.2016 um 16:27 schrieb Nat Sakimura:
> Thanks Denis for pointing it out. It may be desirable to add ABC 
> attack to the list of threats. Torsten et al. are updating Threat 
> Model and Security Considerations so it could potentially be included 
> in there.
>
> Some remarks:
>
>   * I suppose the assumption is that the Bob does not share his
>     credentials with Alice: Otherwise, sharing the credential would
>     achieve something worse.
>   * In addition, it assumes that Bob does not give his device to
>     Alice: Otherwise, something similar to ABC attack can be achieved
>     by Bob giving Alice his Laptop or Phone, and I guess this happens
>     more often than shipping Bob's access token to Alice.
>   * With these assumptions:
>       o It looks like a variation of token injection attack that we
>         have been talking about for many years.
>       o If we token bind the refresh and access tokens, the ABC attack
>         as described does not work.
>       o For something like Age verification, recognizing such attacks,
>         it probably is a bad practice to rely on refresh/access token.
>         The service should do more active check, e.g., through OpenID
>         Connect.
>
> Best,
>
> Nat
>
> On Tue, Nov 8, 2016 at 2:54 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies
>     requirements.
>     One of them (which, BTW, should be moved into Section 4 - Threats)
>     is :
>
>     Collusion:
>
>     Resource servers that collude ...
>
>     This threat addresses the case of "/collusion between servers"/
>     while the case of "/collusion between clients"/
>     has not been considered. When access tokens are being used,
>     /collusion between clients /is of primary importance.
>
>     Let us consider the following "Alice and Bob Collusion attack"
>     (ABC attack).
>
>     An uncle (Bob) is willing to collaborate with his young niece
>     (Alice) who is less than 18 during a short period of time.
>     The niece is opening her own session and creates an account on a
>     server. The uncle does not hand over his own session to her niece
>     at any point of time.
>
>     Let us assume that some crypto expert has written two specific
>     pieces of software. One has been installed on the laptop
>     of the uncle and another one on the laptop of the niece. The two
>     laptops are able to communicate using a network (e.g. a WAN or a LAN).
>
>     The niece creates an account on a resource server. Later on, the
>     resource server asks her (or him ?) to demonstrate that she (or
>     his ?)
>     is more than 18. She forwards the information received from the
>     resource server to her uncle using the network. The uncle receives
>     that information and connects to an Authorization Server. The
>     uncle requests an access token containing information demonstrating
>     that he is older than 18 and passed it back to his niece. The
>     niece then presents it to the resource server. The access token is
>     accepted.
>
>     Since the niece has been able to demonstrate once that she is more
>     than 18, the resource server will remember this attribute
>     and in the future she will not need to demonstrate it again. She
>     will keep the advantages related to this attribute associated
>     with her account on that resource server until she does not need
>     it anymore, i.e. when she will really be over 18.
>
>         Whatever kind of cryptographic is being used, when two users
>         collaborate, a software-only solution will be
>         unable to prevent the transfer of an attribute of a user that
>         possess it to another user that does not possess it .
>
>     The use of a secure element simply protecting the confidentiality
>     and the integrity of some secret key or private key will be
>     ineffective
>     to counter the Alice and Bob collusion attack. Additional
>     properties will be required for the secure element.
>
>     RFC 6819 (OAuth 2.0 Threat Model and Security Considerations)
>     issued in January 2013 has omitted to take into consideration
>     the Alice and Bob Collusion attack.
>
>     Section 2.3 of the ABC4Trust project about key-binding in
>     Deliverable D2.2 available at:
>     https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :
>
>     To prevent “credential pooling”, i.e., multiple Users sharing
>     their credentials, credentials can optionally be bound to a secret
>     key,
>     i.e. a cryptographically strong random value that is assumed to be
>     known only to a particular user. The credential specification
>     specifies whether the credentials issued according to this
>     specification are to employ key binding or not.
>
>     A presentation token derived from such a key-bound credential
>     always contains an implicit proof of knowledge of the underlying
>     secret key,
>     so that the Verifier can be sure that the rightful owner of the
>     credential was involved in the creation of the presentation token.
>     As an extra protection layer, the credentials can also be bound to
>     a trusted physical device, such as a smart card, by keeping
>     the secret key in a protected area of the device. That is, the key
>     cannot be extracted from the device, but the device does participate
>     in the presentation token generation to include an implicit proof
>     of knowledge of this key in the token. Thus, for credentials that
>     are key-bound
>     to a physical device it is impossible to create a presentation
>     token without the device.
>
>     The rightful owner of the credential was indeed involved in
>     real-time in the creation of the presentation token but in the
>     collaboration scenario,
>     the key binding mechanism is not sufficient to counter that
>     specific attack. ABC4Trust, Idemix (IBM) and U-Prove
>     (Microsoft)are currently
>     not resistant to the "ABC attack".
>
>     The IRMA card project (https://www.irmacard.org/) based on the use
>     of a smart card and of the Idemix scheme claims to provide security
>     and privacy simultaneously. However, this project will not be
>     resistant either to the ABC attack.
>
>     *draft-ietf-oauth-pop-architecture-08 should take into
>     consideration the ABC attack.*
>
>     The threat related to the ABC attack should be identified in the
>     security considerations section
>     and the core of the document should attempt to identify one or
>     more ways to counter it.
>
>     The scope of draft-ietf-oauth-token-exchange-06 is limited to the
>     definition of a basic request and response protocol for
>     an STS-style token exchange utilizing OAuth 2.0. Section 6
>     (Security Considerations) has omitted to take into consideration
>     the ABC attack and therefore the currently described "basic
>     request and response protocol" will allow Bob to obtain an access
>     token and to pass it successfully to Alice so that she can use it.
>
>     *draft-ietf-oauth-token-exchange-06 **should take into
>     consideration the ABC attack.*
>
>     The threat related to the ABC attack should be identified in the
>     security considerations section
>     and the core of the document should attempt to identify one or
>     more ways to counter it.
>
>     Denis
>
>     PS. I have recently registered to the OAuth mailing list.
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth