Subject: Re: [Rats] name of identity key

From: "Smith, Ned" <[email-masked]>
Date: Mon, 2 Dec 2019 19:59:55 +0000

On 11/27/19, 11:37 PM, "Michael Richardson" <[email-masked]> wrote:

        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?
[nms] Right. I thought you were looking for names such as "IDevID". It could be the IDevID is the onboarding key or that the attestation key is the onboarding key. Somehow the onboarding protocol selects which key is used if both are available.
    
    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.
[nms] There is still a possibility for a bootstrapping sequence post factory shipment where "the onboarding key" doesn't yet exist. Therefore, pre-onboarding is required to provision the onboarding key. This may be what you describe as "the device Serial Number might be in weird places".

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Dec 2019 15:15:15 -0500

Smith, Ned <[email-masked]> wrote:
    nms> Maybe it makes sense to talk about how the keys are used rather than trying to name them?

    > same as saying, "Onboarding Key", right?

    nms> Right. I thought you were looking for names such as "IDevID". It
    nms> could be the IDevID is the onboarding key or that the attestation
    nms> key is the onboarding key. Somehow the onboarding protocol selects
    nms> which key is used if both are available.

Well, the issue I have, is that as an author of an onboarding protocol, there
is no "somehow", just confusion at this point.

I think that we really need to be a bit clearer here.

    > issue is not really dead.

    nms> There is still a possibility for a bootstrapping sequence post
    nms> factory shipment where "the onboarding key" doesn't yet
    nms> exist. Therefore, pre-onboarding is required to provision the
    nms> onboarding key. This may be what you describe as "the device Serial
    nms> Number might be in weird places".

yes, that's certainly an additional complication.

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

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 2 Dec 2019 21:27:48 +0000

Hi Michael,
  The reason I've stuck with DevID is that the spec says pretty clearly where the serial number needed for on-boarding is to be put.  That doesn't mean that the text couldn't be relaxed in some way to allow keys that identify a box for onboarding using other formats than 802.1AR.  But it might be tough to get multiple methods to be interoperable.
  The confusion you might be thinking of is that a key in the TPM is identified by a handle, not a friendly name.  So when someone wants a DevID key that desire must be translated to a TPM handle.
  I think those have been spec'd now by TCG, at least for TPM2.  But for an embedded system, I think the question is moot; the manufacturer is going to put the key into the TPM in a way that they know how to find it when their own onboarding software wants to use it.
  If you want software from Vendor A to run on a platform (with identity keys) supplied by Vendor B, (perhaps as in the PC world) then the handles need to be spec'd.  But that seems more like a TCG problem.

  One reason (IMHO) onboarding specs should ask for "the DevID key", but not for the IDevID or LDevID or for a specific handle, is that the administrator could well pre-provision the device to use a variety of different keys, all with DevID format, but with different security properties known only to the admin...

  Just my guess...  I see Max on the cc; he's the expert at this!
/guy

Juniper Business Use Only