On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad <i...@augustcellars.com> writes: > > > -----Original Message----- > > From: Ace <ace-boun...@ietf.org> On Behalf Of Olaf Bergmann > > Sent: Monday, January 6, 2020 2:03 AM > > To: Jim Schaad <i...@augustcellars.com> > > Cc: ace@ietf.org; 'Benjamin Kaduk' <ka...@mit.edu>; > > draft-ietf-ace-dtls-authorize....@ietf.org > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > Jim, > > > > Jim Schaad <i...@augustcellars.com> 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
