Re: [Anima] [Ace] Proposing document draft-amsuess-ace-brski-ace-00

[Michael Richardson <[e-mail]>]

Christian =?iso-8859-1?Q?Ams=FCss?= <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide