Hi Jim, Jim Schaad <[email protected]> writes:
> -----Original Message----- > From: Ace <[email protected]> On Behalf Of Olaf Bergmann > Sent: Monday, January 6, 2020 2:03 AM > To: Jim Schaad <[email protected]> > Cc: [email protected]; 'Benjamin Kaduk' <[email protected]>; > [email protected] > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > Jim, > > Jim Schaad <[email protected]> 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. Grüße Olaf _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
