Subject: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Thu, 01 Apr 2021 13:32:08 -0700

Martin Duke has entered the following ballot position for
draft-ietf-oauth-access-token-jwt-12: 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-oauth-access-token-jwt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(2.1) "...can use any signing algorithm." I presume there ought to be some
qualifiers on allowed algorithms?

(4) and (5) "This specification
   does not provide a mechanism for identifying a specific key as the
   one used to sign JWT access tokens."

I don't understand; there's a key ID right there in the token header?

(4) I presume it's important that any resouree server rejection of the token
should be constant-time. Is this somewhere in the RFC tree, or do we need to
explicitly say it here and/or in Security Considerations?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Apr 2021 12:12:23 -0700

> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

The concern here is about identifying keys authorized to sign JWS access
tokens.  The server-provided metadata that lists such keys has a single
bucket that covers keys used for signing different things, so you don't get
any security benefit from key isolation, and a compromise of any of the
(other) keys listed by the server would allow the attacker to sign JWT
access tokens that are accepted as valid.

So in a sense this is not about which key was actually used, but rather
which key is supposed to be used.

> explicitly say it here and/or in Security Considerations?

(A good question, but I don't actually have the answer handy in memory.)

-Ben

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 14 Apr 2021 07:18:57 +0000

Thanks Martin for the comments and Benjamin for addressing some of them!

    > qualifiers on allowed algorithms?
The algorithms referred to here are the ones defined by the usual JWT/JWS, as in JWA (RFC7518). The reader should be able to get it from the context without ambiguity.

    > explicitly say it here and/or in Security Considerations?
I am thinking of analogous descriptions in other specs and I don’t recall mentions of that aspect, hence I assumed we didn’t have to specify it here either. In particular, I glanced thru RFC6750  section 3, which this spec specializes for the specific JWT AT scenario, and they don’t mention that either.

On 4/8/21, 12:12, "Benjamin Kaduk" <[email-masked]> wrote:

    

    
    -Ben

---

From: Martin Duke <[email-masked]>
Date: Mon, 19 Apr 2021 15:45:20 -0700

Alright, this all sounds good without any changes, except:

On Wed, Apr 14, 2021 at 12:18 AM Vittorio Bertocci <
[email-masked]> wrote:

> I am thinking of analogous descriptions in other specs and I don’t recall
> mentions of that aspect, hence I assumed we didn’t have to specify it here
> either. In particular, I glanced thru RFC6750  section 3, which this spec
> specializes for the specific JWT AT scenario, and they don’t mention that
> either.
>

IMO it would be good to add this here, especially if it isn't described
elsewhere in the ecosystem. That said, I'm happy to defer to the Security
AD as to whether this is an important addition.