Re: [OAUTH-WG] OAuth Security -- Next Steps

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 28 July 2016 07:56 UTC

Return-Path: <vladimir@connect2id.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 9702D12D60D for <oauth@ietfa.amsl.com>; Thu, 28 Jul 2016 00:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 1qUht6iI3UTP for <oauth@ietfa.amsl.com>; Thu, 28 Jul 2016 00:56:07 -0700 (PDT)
Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9A6128E18 for <oauth@ietf.org>; Thu, 28 Jul 2016 00:56:06 -0700 (PDT)
Received: from [192.168.1.9] ([46.10.70.150]) by p3plsmtpa08-01.prod.phx3.secureserver.net with id Q7w41t0033EY5i6017w5pv; Thu, 28 Jul 2016 00:56:06 -0700
To: oauth@ietf.org
References: <5795F109.9040403@gmx.net> <DM5PR03MB2441ACA5B240108C320DFABAA60D0@DM5PR03MB2441.namprd03.prod.outlook.com> <CA+k3eCR_EFdA4Zdiwfm65nq99gVYg8eKrC6x7EB_OG=20y4=WA@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <beaaa4f8-7f5e-8f1d-d0bd-6aa5b418ccdc@connect2id.com>
Date: Thu, 28 Jul 2016 10:56:03 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCR_EFdA4Zdiwfm65nq99gVYg8eKrC6x7EB_OG=20y4=WA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050102080502090902060205"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IiO_n1AwLFGAPrOg2siE4gqQI4E>
Subject: Re: [OAUTH-WG] OAuth Security -- Next Steps
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: Thu, 28 Jul 2016 07:56:08 -0000

I congratulate the idea for a BCP.

Ideally that would be a document written with the developer in mind,
easy to consume, and outlining all necessary steps to take in order to
harden / patch up an OAuth 2.0 implementation / app. The individual
attacks could be referenced or described in an appendix.

Working from documents that describe an individual attack, or a class of
attacks, where a matching countermeasure is suggested, is harder for
developers (the typical format of security research papers). In
conversations with developers I found out that many of them have indeed
read about the recently discovered problems, but don't have a good
picture of the overall situation, and how to react. Therefore, putting
together a clear course for action, sanctioned by the OAuth WG, would be
really useful.

I also imagine the BCP could suggest two variants for action:


1. For those people who have existing apps in the field, and mostly 3rd
party client developers. They will probably be looking for the minimum
amount of measures to secure their OAuth 2.0 stuff, to minimise
disruption and all sorts of hassle related to updating APIs, clients,
libraries, etc.


2. For people who want to have additional protections to OAuth 2.0 in
place, e.g. JWT assertions for client auth, bound tokens, etc. Typically
companies that are in control of their clients and apps, or those that
consider introducing OAuth 2.0 for the first time.


Thanks,

Vladimir



On 28/07/16 00:53, Brian Campbell wrote:
> Agree. The BCP would be larger in scope than just mix-up. And given that
> approach, I don't know if it makes sense to have a document specific to
> mix-up.
>
> On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadalin <tonynad@microsoft.com>
> wrote:
>
>> Sounds about right, but I would imagine that the BCP would cover any issue
>> that arises not just mix-up
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Monday, July 25, 2016 3:59 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] OAuth Security -- Next Steps
>>
>> Hi all,
>>
>> We had two working group sessions at the Berlin IETF meeting and I am
>> happy about the progress on many of the subjects. We managed to progress
>> token exchange, native apps, AMR, and authorization server meta-data. We
>> also identified new use cases to explore with the device flow document.
>>
>> We also did a call for adoption of the OAuth token binding functionality,
>> which still needs to be confirmed on the mailing list.
>> (Further emails will follow.)
>>
>> There are, however, aspects I am not happy with. I was hoping to make some
>> progress on the mix-up mitigation and on the wider range of security
>> documents.
>>
>> Here is how I see the story after talking to some meeting participants.
>>
>> 1) It seems that the solution approach to deal with the mix-up attack
>> (only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to
>> be modified to reflect the preference of the working group. My impression
>> (from speaking with participants at the meeting last week
>> privately) is that there is interest in a solution that does not require
>> protocol changes but rather relies on configuration. This may include a
>> combination of exact redirect_URI matching + per-AS redirect_URI + session
>> state checking. There are also other attacks described in
>> draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to
>> avoid confusion.
>>
>> 2) We need a new document, ideally a BCP, that serves as a high-level
>> write-up describing various security issues with OAuth that points to the
>> mostly existing documents for those who want to read the background
>> information. Torsten has posted a mail to the list providing one possible
>> outline of such a document.
>>
>> How does this sound?
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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

--