Christian =?iso-8859-1?Q?Ams=FCss?= <christ...@amsuess.com> wrote:
> 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
There are some things which quite reasonably could go into the
PVR/RVR+voucher. One example is remote attestation: the pledge is the
Attester, the Registrar is the RP, and the MASA is the Verifier. This makes
sense because the manufacturer has all the golden values (the endorsements).
> 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.
Yes.
> 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
Agreed: it's not BRSKI, just ... start with a secure channel.
> 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.
PRM has some innovation that allows the CSR to be created at the same time as
the voucher, and then some cross-checking.
> 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?
If the OSCORE session can be moved, then I think yes, it could hand it off.
In particular on 802.15.4 (6tisch/CoJP) networks, then network rekeys have to
be handled carefully, and can take some time to get done.
> 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.
Ah, yes. Agreed. The registrar has to cope with it all.
>> 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!
Table "A" for Anima.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
