Re: [secdir] [kitten] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

Nicolas Williams <Nicolas.Williams@oracle.com> Wed, 10 November 2010 07:02 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF19B3A6A17; Tue, 9 Nov 2010 23:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.476
X-Spam-Level:
X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQmB7Qzdzfxn; Tue, 9 Nov 2010 23:02:25 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 116863A68B5; Tue, 9 Nov 2010 23:02:00 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oAA72ATX008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 07:02:11 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA9HhiJO024108; Wed, 10 Nov 2010 07:02:09 GMT
Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 765322921289372442; Tue, 09 Nov 2010 23:00:42 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Nov 2010 23:00:42 -0800
Date: Wed, 10 Nov 2010 01:00:37 -0600
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: torsten@lodderstedt.net
Message-ID: <20101110070037.GT6536@oracle.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> <4CD73075.8050408@lodderstedt.net> <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
User-Agent: Mutt/1.5.20 (2010-03-02)
Cc: Anthony Nadalin <tonynad@microsoft.com>, "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [kitten] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: oauth@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 07:02:37 -0000

[That is some cc list!  Do you really need a cc list that large for this
thread?  I've set the reply-to to just oauth@ietf.org (note: I'm NOT
subscribed to that list).  Please honor the reply-to header.  It's a
good idea to set reply-to when making announcements, so that replies
don't flood people who are almost certainly not interested.]

On Tue, Nov 09, 2010 at 08:07:56AM +0000, torsten@lodderstedt.net wrote:
> We think the security considerations should be based on a threat model
> of OAuth. But a complete threat model would blow up the spec.

Really?  I would think that a threat model for OAuth could be described
fairly briefly.  What is the typical value of resources protected by
OAuth?  What kinds of attackers (active, passive, ...) does OAuth aim to
defeat, and under what assumptions (end-points are secure, trusted third
parties are trustworthy, certain cryptographic algorithms are not broken
with parameters in certain ranges, smartcards are secure, ...)?  Which
kinds of attacks does OAuth explicitly not protect against (e.g., DoS)?
What resources do you expect attackers to apply to compromising
resources protected by OAuth?

A few pages should do for the threat model.  An abstract of the OAuth
threat model should also be possible to write.

> We therefore aim to produce a separate security document
> (informational I-D/RFC) covering threat model as well as security
> design and considerations. The security considerations section of the
> core spec can then be distilled from this document.

Sure.  Procedurally speaking, that works.

Nico
--