Thanks Ludwig, That does alleviate the concerns/confusion I had regarding the rs_cnf claim.
On Sat, Feb 1, 2020 at 3:20 AM Ludwig Seitz <ludwig_se...@gmx.de> wrote: > 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 > -- _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._
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
