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
