Re: [Ace] [Anima] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Russ Housley wrote: >>> Is that identity now an LDevID (even though it has a completely >>> different shape than the IDevID), or is a certificate based LDevID >>> still created as part of the process, or can the device happily >>> complete the ANIMA processes without an LDevID? >> >> I wouldn't call it an LDevID. >> You don't need to do EST and ask for an LDevID. > I do not see this being prohibited. It would require: > - CA recognizes the trust anchor associated with the IDevID, > - CA can issue the LDevID, > - Client can authenticate the EST server based on something configured at the factory. I think you are speaking at cross-purposes. Christian wants to know if ANIMA/BRSKI can "complete" without asking for an LDevID. (yes) Alternatively, if some OSCORE context with a symmetric key can count. You have latched onto getting an LDevID without using EST. Agreed: you don't need EST, you can use any other enrollment protocol you want, and the BRSKI-AE document is about using CMP, for instance. -- 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] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
> On May 26, 2023, at 1:18 PM, Michael Richardson wrote: > >> Is that identity now an LDevID (even though it has a completely >> different shape than the IDevID), or is a certificate based LDevID >> still created as part of the process, or can the device happily >> complete the ANIMA processes without an LDevID? > > I wouldn't call it an LDevID. > You don't need to do EST and ask for an LDevID. I do not see this being prohibited. It would require: - CA recognizes the trust anchor associated with the IDevID, - CA can issue the LDevID, - Client can authenticate the EST server based on something configured at the factory. Russ signature.asc Description: Message signed with OpenPGP ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Christian Amsüss wrote: > Yes, that's the way I'd hope they could be used. For example, if a > device were onboarded into an ACE domain with three AS that's using the > ACE-OSCORE profile with the devices, they'd obtain three symmetric keys > with a key identifier h'00', h'01' and h'02' respectively, so that when > the device receives a token, it'll try the one key and not any. No, that part does not make sense. The voucher is authenticating the (public key) identity of the Registrar (aka AS) to the Pledge. If you want to do further key derivations, then you'd have to some PRFs and/or DH (for PFS). >> It makes me nervous, but just because of the normal shared-key threat >> model. > That'd make me nervous too, but see above -- with shared keys, it'd be > at least my expectation that there's a key for every AS. > ... which also means that there'd be a need to update data that > originally came in on an ANIMA voucher, and I don't know whether that's > better done through ANIMA again or through ACE. Has to be done through OSCORE/EDHOC. > The identity a device (after onboarding onto an AS through ANIMA means) > will have as its operational identity the (AS-URI, audience) tuple, > confirmed by the shared key(s) it has obtained. It would not receive > any certificate, and not use the IDevID unless onboarding is started > anew. Yes, but the shared key comes from the EDHOC operation. > Is that identity now an LDevID (even though it has a completely > different shape than the IDevID), or is a certificate based LDevID > still created as part of the process, or can the device happily > complete the ANIMA processes without an LDevID? I wouldn't call it an LDevID. You don't need to do EST and ask for an LDevID. -- 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] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Hi Ben,
On Mon, May 01, 2023 at 10:41:32PM -0700, Benjamin Kaduk wrote:
> > * 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.
Yes, that's the way I'd hope they could be used. For example, if a
device were onboarded into an ACE domain with three AS that's using the
ACE-OSCORE profile with the devices, they'd obtain three symmetric keys
with a key identifier h'00', h'01' and h'02' respectively, so that when
the device receives a token, it'll try the one key and not any.
> It makes me nervous, but just because of the normal shared-key threat
> model.
That'd make me nervous too, but see above -- with shared keys, it'd be
at least my expectation that there's a key for every AS.
... which also means that there'd be a need to update data that
originally came in on an ANIMA voucher, and I don't know whether that's
better done through ANIMA again or through ACE.
> > * 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'm not sure the thread context will help, but I can rephrase the
question now (assuming it's using ACE-OSCORE for simplicity):
The identity a device (after onboarding onto an AS through ANIMA means)
will have as its operational identity the (AS-URI, audience) tuple,
confirmed by the shared key(s) it has obtained. It would not receive any
certificate, and not use the IDevID unless onboarding is started anew.
Is that identity now an LDevID (even though it has a completely
different shape than the IDevID), or is a certificate based LDevID still
created as part of the process, or can the device happily complete the
ANIMA processes without an LDevID?
Thanks
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
