Subject: [Ace] Martin Duke's No Objection on draft-ietf-ace-oauth-params-13: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Thu, 18 Mar 2021 11:44:53 -0700

Martin Duke has entered the following ballot position for
draft-ietf-ace-oauth-params-13: No Objection

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-params/

----------------------------------------------------------------------
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?

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Mar 2021 19:16:39 -0700

Hi Martin,

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

---

From: Seitz Ludwig <[email-masked]>
Date: Wed, 24 Mar 2021 07:42:30 +0000

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-masked]>
> Sent: den 21 mars 2021 03:17
> To: Martin Duke <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]
> Subject: [EXTERNAL] Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-
> oauth-params-13: (with COMMENT)
> 
> Hi Martin,
> 
> > 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?
> 
> 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
> 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
> 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.

---

From: Martin Duke <[email-masked]>
Date: Thu, 25 Mar 2021 12:06:02 -0700

LGTM. Thanks

On Wed, Mar 24, 2021 at 12:42 AM Seitz Ludwig <[email-masked]>
wrote:

> "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)"
>
> than