[secdir] SECDIR review of draft-ietf-oauth-pop-architecture-07

Matthew Lepinski <mlepinski.ietf@gmail.com> Sun, 13 December 2015 22:28 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 44AF21A8863; Sun, 13 Dec 2015 14:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5828avPtvbn3; Sun, 13 Dec 2015 14:28:16 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946C51A8862; Sun, 13 Dec 2015 14:28:16 -0800 (PST)
Received: by lbblt2 with SMTP id lt2so97049267lbb.3; Sun, 13 Dec 2015 14:28:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ALNTRTk6eUzQFXAYG2R3675917RgFKL3yfaxe735Faw=; b=k0Az7/oiLnoBn42b23NSgaN4RuEc+1L7Y9N99dRrWifBzaSYlHP/6IrERmeNgOxFsw Dc7ZkxJcTxOZX0O6TPprmsHcnYo8iQGTy2d++DkH4XqmxTKMmTMx1jdUb7SfoR51Lge+ wRlUDC+ZKf587GnpyPrAkLz4HJat3M16tbus3WlIfoR5T8Zx9/LmnFAqtadT+uJC4UBW p3Re/HRoCn+T/dQu8mWsNj+4D/+SR56/3zHlkFBVK+6fDga4K2NePSChoFUg7zH+LTkc nEy2XN3yQF0ANYTekZt5c625ke7CK5moOHKVZeXnjn9rLk49zoKEHRuBIpsgzEbYdUsr SLAA==
MIME-Version: 1.0
X-Received: by with SMTP id oz10mr11639289lbb.92.1450045694646; Sun, 13 Dec 2015 14:28:14 -0800 (PST)
Received: by with HTTP; Sun, 13 Dec 2015 14:28:14 -0800 (PST)
Date: Sun, 13 Dec 2015 17:28:14 -0500
Message-ID: <CANTg3aCbv-v4ox3Bng-1PrEOLQX5otA79QCJ63VNk8k7Pu6cSA@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-oath-pop-architecture.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=047d7b3a8bfa89a3e60526cf120e
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/AYeMw7a46yPCGZF3Ny9IFJhemvk>
Subject: [secdir] SECDIR review of draft-ietf-oauth-pop-architecture-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Dec 2015 22:28:18 -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 comments.

This document is ready. I have one minor suggestion (see below), but the
document appears seems ready for publication.

This is the architecture and requirements document associated with OAUTH
2.0 Proof of Possession (see draft-ietf-oauth-proof-of-possession and
draft-ietf-oauth-pop-key-distribution). The use-cases (and associated
security concerns) that motivate proof of possession mechanisms are clearly
laid out in the document, as our the security requirements for an
acceptable proof of possession mechanism.

The document assumes knowledge of RFC 6819 -- the OAUTH 2.0 Threat Model
and Security Considerations. (In particular, the architectural assumptions,
security properties and threat model laid out in 6819 seem vital to
understanding the security requirements in this document.) Therefore, I
would like to see an explicit reference to 6819 in the Security
Considerations section of this document. That is, it would be helpful to
make clear that the Threat Model and Architectural Assumptions in 6819
apply to this document.

- Matt Lepinski