[Jwt-reg-review] [IANA #1160802] Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

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
Senior IANA Services Specialist

> 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
> > <ludwig.seitz@combitech.se>
> > wrote:
> >
> > > Hi Brian,
> > >
> > >
> > >
> > > Comments inline.
> > >
> > >
> > >
> > > /Ludwig
> > >
> > >
> > >
> > > *From:* Brian Campbell <bcampbell@pingidentity.com>
> > > *Sent:* den 13 januari 2020 21:22
> > > *To:* Seitz Ludwig <ludwig.seitz@combitech.se>
> > > *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
> > > <ludwig.seitz@combitech.se>
> > > 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
> > >
> > >
> > >
> > > *From:* Ace <ace-bounces@ietf.org> *On Behalf Of *Brian Campbell
> > > *Sent:* den 10 januari 2020 22:12
> > > *To:* Ludwig Seitz <ludwig_seitz@gmx.de>
> > > *Cc:* Roman Danyliw <rdd@cert.org>; jwt-reg-review@ietf.org; Jim
> > > Schaad <
> > > ietf@augustcellars.com>; The IESG <iesg@ietf.org>; ace@ietf.org;
> > > drafts-lastcall@iana.org; Benjamin Kaduk <kaduk@mit.edu>
> > > *Subject:* Re: [Ace] Requested review for IANA registration in
> > > draft-ietf-ace-oauth-params
> > >
> > >
> > >
> > > 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 <ludwig_seitz@gmx.de>
> > > 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 "rs_cnf" claim registered
> > > here:
> > >
> > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-
> > > 9.1
> > >
> > > Thank you in advance for you review comments.
> > >
> > > Regards,
> > >
> > > Ludwig
> > >
> > > _______________________________________________
> > > Ace mailing list
> > > Ace@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ace
> > >
> > >
> > > *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.*
> > >
> > >
> > > *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.*
> > >
> >
> > --
> > _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._