Subject: Re: [Rats] name of identity key

From: Guy Fedorkow <[email-masked]>
Date: Wed, 27 Nov 2019 15:45:56 +0000

Hi Michael,
  I'm not sure I'm seeing the problem...
  The identity key used for ZTP and the identity key used to prove that you're attesting the right box are most likely  the same, as they have the same role, that of authenticating a secure connection to a device.  And it's up to the device manufacturer and the system administrator as to whether they want to use an IDevID provided by the manufacturer or an LDevID provided by the sysadmin.  Obviously if you want drop-ship sZTP to work, it has to be the manufacturer's identity key, since the sysadmin won't get to touch the box before it's plugged in.  But there's nothing to say they couldn't pre-stage it and install a Local Device Identity key (and Local Attestation Key)
  In RIV, it's the Attestation key (Initial or Local) that must be unique, and that one has no purpose other than to sign the evidence collected in the TPM.

  Is there something I'm missing in your question below?

  Thanks
/guy

Juniper Business Use Only

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Monday, November 25, 2019 2:57 AM
To: Guy Fedorkow <[email-masked]>; [email-masked]
Cc: Jessica Fitzgerald-McKay <[email-masked]>; Henk Berkholz <[email-masked]>; Smith, Ned <[email-masked]>; William Bellingrath <[email-masked]>
Subject: Re: name of identity key

Guy Fedorkow <[email-masked]> wrote:
    > Hi Michael, I don't want to lose your question on the name of the
    > identity credential in RIV (or RATS)...  I think you were saying that
    > from a RATS point of view, you'd want to make the spec more generic
    > than a strict requirement for IEEE DevID.  Can you help me see why?  Is
    > there a more generic way of specifying the certificate that goes with
    > the identity key?  Thanks /guy

I (draft-ietf-anima-bootstrapping-keyinfra) am the user of an IDevID deployed in devices.  This is often located in a TPM.

If the TPM has to have a different IDevID key for signing Evidence, then I forsee a number of problems if the key has the same DN (serial-number, etc.) as the IDevID used for onboarding.

Is it signed by the same manufacturer CA as the onboarding IDevID?
(what names do I even use to distinguish these two keys?)

I can see manufacturers pushing back on having two identities.

One answer might be:
  MANUCA -> RIV_IDEVID(w/CA:TRUE) -> Onboarding_IDEVID

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Nov 2019 08:23:27 +0100

In some private thread, Guy said:

    > Smith, Ned <[email-masked]> wrote:
    >> Actually, it is expected that there will be many keys in a platform
    >> that could be used to obtain an IDevID credential. As discrete
    >> components (vendors of) are increasingly embedding root-of-trust / key
    >> gen capabilities. The challenge is more likely one of deciding *which*
    >> key should be regarded as the 'platform' key/identity used for
    >> onboarding.

    >> I agree that having multiple IDevID credentials could be confusing to
    >> "platform" owners but that should not imply that a platform can only
    >> have one key / credential. It is possible for a platform to have a
    >> delegate device that represents the platform remotely while other
    >> *devices* recognize the delegate as a platform local 'verifier'. This
    >> is the Open Compute Project's Cerberus architecture / use case. The EAT
    >> sub_mods claim and TEEP architecture seems to support this convention
    >> as well.

I said:
    mcr> I don't want to prevent multiple IDevID credentials, I want to name them
    mcr> consistently :-)

Ned Smith then said:
    nms> Good question. Part of the motivation to use "IDevID" terminology in
    nms> TCG is to agree on some industry standard naming. The
    nms> Cerberus/RIoT/DICE work introduced other terms "AliasID" and

Do you mean Kerberos, or are you referring to something else?
(There have been multiple crypto protocols with that name, alas)

    nms> "DeviceID" which are more confusing than helpful. DICE layering also
    nms> uses subscript notation to disambiguate which component/layer a key
    nms> belongs to, since it doesn't make sense to name things like naming
    nms> your kids given a layered architecture. Even so, TPM and DICE still
    nms> distinguish between key / credential types based on expected usage
    nms> (identity, attestation) and DICE also support embedded CA use cases
    nms> therefore acknowledges a third type (ECA). ECA keys can attest, but
    nms> do so by including Evidence in the certificate it
    nms> issues. Attestation keys can sign evidence (e.g. sign an EAT) while
    nms> identity keys sign an auth challenge. Auth challenges can support
    nms> implicit attestation - meaning claims ascribed to the Attester
    nms> arrive at the Verifier through an out-of-band channel and can
    nms> include claims signed by Endorsers. The identity (aka SubjectName /
    nms> SubjectAltName etc...) is used to link the identity to Tokens or
    nms> Endorsements containing Claims.

    nms> Maybe it makes sense to talk about how the keys are used rather than trying to name them?

Well, I think that having it named "the key we use for Onboarding" is the
same as saying, "Onboarding Key", right?

I don't know how the manufacturing process that involves a TPM with a TPM
attestation key works.  I just know that when doing BRSKI, that there were
issues with being confused between various TPM keys, and we originally wrote
text saying that the device Serial Number might be in weird places.  We later
ripped that text out, as time had changed things, and I'm worried that this
issue is not really dead.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-