-----Original Message-----
From: Benjamin Kaduk <[email protected]>
Sent: Thursday, January 9, 2020 1:22 PM
To: Jim Schaad <[email protected]>
Cc: 'Olaf Bergmann' <[email protected]>;
[email protected]; [email protected]
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote:
>
>
> -----Original Message-----
> From: Benjamin Kaduk <[email protected]>
> Sent: Thursday, January 9, 2020 12:17 PM
> To: Olaf Bergmann <[email protected]>
> Cc: Jim Schaad <[email protected]>; [email protected];
> [email protected]
> 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 <[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.
>
> 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).
[JLS] Yea I think you are right - I would need to go read CMC and make sure
that I got everything right as I spent about 2 years doing the analysis
there
-Ben
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
