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

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Thursday, January 9, 2020 12:17 PM
To: Olaf Bergmann <[e-mail]>
Cc: Jim Schaad <[e-mail]>; [e-mail];
[e-mail]
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 <[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.

[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.

Jim


-Ben