On Thu, Jul 20, 2023 at 02:35:09PM -0400, Michael Richardson wrote: > So draft-ietf-anima-constrained-voucher, has some optimizations that can > sometimes let the pledge skip the /crts, but why is that interaction so > expensive? > Note that in lake-authz, the voucher isn't actually sent, rather just the > signature on what we expected to see in the voucher.... so extensions to the > voucher would be difficult to do.
My impression was that this was not just an optimization that saves an
initial request, but that the voucher (in all its augmentation that it
gets when the registrar turns the PVR into an RVR) could serve as the
one way the credentials are provisioned through. Packing everything into
the voucher was not motivated by saving round-trips, but by reducing
code paths.
> So if I understand you, you'd like to avoid additional round trips by
> stacking the certificate request with the PVR. BRSKI-PRM does *exactly*
> that, because in the store-and-forward ("DTN") nature of PRM, round trips
> involve people walking up/down stairs.
I think a good next direction would be to skip the "stuffing things
into the voucher" part and instead focus on just doing the /cert /
/s(r)en equivalent of certificate based authentication.
So in a sketch, we'd do just as in authz+CoJP, and in the msg_3 request
(or even a later regular OSCORE request if we use CoJP too) ask the
registrar for the relevant AS data.
I'll try to estavblish that as a new baseline. (Not sure yet whether
that'd better be a -01, or an ace-est-ace as it's not really depending
on BRSKI any more). An upside of that scenario is that it has a
relatively straightforward story for rollover of the AS keys
(corresponding to the rollover of CA keys in EST where the device can
query for the newest values).
In such a scenario I'd only come back to PRM if there's good reason to
actually do PRM (i.e. there are stairs, not just because it looks
suitable), or when that rollover is AS initialized.
That handover gets me thinking: In authz-for-CoJP, the authenticator
plays the role of the JRC (I figure it'll play reverse proxy for the
actual one). Does that mean that the authenticator needs to stay around
(and keep its EDHOC created OSCORE session / roll it over as described
in CoJP), or can it ever hand the device off to a JRC directly?
> > That'd mean that party V needs to serve both as a JRC and
> > DTLS/OSCORE data -- nothing I'd rule out, just something that
> > wouldn't have been apparent to me from the documents I've read
> > so far.
>
> Why would you need a DTLS context?
That was supposed to be an either-or; I don't suppose I'd have a device
that takes both. (Should actually have been cert/AS data). But having
the registar serve both JRC data and AS details sounds realistic to me.
> pick a "morning" in gather.town.
> I'm also remote. Maybe Wednesday before ANIMA.
Wednesday before at gather.town sounds great, looking forward to it!
Thx
c
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
