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

Erik Wahlström neXus <erik.wahlstrom@nexusgroup.com> Thu, 19 November 2015 09:17 UTC

Return-Path: <erik.wahlstrom@nexusgroup.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EBC4D1B3041 for <oauth@ietfa.amsl.com>; Thu, 19 Nov 2015 01:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.884
X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id x0l6G2hu-sK2 for <oauth@ietfa.amsl.com>; Thu, 19 Nov 2015 01:17:21 -0800 (PST)
Received: from smtp.nexusgroup.com (smtp.nexusgroup.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EF81B303C for <oauth@ietf.org>; Thu, 19 Nov 2015 01:17:20 -0800 (PST)
Received: from NG-EX01.ad.nexusgroup.com ( by NG-EX01.ad.nexusgroup.com ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 10:17:18 +0100
Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 10:17:18 +0100
From: Erik Wahlström neXus <erik.wahlstrom@nexusgroup.com>
To: "<oauth@ietf.org>" <oauth@ietf.org>
Thread-Topic: A review of draft-ietf-oauth-pop-architecture-05
Thread-Index: AQHRIqsWh1Kr9qJTskO0p1mDeu7WuQ==
Date: Thu, 19 Nov 2015 09:17:18 +0000
Message-ID: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
x-mailer: Apple Mail (2.2104)
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4197256B0C1246AAB2F2C9849F44BB3Anexusgroupcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/nHyYqDmCv5AOYEx--iZ9WtDrnKU>
Subject: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05
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: Thu, 19 Nov 2015 09:17:25 -0000


I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we have a draft that uses PoP tokens for IoT and the architectures defined here so my review was done with that IoT perspective. I’m a bit late with the review and some of the comments might already be mentioned by others.


3.1. Preventing Access Token Re-Use by the Resource Server

If a symmetric key is used it’s possible to re-use the key for a resource server. The section talks about the importance of scopes, but I feel it should also mention the importance for the resource server to verify the audience (“aud”) claim in the token to disable missuse.


The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00) relies heavily on this work. The main reason for this is the way PoP tokens can establish key material, with the help of the authorization server, on both the client and resource server. PoP tokens is also a very good fit for constrained IoT devices that can be offline and it’s also possible to use hardware key storages to handle asymmetric pop keys.

There could be a place for a new "Use Case" under section 3 that talks about scenarios where PoP keys are a really good match for offline IoT devices. I could help out ironing out a text for that with the help of the docs authors if that’s of interest.


s/a bogus tokens/a bogus token


In the document only references are made to JSON, JWT and JOSE. More exactly in the following two sections:

   A number of the threats listed in Section 4<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#section-4> demand protection of the
   access token content and a standardized solution, in form of a JSON-
   based format, is available with the JWT [RFC7519<https://tools.ietf.org/html/rfc7519>].

   With the JSON Web Token (JWT) [RFC7519<https://tools.ietf.org/html/rfc7519>] a standardized format for
   access tokens is available.  The necessary elements to bind symmetric
   or asymmetric keys to a JWT are described in

Constrained IoT devices uses other access token and messages formats (according to our draft). It does not only use signed/encrypted JWT’s but also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt

I totally agree that JWT is the correct examples to have in this document due to the fact that they are RFC’s, they are well known and should be used in as many places as possible, but it would be good to open up for other types of message formats. For example like this:

   A number of the threats listed in Section 4<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#section-4> demand protection of the
   access token content and a standardized solution in form of, for example, a JSON-
   based format, is available with the JWT [RFC7519<https://tools.ietf.org/html/rfc7519>].


 For that
   purpose the client will have to authenticate the resource server
   before transmitting the access token.

I’m missing a description about how this is handled in an end-to-end security scenario.


      The resource server queries the authorization server for the
      symmetric key.  This is an approach envisioned by the token
      introspection endpoint [I-D.ietf-oauth-introspection<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#ref-I-D.ietf-oauth-introspection>].

Not a question for this draft maybe, but in what draft is the introspection response claim defined? It’s not defined in https://tools.ietf.org/html/rfc7662#section-2.2 and I don’t know in what other draft it can be defined.


In ACE WG the draft seitz-ace-oauth-authz have a profile for an access request to make it work over CoAP. CoAP is the HTTP equivalent for constrained devices, and it has limitations, for example it can’t send large tokens in options (headers in "http-speak"). This means that the draft defines a way to first send the PoP token to an new endpoint on the resource server to establish a security context. Then the real request against the resource server can be done once the security context is established. See more details here https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.2.

An open question; should a flow like that be added to the architecture section? That means a new section 7.5.


Thanks for writing this. I think it’s very important work.

/ Erik