[secdir] Review of draft-ietf-oauth-assertions-09

Shawn Emery <shawn.emery@oracle.com> Sun, 30 December 2012 07:08 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0021F882B; Sat, 29 Dec 2012 23:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD0g3Kkr2ixI; Sat, 29 Dec 2012 23:08:23 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4521F8781; Sat, 29 Dec 2012 23:08:23 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBU78Ms1007220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Dec 2012 07:08:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBU78K5N023612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Dec 2012 07:08:20 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBU78Kb8025605; Sun, 30 Dec 2012 01:08:20 -0600
Received: from [10.159.67.241] (/10.159.67.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Dec 2012 23:08:20 -0800
Message-ID: <50DFE815.2020501@oracle.com>
Date: Sun, 30 Dec 2012 00:07:01 -0700
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.7) Gecko/20121011 Thunderbird/10.0.7
MIME-Version: 1.0
To: secdir@ietf.org
References: <50A9523F.9070607@oracle.com>
In-Reply-To: <50A9523F.9070607@oracle.com>
X-Forwarded-Message-Id: <50A9523F.9070607@oracle.com>
Content-Type: multipart/alternative; boundary="------------040106080708040601010101"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: draft-ietf-oauth-assertions.all@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Review of draft-ietf-oauth-assertions-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 30 Dec 2012 07:08:24 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This internet-draft describes an assertion framework for the OAuth 2.0 protocol.  Given that
that this is a framework, subsequent drafts would be needed for a deployed mechanism.

The security considerations section does exist and outlines various issues including
impersonation, replay, and privacy.  The section then suggests ways of mitigating these
threats.  This seems sufficient, but can there be more guidance on the Assertion ID to
avoid collision or replay (e.g. length, roll-over, etc.)?

General comments:

None.

Editorial comments:

Redundant wordings, suggested fix:

Old:

  An IEFT URN for use as the "XXXX" value can be requested using
  the template in An IETF URN Sub-Namespace for OAuth [RFC6755  <http://tools.ietf.org/html/rfc6755>].

New:

  An IEFT URN for use as the "XXXX" value can be requested using
  the template in [RFC6755  <http://tools.ietf.org/html/rfc6755>].

Shouldn't urn:ietf:params:oauth:grant_type:* be
urn:ietf:params:oauth:grant-type:*?

s/included yet all/included, yet all/

Shawn.
--