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

[Ludwig Seitz <[e-mail]>]

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