LGTM. Thanks On Wed, Mar 24, 2021 at 12:42 AM Seitz Ludwig <[email protected]> wrote:
> Hi Martin, Ben, > > If I were to change the offending sentence like so: > "It is RECOMMENDED that an AS reject a request containing a symmetric key > value ... (Note: this does not apply to key identifiers referencing a > symmetric key)" > > (the "Note..." part being the new clarification), would that help making > the intention distinction more visible? > > /Ludwig > > > > -----Original Message----- > > From: Benjamin Kaduk <[email protected]> > > Sent: den 21 mars 2021 03:17 > > To: Martin Duke <[email protected]> > > Cc: The IESG <[email protected]>; [email protected]; [email protected]; > draft-ietf- > > [email protected] > > Subject: [EXTERNAL] Re: [Ace] Martin Duke's No Objection on > draft-ietf-ace- > > oauth-params-13: (with COMMENT) > > > > Hi Martin, > > > > On Thu, Mar 18, 2021 at 11:44:53AM -0700, Martin Duke via Datatracker > > wrote: > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > In sec 3.1 it says the AS SHOULD reject req_cnf if the key is > > > symmetric. But in Sec 5 it presents a totally reasonable use case > > > where the C and RS hold a previously established (symmetric?) key. > > > These observations are somewhat contradictory. Should 3.1 include a > > > qualifier. Would the AS know about this key a priori so that it can > > > ignore the recommendation? If not, how can this be done safely? > > > > I think there is a subtle distinction between the two cases, if I am > > remembering correctly. In particular, in Section 3.1 it says that "[i]t > is > > RECOMMENDED that an AS reject a request containing a symmetric key > > value", and the last word ("value") is important! This is saying, if > the client > > tries to propose to the AS the actual symmetric key to be (encapsulated > in > > the token and) used to secure C/RS communications, the AS typically > should > > reject it, since a constrained client is likely to have a much worse RNG > than > > the AS. If, on the other hand, some out-of-band management system has > > provisioned a symmetric key shared by C and RS, that key is presumed to > be > > strong, but in the scenario depicted in Section 5 it is "the > key-identifier of a > > previously established key between C and RS" that "req_cnf" conveys. > > Note that this scenario is only the identifier, not the key value itself. > > > > This is clearly a pretty subtle distinction to make, and if you have any > > suggestions for how to word things to make it more obvious, we'd love to > > have them. > > > > Thanks, > > > > Ben >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
