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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]>
> wrote:
> 
> > Hi Brian,
> >
> >
> >
> > Comments inline.
> >
> >
> >
> > /Ludwig
> >
> >
> >
> > *From:* Brian Campbell <[e-mail]>
> > *Sent:* den 13 januari 2020 21:22
> > *To:* Seitz Ludwig <[e-mail]>
> > *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 <[e-mail]>
> > 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 <[e-mail]> *On Behalf Of *Brian Campbell
> > *Sent:* den 10 januari 2020 22:12
> > *To:* Ludwig Seitz <[e-mail]>
> > *Cc:* Roman Danyliw <[e-mail]>; [e-mail]; Jim Schaad <
> > [e-mail]>; The IESG <[e-mail]>; [e-mail];
> > [e-mail]; Benjamin Kaduk <[e-mail]>
> > *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 <[e-mail]> 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
> > [e-mail]
> > 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._