Subject: Re: [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jan 2020 13:57:16 -0700

I'm really struggling with understanding what the value of an "ace_profile"
claim actually would be in a JWT. A JSON string that's the profile name
(though 5.6.4.3 maybe prohibits that)?  A JSON number that's an integer
matching the CBOR Value? Something else?

Is the value of "exi" in a JWT a JSON number? Seems likely but it's
something that should probably be made explicit.

Also for "exi", the requirement in 5.8.3. to "keep track of the identifiers
of tokens containing the "exi" claim that have expired (in order to avoid
accepting them again)" seems problematic in that it sounds like it's
mandating an unbounded growth of memory use.

The draft says that the "cnonce" claim (value) uses binary encoding. What
does that mean for JSON based JWT?

On Sat, Dec 21, 2019 at 4:35 AM Ludwig Seitz <[email-masked]> wrote:

> Hello JWT registry reviewers,
>
> the IESG-designated experts for the JWT claims registry have asked me to
> send a review request to you about the claims registered here:
>
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.12
>
> Thank you in advance for you review comments.
>
> Regards,
>
> Ludwig
>
> _______________________________________________
> Jwt-reg-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jwt-reg-review
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jan 2020 14:12:01 -0700

That  "rs_cnf" claim registration request in 9.1 points to 3.3 which says
it has 'the same syntax and semantics as defined in for the "rs_cnf"
parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" values
'follow the syntax of the "cnf" claim from section 3.1 of
[I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments I've
made today, I don't follow what that would mean for the value of the claim
when it's a JWT. And that seems like something that's important to
understand for the purpose of a JWT claims registry request.

On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz <[email-masked]> wrote:

> send a review request to you about the "rs_cnf" claim registered here:
>
> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1
>
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Jan 2020 14:01:00 -0700

Thanks for the updates Lugwig,

Section 6.6. does propose one mitigation for the unbounded memory growth
problem. However, it relies on the AS to do pretty specific things with the
content of other claims for it to even be possible for an RS to perform the
mitigation approach. Do you think, for interoperability, it needs to be
more prescriptive? Like maybe requiring the cti/jti claim with specific
content and characteristics when exi is present or embedding/encoding that
sequence number in the value of the exi itself alongside the lifetime of
the token.

On Sat, Jan 11, 2020 at 9:16 AM Seitz Ludwig <[email-masked]>
wrote:

> Hello Brian,
>
>
>
> Thank you for this review!
>
> I have added text to clarify the formatting of these parameters and claims
> when used in JSON-based interactions.
>
> More comments inline.
>
>
>
> Regards,
> Ludwig
>
>
>
> *From:* Ace <[email-masked]> *On Behalf Of *Brian Campbell
> *Sent:* den 10 januari 2020 21:57
> *To:* Ludwig Seitz <[email-masked]>
> *Cc:* Roman Danyliw <[email-masked]>; [email-masked]; Jim Schaad <
> [email-masked]>; The IESG <[email-masked]>; [email-masked];
> [email-masked]; Benjamin Kaduk <[email-masked]>
> *Subject:* Re: [Ace] [Jwt-reg-review] Requested review for IANA
> registration in draft-ietf-ace-oauth-authz
>
>
>
> I'm really struggling with understanding what the value of an
> "ace_profile" claim actually would be in a JWT. A JSON string that's the
> profile name (though 5.6.4.3 maybe prohibits
>
> that)?  A JSON number that's an integer matching the CBOR Value? Something
> else?
>
>
>
> [LS] For JSON the string representation is ok, I reworded 5.6.4.3 to
> clarify this.
>
>
>
> [LS] Now explicit
> Also for "exi", the requirement in 5.8.3. to "keep track of the
> identifiers of tokens containing the "exi" claim that have expired (in
> order to avoid accepting them again)" seems problematic in that it sounds
> like it's mandating an unbounded growth of memory use.
>
>
>
> Section 6.6. proposes a mitigation for the unbounded growth of memory use
> problem. Does that resolve your reservations?
>
>
>
> [LS] Now Base64 encoded binary for JSON.
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 18 Jan 2020 17:21:18 +0100

On 2020-01-13 22:01, Brian Campbell wrote:
> problem. However, it relies on the AS to do pretty specific things with
> the content of other claims for it to even be possible for an RS to
> perform the mitigation approach. Do you think, for interoperability, it
> needs to be more prescriptive? Like maybe requiring the cti/jti claim
> with specific content and characteristics when exi is present or
> embedding/encoding that sequence number in the value of the exi itself
> alongside the lifetime of the token.
>
>

This sounds like a reasonable requirement. I'm even inclined to make
that a MUST and not just a SHALL. Next update coming soon.

/Ludwig

---

From: Brian Campbell <[email-masked]>
Date: Tue, 21 Jan 2020 14:35:26 -0700

Thanks Ludwig, -31 is improved with regard to my previous concerns about
'exi'

---

From: "Sabrina Tanamal via RT" <[email-masked]>
Date: Fri, 24 Jan 2020 16:59:09 +0000

Hi Ben, 

Since there are multiple experts for this registry, we can ask the others to review the registration. 

Thanks,

Sabrina Tanamal
Senior IANA Services Specialist

On Fri Jan 24 01:46:47 2020, [email-masked] wrote:
> Thanks for putting the effort in, Brian.
> 
> IANA, do you need to assign a new expert to reviewi the JWT Claims
> registration request from this document, or are the experts expected
> to be
> self-organizing here?
> 
> Thanks,
> 
> Ben
> 
> On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote:
> > Apologies, I forgot to reply-all at some earlier point and dropped
> > the
> > mailing lists and other cc's off the thread. Added back now.
> >
> > And also apologies because I think I need to recuse myself from the
> > DE
> > responsibility on the JWT registry request here. I've spent more time
> > than
> > I'd like to admit or really have to spare on it and am still
> > struggling to
> > understand.
> >
> > I appreciate you pointing out the authz-info endpoint in ACE but I
> > still
> > don't follow how "rs_cnf" in an access token would really work in
> > practice.
> > The client sends the token to the RS's authz-info endpoint on an
> > insecure
> > connection or one that has the server auth with potentially different
> > key
> > and the RS stores the access token for later use. Then on resource
> > access
> > the RS looks up the access token (with respect to the cnf key in it)
> > based
> > on the key the client used in establishing a new mutually
> > authentication
> > connection to the RS. For the RS to choose a key for server it will
> > use
> > during the handshake (and as far as I know the server key is the
> > first in
> > the authn process of the handshake) based on the "rs_cnf" in the
> > access
> > token, it needs to remember and associate that client and the access
> > token
> > with something else (IP address?) that will be available during the
> > handshake. It doesn't fit together for me in a way that seems likely
> > to
> > work or be interoperable but, like I said, I'm really struggling to
> > understand.
> >
> > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig
> > <[email-masked]>
> > wrote:
> >
> > > Hi Brian,
> > >
> > >
> > >
> > > Comments inline.
> > >
> > >
> > >
> > > /Ludwig
> > >
> > >
> > >
> > > *From:* Brian Campbell <[email-masked]>
> > > *Sent:* den 13 januari 2020 21:22
> > > *To:* Seitz Ludwig <[email-masked]>
> > > *Subject:* Re: [Ace] Requested review for IANA registration in
> > > draft-ietf-ace-oauth-params
> > >
> > >
> > >
> > > Thanks for the response and updates Ludwig,
> > >
> > >
> > >
> > > Please bear with me while I try to wrap my head around some things.
> > >
> > >
> > >
> > > The JWT registration request for the "rs_cnf" claim points to Sec
> > > 3.3
> > > <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-
> > > 08#section-3.3>
> > > saying it is "a hint [in the access token] to the RS about which
> > > key it
> > > should use to authenticate towards the client".  But doesn't the
> > > client
> > > have to go through the DTLS/TLS handshake with the RS (which is
> > > presumably
> > > when it authenticates to the client) before it presents the access
> > > token?
> > > I'm not seeing how this would work as seems the RS won't see the
> > > hint until
> > > after it needs it.
> > >
> > >
> > >
> > >
> > >
> > > [LS] Not in the ACE flow. We use the access token to establish keys
> > > at the
> > > RS both for the client and the RS. We have therefore defined a new
> > > ACE-OAuth endpoint (authz-info) at the RS. The client can POST
> > > access
> > > tokens to this endpoint without prior authentication.
> > >
> > > At that point, the RS only validates the signature/MAC by the AS.
> > >
> > >
> > >
> > > Later at the time of access, the corresponding token is linked to
> > > the
> > > access request via the pop-mechanism and the client/access specific
> > > parts
> > > are validated (e.g. scope, subject).
> > >
> > >
> > >
> > > Hope that clarifies things a bit.
> > >
> > >
> > >
> > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig
> > > <[email-masked]>
> > > wrote:
> > >
> > > Hello again Brian,
> > >
> > >
> > >
> > > Thank you for reviewing this! Indeed the handling of JWT/JSON
> > > interactions
> > > was handled sloppily here. I will soon issue a draft update that
> > > specifies
> > > that the JSON-based interactions should use the syntax from RFC7800
> > > while
> > > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession.
> > >
> > >
> > >
> > > This correction goes for all the use of “cnf”, “req_cnf” and
> > > “rs_cnf”.
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > >
> > > Ludwig
> > >
> > >
> > >
> > > *Sent:* den 10 januari 2020 22:12
> > > *Subject:* Re: [Ace] Requested review for IANA registration in
> > > draft-ietf-ace-oauth-params
> > >
> > >
> > >
> > > review, use, distribution or disclosure by others is strictly
> > > prohibited.

---

From: "Sabrina Tanamal via RT" <[email-masked]>
Date: Thu, 30 Jan 2020 00:40:53 +0000

Dear John, Michael, and Chuck, 

Have you had a chance to review the registration in draft-ietf-ace-oauth-params? 

https://tools.ietf.org/html/draft-ietf-ace-oauth-params

Thanks,

Sabrina Tanamal

> > > prohibited..