[OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 16 November 2015 20:37 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 E83831B3139 for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2015 12:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 uP_VjcCcW9hn for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2015 12:37:01 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 777CE1B3138 for <oauth@ietf.org>; Mon, 16 Nov 2015 12:37:01 -0800 (PST)
Received: by wmww144 with SMTP id w144so127069236wmw.1 for <oauth@ietf.org>; Mon, 16 Nov 2015 12:37:00 -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=WoKKp6XbD1w+Ss8gkH2y3R1AjmQ22iILAnyUcq/SHxY=; b=Ec+rpkYJ2PRWr1F90CvYMyFb9Vy58uu2xoB4pgebWxj83UPVZKH5SA9WNJ+TbM/P9G Xgftz+vQDcLOL/7L1l1Cipkbs7dMn9Vv576ByRWlbnypIYONT2/Lt0XpsB19h/EdzzUr tSx3Kw9OL1vPsJKPNlAr03x6meWPlZW0FSJTKb5VJXXByjzKWXeaAbcJSWxWEl1uG1MP gBpBULMcb7KFSEKHkzIJAa/XR48v+WgtwXHFsLRPQHKKghqZoMp1RsjKgibvqIE13Acu nmQc/Iu1Mcis80PsBvYK26uJv5VapG5h69YBpsqdal3m+wy57z+rqTTDFbRxc0TlI9Hy Txlw==
MIME-Version: 1.0
X-Received: by 10.28.126.215 with SMTP id z206mr21739120wmc.71.1447706220073; Mon, 16 Nov 2015 12:37:00 -0800 (PST)
Received: by 10.28.52.130 with HTTP; Mon, 16 Nov 2015 12:37:00 -0800 (PST)
Date: Mon, 16 Nov 2015 15:37:00 -0500
Message-ID: <CAHbuEH5nRQcKQMh8LDGdfBQ=Z4AWeKJxxCGV7V-gh_dSuSpb7w@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/932Pn99G_7C_QxGGkUDDM4XIViE>
Subject: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture
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: Mon, 16 Nov 2015 20:37:03 -0000

Hello,

I reviewed draft-ietf-oauth-pop-architecture and have a few questions.

1. Section 6, Threat Mitigation:

Last sentence of first paragraph, "To
   simplify the subsequent description we assume that the token itself
   is digitally signed by the authorization server and therefore cannot
   be modified."

Since bearer tokens are not signed by default, is this proposing a
change?  If so, where will that change occur?  To state that "it is
assumed" without it being required anywhere is not a good assumption.
I'd still see this as a risk or security consideration.  When OAuth is
re-used by other protocols, I am seeing that re-use leave off basic
protections that should be assumed like TLS, let alone digital
signatures.  If this is required in the defined architecture (Section
7 - it does show this, but there are no MUSTs that I can find), just
state that and refer to the requirement.

2. Section 6, Threat Mitigation

Third paragraph, "As an example, TLS with a ciphersuite
   that offers confidentiality protection has to be applied (which is
   currently true for all ciphersuites, except for one).

Please list a reference so the reader knows which ciphersuites are
acceptable from the recommended ones in RFC7525.  I don't recall there
being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and
that we've discussed that already with previous drafts, so this should
be spelled out more).

3. (Nit) Section 6.2, add a comma to improve readability
From: "Instead of providing confidentiality protection the authorization
   server could also put the identifier of the client into the protected
   token with the following semantic:"
To: "Instead of providing confidentiality protection, the authorization
   server could also put the identifier of the client into the protected
   token with the following semantic:"

Thank you all for your work on this draft!
-- 

Best regards,
Kathleen