Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Benjamin Kaduk <[e-mail]>]

On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> Hi Jim,
> 
> Jim Schaad <[e-mail]> writes:
> 
> > -----Original Message-----
> > From: Ace <[e-mail]> On Behalf Of Olaf Bergmann
> > Sent: Monday, January 6, 2020 2:03 AM
> > To: Jim Schaad <[e-mail]>
> > Cc: [e-mail]; 'Benjamin Kaduk' <[e-mail]>;
> > [e-mail]
> > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> >
> > Jim,
> >
> > Jim Schaad <[e-mail]> writes:
> >
> > [Ben's review]
> >> We also are potentially in violation of the framework's requirements with respect to the independent selection of profiles for client/AS and client/RS interactions -- at present, when DTLS+RPK is used for client/RS, we require that DTLS+RPK is also used for client/AS, in order to prove possession of the key.  We could perhaps weasel our way out by saying that the framework's requirement applies at the profile granularity, and with symmetric PSK we can be fully independent, but we still need to say something about this property and the interaction with the framework's requirements.
> >>
> >> [JLS] I am missing where it is saying this.   Can you give a pointer?  I don't believe that the POP of the RPK is required at the time that the token is obtained.
> >
> > The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS.
> >
> > [JLS]  What if I do the following sequence of events:
> > 1.  The AS is configured with RPK1 for the client and the client is configured with RPK2 for the AS.
> > 2.  The client and the AS run some type of POP algorithm, not currently specified, to configure RPK3 into the AS for a second RPK to work with some set of audiences (AUD1).
> > 3.  The client then uses RPK1 to authenticate to the AS and asks for a new token for AUD1 and provides (explicitly or implicitly RPK3).  The AS knows that it is tied to the client due to what happened in step 2.  The AS then creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and returns it.
> >
> > The AS does a current POP for RPK1 when the token is being asked for.
> > The AS did a POP for RPK3 when it was placed into the system.
> > The AS has not done a POP for RPK4 - that was simply configured without that step ever being done.  The ACE framework has no ability for the AS to do the POP on RPK4 and ensure that it current.  The client would do a POP when the TLS session is created but has to rely on the AS that it is for the correct RS.
> >
> > Note that the client can never generate a brand new RPK9 and send it to the AS in the token request because the AS will never have seen this before and would need to run the POP algorithm of step 2 in order to assure that it is bound to the correct client and not pulled out of thin air.  RPK9 could not be used to authenticate the token request because the AS has no idea what client it is tied to.
> 
> okay, I see you have a valid point here. I will try to come up with some
> text that says that the AS must ensure that (in your scenario) RPK1 and
> RPK3 are bound to the same entity.

Jim's proposal seems broadly reasonable (though I think in general there
needs to be some AS contributory nature in order to get proof of current
possession of RPK3 at the time of (2).  I think I would phrase it as "in
possession of the same entity" rather than "bound to the same entity",
though.

-Ben