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
