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 <[email protected]> > Sent: den 23 mars 2021 04:05 > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected] > 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/ > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
