Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Daniel Fett <fett@uni-trier.de> Tue, 23 February 2016 10:28 UTC

Return-Path: <prvs=85429604b=fett@uni-trier.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9DF1B416E for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2016 02:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.856
X-Spam-Level:
X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham
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 QQn93Wb5dLD1 for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2016 02:28:32 -0800 (PST)
Received: from mx2.uni-trier.de (mx2.uni-trier.de [136.199.224.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EE51B416D for <oauth@ietf.org>; Tue, 23 Feb 2016 02:28:31 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,488,1449529200"; d="scan'208";a="18126674"
Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx2i.uni-trier.de with ESMTP; 23 Feb 2016 11:28:07 +0100
Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id 78A2E459E5 for <oauth@ietf.org>; Tue, 23 Feb 2016 11:28:07 +0100 (CET)
To: oauth@ietf.org
References: <56C7702B.2000401@gmx.net> <BY2PR03MB442E9BF84AFA890378C5116F5A00@BY2PR03MB442.namprd03.prod.outlook.com> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <CAAP42hD96u0Nepdo8YcHeXEo2v1Mo=a_Zo4OcS9ppu7rU-=8Ag@mail.gmail.com> <56C8360C.8010203@gmx.net> <BY2PR03MB44257DFC0BD58DC443A5BB3F5A10@BY2PR03MB442.namprd03.prod.outlook.com> <56C83EEA.8000306@gmx.net> <BY2PR03MB442B1EFAAB9911D5569A833F5A10@BY2PR03MB442.namprd03.prod.outlook.com> <56CC21CB.7070404@connect2id.com>
From: Daniel Fett <fett@uni-trier.de>
Message-ID: <56CC3437.9020908@uni-trier.de>
Date: Tue, 23 Feb 2016 11:28:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CC21CB.7070404@connect2id.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/thenCi5umBewUMP923fLRgU-ko4>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Feb 2016 10:28:34 -0000

Hi Valdimir,

this is exactly what we did in our research paper. We also analyzed and
established a proof of security for one of the proposed mitigations.

Of course, any proof always depends on some assumptions (e.g., no
untrusted third-party code on RP's web site) and aims at specific
security properties.

As you can see from the paper, due to the web itself being complex, the
analysis is also rather lengthy.

In the related work section we also refer to other approaches of
formally analyzing web protocols. We do not think that approaches
"unrelated to web protocols" can produce useful results, because the web
brings many very specific features and constraints.

Cheers,
Daniel

On 23.02.2016 10:09, Vladimir Dzhuvinov wrote:
> Hi Mike,
> 
> You mention that you spent considerable time in research. I wonder if
> there is existing theory, in communications or information theory, that
> can be used to formally establish and prove (or disprove) the security
> of the proposed OAuth measures? Perhaps some work that is totally
> unrelated to identity and the web protocols, but could well apply here?
> 
> My reasoning is that we have a closed system that is fairly simple, so
> formal analysis must be entirely possible.
> 
> 1. We have 5 parties (client, AS, RS, user, user agent).
> 
> 2. The OAuth protocol follows a simple and well-defined pattern of
> messages between the parties.
> 
> 3. The points and the number of ways by which an adversary may break
> into OAuth must therefore be finite.
> 
> 4. The security requirement is essentially to guarantee the precedence
> and authenticity of the messages from discovery endpoint to RS, and the
> preferred way to do that is by establishing a binding between the
> messages, which can be forward or backward binding.
> 
> 
> Right now the WG concern is whether all possible attacks have been
> recognised, and then taken care of. If we can have a formal model that
> can reliably reveal and prove that, this will be a huge breakthrough.
> 
> Cheers,
> 
> Vladimir
> 
> 

-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436