Re: [Anima] [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)

On Mon, May 01, 2023 at 12:09:03PM +0200, Christian Amsüss wrote:
> Hi Michael,
> (CC'ing ACE list because what I think will be the larger part of the
> thread is hopefully relevant)
> 
> >     > there a generalization of the IEEE identifiers that also makes
> >     > sense for constrained but more general-purpose-oriented devices,
> >     > for which the ANIMA products can still be used?
> > 
> > Yes, I agree: replacing the IDevID makes a lot of sense if the control over
> > the software-update trust anchor changes.
> 
> When talking about such processes, can we still use the IDevID term
> (even though an IDevID is "stored in a way that protects it from
> modification"), or is the use of the term OK because we're not modifying
> but replacing it, or do we need to use a more general term, or do we not
> care?

I don't have much of an opinion on this at the moment but could probably be
convinced that using IDevID is ok.

> >     > * Is there any document that describes (or has an example of) how ANIMA
> >     > onboarding interacts with ACE's AS? My current -- maybe naive --
> >     > assumption is that a voucher in this countext would contain a
> >     > pinned-domain-pubk which is the public key the AS will use to sign ACE
> >     > tokens, and the est-domain would indicate the AS URI, but with the
> >     > pinned-domain-pubk being described in TLS terms (whereas an ACE AS
> >     > uses COSE keys), this may be skipping a step.
> > 
> > Yeah, that makes sense to me.
> > I think that ace-ake-authz intended to describe things in terms of ACE.
> 
> In the current document, the only ACE reference is in an older version's
> asssigned group. And I think that's good, for using-ANIMA-with-ACE is
> orthogonal to doing-ANIMA-over-EDHOC.
> 
> It just may mean we need another document, unless we cram things
> together in one (which, apart from any good-practice discussions, is
> hard to convey to the initial reader, who'll need to understand that
> they can use either part w/o the other).
> 
> > The AS == Registrar, I think.
> > Or, perhaps the AS uses a key that the local CA (mediated by the Registrar as
> > a trust anchor, /cacerts) has blessed in some way.  How that works is TBD.
> 
> So, what'd we need?
> 
> * Does pinned-domain-pubk work also for COSE keys as used for signed
>   CWTs? (If so, is there a key identifier to go with it?)

COSE key identifiers ('kid') are not exactly what you would typically call
a "key identifier" in unconstrained spaces.  In particular, they are just
for optimizing lookup over trial decryption, and you have to associate your
authorization data with the full key entry, not with the 'kid'.  COSE 'kid'
are not globally unique, and you might run into a lot of places using kid
of '0' and relying on context to infer which one is meant.

> * Some ACE profiles (eg. ACE-OSCORE, RFC9203) are typically used with a
>   symmetric key shared between AS and RS (and that may be the only key
>   material). Is it fine from an ANIMA PoV to only have such key
>   material? (When such a key is used, it obviously needs to be
>   encrypted; at least some methods of ANIMA, eg. EST, can do that).

It makes me nervous, but just because of the normal shared-key threat
model.  (It is the group-shared threat model since you may have more than
one instance of AS for ANIMA purposes, but it's probably okay to have "AS1
attacks AS2" as out of scope since the AS is assumed to be trusted.)

> * (At least) When AS is used with asymmetric tokens, the RS needs to be
>   told its audience identifier; I'd guess that'd be a new leaf.
> * Once onboarding onto ACE has completed, all the device's identity
>   would be ACE (except for the IDevID that's left in place for a factory
>   reset). Is that fine with an ANIMA setup?

Without the full context of the preceding thread, it's hard to be sure I
understand properly, but I think yes, ANIMA expects LDevID for onboarded
devices, so if you're building ACP using ACE crypto it should be fine.

-Ben

>   I figure that the alternative is to have a dedicated registrar that
>   then hands out certificates to the AS that allow the AS to
>   (temporarily) speak for the CA, but this probably just shifts the
>   questions above down to how those points above would be expressed in a
>   certificate. Skipping that middle step would allow implementing
>   devices that have ANIMA-style onboarding (cBRSKI with ake-authz,
>   maybe), but (eg. using ACE-OSCORE) don't ever need asymmetric
>   operations at runtime.
> 
> Or do I get the boundaries all wrong, and an ACE device would rather
> express the concepts of a voucher in a CWT? (But ANIMA already did all
> the hard work, and given such a device likely needs some CORECONF and
> thus YANG anyway, reducing extra weight).
> 
> If not: Shall we just start a small and sleek document that registers
> some values, and evolve it with some help from Mr. Cunningham?
> 
> BR
> Christian
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>   -- Bene Gesserit axiom

> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace