Re: [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Benjamin Kaduk wrote:
> 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.
I wanted to wait for other opinions.
I begin to wonder if we should do our own 802.1AR. The document is 90%
references to IETF RFCs, many of them old or vague. Another half is a
pseudo-API, which nobody uses.
I don't really understand the concerns that Ben and Christian have raised.
>> * 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.
pinned-domain-pubk pins a specific public key, in the case of "pubk", but
*value* the COSE kid is not really involved *at all*
pinned-domain-pubk-sha256 pins by SHA256 hash, but for 256-bit ECDSA keys, that
might
not be much of an actual savings.
>> * 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.)
symmetric keys could be used with constrained vouchers, from the MASA to the
Pledge. They couldn't be used in the other direction, where the Registrar,
having no relationship with the Pledge, needs to validate the IDevID.
I wouldn't want to do this though, and I see no advantage, only extreme risk.
>> * (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.
I see no reason the (provisional)[D}TLS connection between Pledge and Registrar
can't be used to initialize a symmetric key for OSCORE. Apply a suitable key
exporter.
The Registrar becomes (or communicates with) the AS.
If you are using EDHOC, then a suitable key was already created by EDHOC.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [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
[Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
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? > > * 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?) * 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). * (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? 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 signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
