Re: [Iotops] [Rats] 802.1AR device identity

Joining the conversation a little late...

I think that while the IdevID was originally intended to be a life-long
birth certificate of sorts, improving the standard to allow certificate
rotation could be useful.

Keys become easier/cheaper to guess over time. Guessing the key will
eventually be easier and less expensive than compromising the TPM which
protects it. And not all implementations are created equal. For instance:
https://en.m.wikipedia.org/wiki/ROCA_vulnerability . If the certificate
can't be rotated, then even after a firmware update, you're stuck with a
vulnerable private key in a patched TPM.

Protocols exist to allow an entity to rotate its own certificate. If it
were possible to safely do so, wouldn't the security posture of a device be
improved by having some cryptographic agility for the identity's method for
proof-of-possession? Rotation frequency recommendations can be related to
the amount of time required to guess the private key. What if the device
could rotate its own key in a shorter period of time than an adversary
could guess it?

If the device's name is universally unique and the certificate is
discoverable using that name, then the certificate then becomes just a
means of proving possession of the name.

 A manufacturer could support the rotation of IdevID certificates through
an integration between the CA and the discovery mechanism.

Certificate rotation like this could work with DANE for client identity.

On Mon, Mar 15, 2021, 06:30 Guy Fedorkow <gfedorkow=
40juniper.net@dmarc.ietf.org> wrote:

> I agree with Michael.  The IDevID in my point of view is as permanent as
> the serial number on the box or the VIN on your car.
> I think DevID could have privacy implications in some applications, so
> within TCG there have been proposals to download the IDevID at the
> customer's discretion, but in that case, it would have to be linked to
> TPM's EK (another immutable key), so there's still only one possible IDevID
> ever for a box.
>   As noted, LDevIDs can be made and destroyed at will.
> /guy
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Saturday, March 13, 2021 8:35 PM
> To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>; rats@ietf.org;
> iotops@ietf.org
> Subject: Re: [Rats] [Iotops] 802.1AR device identity
>
> [External Email. Be cautious of content]
>
>
> Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:
>     > Yeah, this is an issue that comes up from time to time.  How
>     > “immutable” should that iDevID be?
>
> I take the approach that the IDevID that was shipped from the factory can
> not be replaced without a device recall.
>
> (It could be that there are modes where another IDevID can be installed,
> but the original would not be removed.  Whether this is an LDevID or IDevID
> is open to intepretation)
>
>     > 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?
>
> Then, the device is broken.
> I think you would certainly agree that this can be the only answer if the
> software signing key is compromised, right?
>
>     > Can one recover with an update?
>     > What if there are attributes in the cert that I want to
>     > dink and share with the deployment?
>
> Please define "dink" for me.  I know of only one definition from the
> school yard.
> Does this mean remove? replace?
>
>     > 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.
>
> Can you give me an example of one of these attributes?
> This sounds like the FIDO situation, from section 6.3 of (my) the usecase
> document:
>
>    According to [fidotechnote] FIDO uses attestation to make claims
>    about the kind of device which is be used to enroll.  Keypairs are
>    generated on a per-device _model_ basis, with a certificate having a
>    trust chain that leads back to a well-known root certificate.  It is
>    expected that as many as 100,000 devices in a production run would
>    have the same public and private key pair.  One assumes that this is
>    stored in a tamper-proof TPM so it is relatively difficult to get
>    this key out.  The use of this key attests to the the device type,
>    and the kind of protections for keys that the relying party may
>    assume, not to the identity of the end user.
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
> --
> Iotops mailing list
> Iotops@ietf.org
> https://www.ietf.org/mailman/listinfo/iotops
>