Re: [Rats] 802.1AR device identity

["Smith, Ned" <[e-mail]>]

See inline nms>.
From: Eliot Lear <[e-mail]>
Date: Thursday, March 11, 2021 at 1:54 AM
To: "Smith, Ned" <[e-mail]>
Cc: Guy Fedorkow <gfedorkow=[e-mail]>, Laurence Lundblade <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Rats] 802.1AR device identity

Thanks, Ned.  My point really was to talk about the impetus for making an iDevID change.  There’s one more obvious one that I didn’t mention.  If you want to make use of tools like ANIMA BRSKI / RFC 8366 to transition from iDevID -> lDevID and you have a supply chain to manage, monkeying with what is called the iDevID in those transactions might help.  A better approach might be to integrate FDO (ledger based transfers).
Nms> I’m not familiar with the FDO acronym (First Device Onboard?) or how the 802.1AR use case context for iDevID/LDevID relates to ledger based transfers. This feels like a deep topic that maybe should be a talk or slides that the RATS WG understands better?

Eliot



On 10 Mar 2021, at 22:09, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

Regarding “a standard protected TLV list  that deployments could receive through a standard interface.  These are attestations of a form”

The TLV list is a statement made by a manufacturer about the recoverability of device / device ID. We might call them Vendor Assertions for now.

The RATS Arch describes Endorsements which are “statements about the integrity of the signing capability”. It isn’t clear to me that mutability/immutability of an IdevID key is covered under the definition for Endorsements. The architecture didn’t define terminology for Vendor Assertions that don’t fit the definition for Endorsements or Reference Values.

Bringing this back to the original thread. The vendor is likely the most authoritative entity to make assertions about the mutability/immutability properties of the IDevID (key). If a standard tries to codify it in a specification it tends to suffer from ambiguity or it defines an implementation. (both have compliance challenges)

Hence, a reasonable way forward is for vendors to make claims about IDevID mutability properties. Providing the community with a vocabulary for making such claims is probably the best facilitation a standard could do.

From: Eliot Lear <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 10, 2021 at 12:27 PM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: Guy Fedorkow <gfedorkow=[e-mail]<mailto:gfedorkow=[e-mail]>>, Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] 802.1AR device identity

Yeah, this is an issue that comes up from time to time.  How “immutable” should that iDevID be?  I’ve had this thought in two different contexts:
•         What if the signature algorithm, CA, or private key used to protect the iDevID has been compromised?  Can one recover with an update?
•         What if there are attributes in the cert that I want to dink and share with the deployment?

I’d like to take that latter case off the table, but then we need to seriously think about RATS or SUIT providing a standard protected TLV list  that deployments could receive through a standard interface.  These are attestations of a form, but they’re not really measurements, as has been previously discussed here.

Eliot




On 10 Mar 2021, at 20:02, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

The 802.1AR spec doesn’t AFAIK require IDevIDs that can’t change. But not curtain. Is says things like:
A
device’s DevID module stores each of its DevID secrets securely and supports signing operations that prove
possession of the secret (and thus that the device is the subject of the associated DevID certificate), while
ensuring that the secret remains confidential so the device cannot be impersonated by others.
An Initial Device Identifier (IDevID) provided by a device’s supplier can be supplemented by one or more
Local Device Identifiers (LDevIDs), each using an existing or a freshly generated secret, facilitating
enrollment (provisioning of authentication and authorization credentials to authenticated devices) by a local
network administrator.

A device with DevID capability incorporates a globally unique manufacturer provided Initial Device
Identifier (IDevID), stored in a way that protects it from modification.

LDevIDs can also be used as the sole identifier (by disabling the IDevID) to
assure the privacy of the user of a DevID and the equipment in which it is installed.

-Ned
From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Guy Fedorkow <gfedorkow=[e-mail]<mailto:gfedorkow=[e-mail]>>
Date: Wednesday, March 10, 2021 at 7:59 AM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Rats] 802.1AR device identity

Hi Laurence,
  We talked about device identity on the RATS call today.
  For RIV, we’re relying on this IEEE spec:
https://1.ieee802.org/security/802-1ar/
  That spec defines Initial and Local Device Identities.  Initial DevID is set by the manufacturer and can’t be changed or replaced, while the Local DevID can be set and erased by the owner of the gear.
  The spec doesn’t address deciding which identity to use for any specific application, but the intent clearly is to allow the owner to use the manufacturer-supplied identity to install an owner-specific identity in a device, and erase the owner-specific identity leaving the manufacturer identity in place when the device is decommissioned.

  Many different specs must have examined this problem, but of course it never hurts to re-use some of these ideas where possible.
  Thx
/guy



Juniper Business Use Only
_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats