Subject: Re: [Ace] Secdir review of draft-ietf-ace-oauth-params-06

From: Seitz Ludwig <[email-masked]>
Date: Tue, 7 Jan 2020 20:16:44 +0000

Hello Charlie,

Thank you for the review, sorry for the tardive reply (things got a bit chaotic due to an affiliation change on my part). The -10 version here: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params addresses your comments given the additional explanations by Ben.

Please confirm if this satisfies your requested changes.

Regards,

Ludwig

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: den 17 december 2019 23:02
To: Charlie Kaufman <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-ietf-ace-oauth-params-06

Hi Charlie,

Thanks for the review!

On Fri, Dec 13, 2019 at 07:48:22AM +0000, Charlie Kaufman wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> This document only exists because of a scheduling issue between the ACE and OAUTH working groups. The ACE working group needed some additional OAUTH extensions added more quickly that the OAUTH group could manage to do it. This document is intended to only exist until the OAUTH group can make the corresponding changes. As such, it really doesn't have security considerations beyond those in the document it modifies.
> 
> The security considerations section says (and I agree):
> 
> This document is an extension to [I-D.ietf-ace-oauth-authz]. All security considerations from that document apply here as well.
> 
> Some acronyms that were not defined (but this might be OK in the 
> context of this being a modification to another document): AS, RS, 
> CoAP, cnf, CBOR, pop, CWT
> 
> 
> A few typos / odd phrasing:
> 
> Abstract: whishes -> wishes
> Appendix A: possesion -> possession
> 
> >From Section 2:
> Note that the term "endpoint" is used here following its OAuth 2.0 [RFC6749] definition, which is to denote resources such as token and introspection at the AS and authz-info at the RS.
> 
> Really? The term "endpoint" refers to tokens and authz-info data structures? This seems unlikely.

Not data structures, but (HTTP/CoAP) resources -- "things you can POST to".

> Continuing in Section 2:
> The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this specification.
> 
> Why is a definition that does not apply relevant to this document?

This document is at the intersection of two worlds: CoAP and OAuth.  Both define "endpoint" but in contradictory ways.  Since at least one has to lose, giving the reader a pretty explicit hint that they're wrong to use a given definition seems to have value.  But maybe I'm in the rough; we'll see :)

-Ben