On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Thursday, January 9, 2020 12:17 PM > To: Olaf Bergmann <bergm...@tzi.org> > Cc: Jim Schaad <i...@augustcellars.com>; ace@ietf.org; > draft-ietf-ace-dtls-authorize....@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > 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. > > [JLS] If I was to write this out as a real protocol, it would end up > something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || AS > Nonce || Client Nonce )) so that we know that both keys are in the > possession of a single entity (or a cabal collaborating) and it is current > to the run of the POP protocol.
With a fixed protocol/context string to indicate the intent of what's being signed, of course :) I am too distracted to do a proper analysis right now but seem to recall that usually an indication of "both parties/keys agree to <X>" involves three signatures, so that each party certifies the signature of the other over the operation (in addition to the operation itself). -Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
