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

From: Ludwig Seitz <[email-masked]>
Date: Sat, 1 Feb 2020 11:19:53 +0100

On 2020-01-23 22:31, 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.
>
>

Hello Brian,

thank you for your efforts in reviewing the IANA registrations.
As for your struggling to understand, we should have struggled more,
since there was indeed a flaw in the reasoning behind the rs_cnf claim
(and introspection parameter). As a result of that we will remove both
the rs_cnf claim and the introspection parameter, keeping only the
rs_cnf token endpoint parameter, which I believe still makes sense.

Background: When introducing the rs_cnf claim, we had mistakenly assumed
that the RS could associate the token with the ongoing (D)TLS handshake
at the time the server certificate message is to be created, this is not
the case and the rs_cnf claim is therefore useless (same goes for the
rs_cnf introspection parameter).  Instead I will require that a RS MUST
NOT hold more than one asymmetric key pair based on the same algorithm,
used for authentication.  Thus the (D)TLS algorithm negotiation in the
handshake should resolve the issue of which key to use for the RS.

Updates of both draft-ietf-ace-oauth-params and
draft-ietf-ace-oauth-authz coming soon.

/Ludwig

---

From: Brian Campbell <[email-masked]>
Date: Tue, 4 Feb 2020 15:11:18 -0700

Thanks Ludwig,

That does alleviate the concerns/confusion I had regarding the rs_cnf
claim.

-- 
_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: Mike Jones <[email-masked]>
Date: Tue, 18 Feb 2020 22:44:16 +0000

I am OK with these JWT claim registrations.

				-- Mike

-----Original Message-----
From: Jwt-reg-review <[email-masked]> On Behalf Of Sabrina Tanamal via RT
Sent: Friday, January 24, 2020 8:59 AM
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-&amp;data=02%
> > > 7C01%7CMichael.Jones%40microsoft.com%7Cdbbd65cde4094540932b08d7a0f
> > > 0220f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637154825550691
> > > 547&amp;sdata=giictWf%2BpzXWEBH2HBC1vyHYr68OhfO9zPK3Wq0x%2FQc%3D&a
> > > mp;reserved=0
> > > 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
> > >
> > >
> > >
> > > *From:* Ace <[email-masked]> *On Behalf Of *Brian Campbell
> > > *Sent:* den 10 januari 2020 22:12
> > > *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] 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 <[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 "rs_cnf" claim 
> > > registered
> > > here:
> > >
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > tools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-07%23section-&
> > > amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdbbd65cde409454
> > > 0932b08d7a0f0220f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
> > > 154825550701493&amp;sdata=g%2BCfDcbOrCUsP7ptR%2F2dujbWkfYyMiFnqQbP
> > > o122cRs%3D&amp;reserved=0
> > > 9.1
> > >
> > > Thank you in advance for you review comments.
> > >
> > > Regards,
> > >
> > > Ludwig
> > >
> > > _______________________________________________
> > > Ace mailing list
> > > [email-masked]
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=02%7C01%7CMichael
> > > .Jones%40microsoft.com%7Cdbbd65cde4094540932b08d7a0f0220f%7C72f988
> > > bf86f141af91ab2d7cd011db47%7C1%7C0%7C637154825550701493&amp;sdata=
> > > 6Kx4rgPWRbneYvENICHnvWM1Q0TlCvFfeDU16re%2FOb4%3D&amp;reserved=0
> > >
> > >
> > > *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._

_______________________________________________
Jwt-reg-review mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjwt-reg-review&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdbbd65cde4094540932b08d7a0f0220f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637154825550701493&amp;sdata=PE0e7e%2FNg1VTu0R4%2BAYk9wN%2FW4IlMHcxkqwuPV8P71g%3D&amp;reserved=0