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

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 23 February 2016 09:09 UTC

Return-Path: <vladimir@connect2id.com>
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 9DC0E1B3F5E for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2016 01:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 c_HB_qk6lP9G for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2016 01:09:33 -0800 (PST)
Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8041B3F74 for <oauth@ietf.org>; Tue, 23 Feb 2016 01:09:33 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa07-03.prod.phx3.secureserver.net with id Ml9X1s00415ZTut01l9Yvb; Tue, 23 Feb 2016 02:09:33 -0700
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>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56CC21CB.7070404@connect2id.com>
Date: Tue, 23 Feb 2016 11:09:31 +0200
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: <BY2PR03MB442B1EFAAB9911D5569A833F5A10@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050905080603080308050608"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/EHdC6dLr-ek8FZw_zQCRshkNvM0>
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 09:09:35 -0000

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



On 20/02/16 12:41, Mike Jones wrote:
> Suggesting that they be read is of course, the right long-term approach.  But as someone who spent 20+ years as a researcher before switching to digital identity, I was sensitive to not wanting to upstage their work by copying too much of their material into our draft before their publications were widely known.  I'll of course commit to working the researchers and the working group to create a self-contained concise description of the threats and mitigations in the working group document.
>
> 				Cheers,
> 				-- Mike
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] 
> Sent: Saturday, February 20, 2016 2:25 AM
> To: Mike Jones <Michael.Jones@microsoft.com>om>; William Denniss <wdenniss@google.com>om>; Phil Hunt (IDM) <phil.hunt@oracle.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
>
> Hi Mike,
>
> On 02/20/2016 10:52 AM, Mike Jones wrote:
>> Have you read both of their publications?  If not, do yourself a favor 
>> and do.  They're actually both very readable and quite informative.
> I have read both documents. In context of this discussion the question is whether we
>
> (a) require them to be read (in which case they should be a normative reference), or
> (b) suggest them to be read (since they provide additional background information). In this case they are an informative reference.
>
> I believe believe we want (b) for the OAuth WG document. While I encourage everyone to read the publications I also believe that there is lots of material in there that goes beyond the information our audience typically reads (such as the text about the formal analysis).
>
> There is probably also a middle-ground where we either copy relevant text from the papers into the draft or reference specific sections that are "must-read".
>
> One other issue: I actually thought that the threat that is outlined in the research paper is sufficiently well described but the second threat, which is called 'cut-and-paste attack', requires more work.
> I noted this in my summary mail to the list, see http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com