[Ace] Roman Danyliw's Yes on draft-ietf-ace-oauth-authz-38: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 23 March 2021 03:04 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ace@ietf.org
Delivered-To: ace@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 342013A1B3E; Mon, 22 Mar 2021 20:04:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-ace-oauth-authz@ietf.org, ace-chairs@ietf.org, ace@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <161646869070.23075.303761097693732783@ietfa.amsl.com>
Date: Mon, 22 Mar 2021 20:04:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/n5GXWaeGz9plOqDmmX8Zotkbkuk>
Subject: [Ace] Roman Danyliw's Yes on draft-ietf-ace-oauth-authz-38: (with COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 03:04:51 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-oauth-authz-38: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Stephen Kent for the SECDIR review, and thank you to the authors
for responding to it.

** Section 5.3.  Per “The RS sending this response (i.e., RS) uses an internal
clock that is only loosely synchronized with the clock of the AS”, a more
precise phrase that “loosely synchronized” would be helpful.

** Section 6.2.  It would be worthwhile to clarify the following:

Section 6.2.
(a) Developers MUST ensure that ephemeral credentials … are not leaked to third
parties.

(b) An
   adversary in possession of the ephemeral credentials bound to the
   access token will be able to impersonate the client.  Be aware that
   this is a real risk with many constrained environments, since
   adversaries can often easily get physical access to the devices.

(a) is helpful guidance; and independently (b) is a good reminder.  However,
the risk of a leak to a third party seems independent of getting physical
access.

** Section 6.4.  Per “C therefore MUST determine if an AS is authorized to
provide access tokens for a certain RS.”, this is good advice.  Additionally,
it should be clarified that the means for a C to determine if the AS has the
authority to issue access tokens for a given RS is left to the application and
out of scope of this document.

** Fully appreciating that this document is already quite long, consider
whether it would be helpful to implementers to add another block of text to
explicitly enumerate how this framework alters OAuth.  For example: ==[ snip ]==

This document adapts OAuth v2 to be suitable for the IoT environment.  In
particular it differs from the normative requirements of OAuth in the following
ways:

*    Use of TLS -- OAuth 2.0 requires the use of TLS both to protect the
communication between AS and client when requesting an access token; between
client and RS when accessing a resource and between AS and RS if introspection
is used.  This framework requires similar security properties, but does not
require that they be realized with TLS.  Section 5.

* Cardinality of grant_type parameter -- In client-to-AS requests using OAuth
2.0, the grant_type parameter is required (per [RFC6749]).  In this framework,
this parameter is optional.  See Section 5.8.1.

* Encoding of scope parameter – In client-to-AS requests using OAuth 2.0, the
scope parameter is string encoded (per [RFC6749]).  In this framework, this
parameter may also be encoded as a byte string.  See Section 5.8.1.

* Cardinality of token_type parameter – in AS-to-client responses using OAuth
2.0, the token_type parameter is required (per [RFC 6749]).  In this framework,
this parameter is optional.  See Section 5.8.2.

* Access token retention – in OAuth 2.0, the access token is sent with each
request to the RS.  In this framework, the RS must be able to store these
tokens for later use.  See Section 5.10.1.

 ==[ end ]==

** Would the first paragraph of Section 7.2 of draft-ietf-ace-dtls-authorize
providing caution about the challenges of multiple access tokens be better
served by placing it in this document?  Section 7 of
draft-ietf-ace-oscore-profile has similar words too.

** Editorial Nits

-- Section 3.1.  Typo.  s/token token/token/

-- Section 5.3. Typo s/nevetheless/nevertheless/

-- Section 6.6. Typo s/loose the current/lose the current/

-- Section 6.6. Typo s/the the/the/