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

[Seitz Ludwig <[e-mail]>]

Hello Roman,

Thank you for reviewing this draft. Sorry for the long answering delay.

Version -39 (https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-39) addresses your comments, except for: 

> ** 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.

This comment requires coordination with the other draft's main authors, working on it.

Regards,

Ludwig

> -----Original Message-----
> From: Roman Danyliw via Datatracker <[e-mail]>
> Sent: den 23 mars 2021 04:05
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [EXTERNAL] Roman Danyliw's Yes on draft-ietf-ace-oauth-authz-38:
> (with COMMENT)
> 
> 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/
> 
>