Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

Michael Thomas <mike@mtcc.com> Mon, 23 April 2012 16:09 UTC

Return-Path: <mike@mtcc.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 117B421F864A for <oauth@ietfa.amsl.com>; Mon, 23 Apr 2012 09:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWwafvVWNi9f for <oauth@ietfa.amsl.com>; Mon, 23 Apr 2012 09:09:20 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id E775121F858B for <oauth@ietf.org>; Mon, 23 Apr 2012 09:09:19 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3NG9FQn030053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 09:09:16 -0700
Message-ID: <4F957EA7.3060004@mtcc.com>
Date: Mon, 23 Apr 2012 09:09:11 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>, "oauth@ietf.org" <oauth@ietf.org>
References: <CALaySJLy6jpuPqxQXfKfpx0TpcK1gav1NtcTOoh+NOr11JSCbw@mail.gmail.com> <4F8DE789.4030704@mtcc.com> <CALaySJK1ej_HkP5Jz26XT-KjULirD2iFfVOpRkHgPZp-CbJCrg@mail.gmail.com>
In-Reply-To: <CALaySJK1ej_HkP5Jz26XT-KjULirD2iFfVOpRkHgPZp-CbJCrg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1181; t=1335197357; x=1336061357; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20Shepherd=20review=20of=20draft-ietf-oau th-v2-threatmodel |Sender:=20 |To:=20Barry=20Leiba=20<barryleiba@computer.org>,=20=0A=20= 22oauth@ietf.org=22=20<oauth@ietf.org> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=fy930Q+o/eN1HuLqTe+RCddhD240XjHzAjwWuT4CwrI=; b=BMXZKV9RC1KR9/pIKuhqT5RNgDh1akOncFmj2F7TgVQ1DYVPzNN9Oe/PPa +wrfQbBXLSJ459MOpREgmkJhoTBei3ya4aRpTElzmDBbugl74c2ZozOn6Ep3 LXqzsiia2GCEB94UurZkqOJA4GOXZZNeDK1lL4hFhQYlsdrB3OVhE=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 23 Apr 2012 16:09:21 -0000

[I accidentally sent just to Barry my take on his addition which I think is fine
except for one thing addition...]

Barry Leiba wrote:
> You sent it just to me.  I think it's a reasonable addition, so please
> send it to the distribution (which at the moment does not include the
> OAuth list, just the
> <draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org> alias), and
> suggest specific text to add.  I presume it would go in an new bullet
> just before the last.

The thing I think is missing here is that the Authorization Server has a
stake in mitigating threats, and actually has a quite potent one: it can
be selective with whom it enrolls, and can revoke bad actors.

So let me try a bullet:

o While end users are mostly incapable of properly vetting applications they
   load onto their devices, those who deploy Authorization Servers have tools at
   their disposal to mitigate malicious Clients. Namely, in order to become a threat
   at all, a Client must first become a Client. A well run Authorization Server MAY
   require a curation process when enrolling Clients, and SHOULD have processes to
   revoke bad actors after enrollment.

Mike