Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2019 13:31:36 -0400

Mendelson, Tsippy <[email-masked]> wrote:
    > Sending again to wider ANIMA audience – as I received no response.

I don't think that I saw it before.
But, you posted to the list, which is the right place.
(You could have opened a github issue)

    > We have identified a reference to an old spec in BRSKI draft
    > draft-ietf-anima-bootstrapping-keyinfra-22.

    > The draft refers to:

    > [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
    > <http://standards.ieee.org/findstds/
    > standard/802.1AR-2009.html>.

    > However there is a later spec:
    > https://standards.ieee.org/standard/802_1AR-2018.html

    > The specific quote from 802.1AR-2009 that we would like to ask about is in
    > section 2.3.1 “Identification of the Pledge”:

So, I have no idea if 802_1AR-2018 is better or not, as I don't have a copy
of it.  I tried last week to get a copy of it via the getieee system,
but I failed.  I had previously been able to download the 2009 version.

    > The following fields are defined in [IDevID] and [RFC5280]:

    >    o  The subject field's DN encoding MUST include the "serialNumber"
    >       attribute with the device's unique serial number.  (from [IDevID]
    >       section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
    >       attributes)

    > In 802_1AR-2018 we could not find that the “serialNumber” attribute
    > MUST be included rather we found SHOULD:

Yes, but we are saying that *WE* require it.  

    > Here it says: An IDevID certificate subject field shall be non-null and
    > should include a unique device serial number.

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

---

From: "Mendelson, Tsippy" <[email-masked]>
Date: Tue, 23 Jul 2019 09:26:54 +0000

Hi,

Sending again to wider ANIMA audience - as I received no response.

Thanks,
Tsippy

From: Mendelson, Tsippy
Sent: Sunday, June 30, 2019 11:18
To: [email-masked]
Cc: Ruan, Xiaoyu <[email-masked]>; Jayanna, Prabhu <[email-masked]>; Mendelson, Tsippy <[email-masked]>
Subject: Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009

Hello,

We have identified a reference to an old spec in BRSKI draft draft-ietf-anima-bootstrapping-keyinfra-22.

The draft refers to:

[IDevID]   "IEEE 802.1AR Secure Device Identifier", December 2009,
              <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.
However there is a later spec: https://standards.ieee.org/standard/802_1AR-2018.html

The specific quote from 802.1AR-2009 that we would like to ask about is in section 2.3.1 "Identification of the Pledge":

      attributes)

In 802_1AR-2018 we could not find that the "serialNumber" attribute MUST be included rather we found SHOULD:
Here it says: An IDevID certificate subject field shall be non-null and should include a unique device serial number.

We would be happy for a clarification.

Thanks,
Tsippy

Tsippy Mendelson,
Manageability Chief Architect,
IP Technologies Group, SecIP - CSE FW Architect
Intel Israel Design Center
Phone: +972-2-589-2468
Cellular: +972-54-7885061

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jul 2019 23:07:59 +0200

Ideally i would like to negotiate you into liking and accepting the text
as it stands, and if then - if you are interested - to help write a small
followup document amending the solution space to other pledge IDevID
formats (e.g.: without these easy identifiers). The reason for me saying this
is that the authors and i think the industry well understands the
workflows in which these device identifiers are also communicated via
sales integration, appear on printed labels and all the like. So we feel
safe that we have a rock solid solution when we do have this identifier
in the IDevID.

>From what i understand (and please correct me if you are coming from a
different angle), you may be able to reduce cost in manufacturing of
low-cost and/or constrained device by not having to have IDevID securely
installed with such serialNum, but instead just having a
self-signed certificate or maybe even only a self-generated key-pair -
and then for example just using a simple registration process at the
manufacturer to remembrer the public key pair there - manufacturer
doesn't need to create any other device tracking space other than the
public key. Not good for humans, but good enough for automated
mechanisms. This is i think what we discussed during a BRSKI/ACME side-meeting
last week (see also notes sent by Owen and I).

I think it is perfectly feasible to adopt BRSKI to support these type
of environments, probably with only few changes, but it would be a lot
easier to conclude on HOW to do it through the aforementioned separate
followup document. 

For example, i am not sure if TLS can authenticate just with public key
pair, or not (if not we would always ask to create self-signed
certificate), then we might need to amend the voucher format (not sure),
and ultimately, there may need to be some form of standardized sales
integration signaling so that the owner learns about the public keys of
the devices he bought. E.g.: something like this.

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 18:23:37 -0400

Toerless Eckert <[email-masked]> wrote:
    > low-cost and/or constrained device by not having to have IDevID

I didn't get that all from the original poster.
I think you are jumping to a conclusion that is not supported by text here.

They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a SHOULD.
And, that's not the point at all, really.
IF you want to do BRSKI, then you MUST include a serialNumber in the DN.

802.1AR-2009, has section 7.2.8:

7.2.8 subject
      The DevID subject field shall uniquely identify the device associated
      with the particular DevID credential within the issuer’s domain of
      significance. The formatting of this field shall contain a unique X.500
      Distinguished Name (DN). This may include the unique device serial
      number assigned by the manufacturer or any other suitable unique DN
      value that the issuer prefers. In the case of a third-party CA or a
      standards certification agency, this can contain the manufacturer’s
      identity information.

      The subject field’s DN encoding should include
      the “serialNumber” attribute with the device’s unique serial number.

Note lack of RFC2119 language (or a reference to it).

So if the 2018 has "SHOULD" here, then that's a strengthing of the language,
not a weaking.   The first paragraph does have weasel words "any other
suitable unique DN", but I really think that a serialNumber DN attribute
(as opposed to the serialNumber certificate attribute) is needed for BRSKI
to interoperate well.

If someone has a 10 million devices in the field which can be field upgraded
to run BRSKI (while still in a not-yet enrolled state in a box), then let's
talk about this.  Maybe it's actually 10,000,000 TPM devices with IDevIDs
already generated, but no serialNumber in it.  Getting the JRC code right
to do other things can be a pain, but it can be done.

-- 
]               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: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 01:11:36 +0200

> I think you are jumping to a conclusion that is not supported by text here.

Yes, i was elaborating about why one would want an IDevID without the
serialNumber and what would need to happen to support that. But i also
said this should be out of scope for the current BRSKI document.

> IF you want to do BRSKI, then you MUST include a serialNumber in the DN.

Agreed.

>       with the particular DevID credential within the issuer???s domain of
>       standards certification agency, this can contain the manufacturer???s
>       identity information.
> 
>       The subject field???s DN encoding should include
>       the ???serialNumber??? attribute with the device???s unique serial number.
> 
> not a weaking.
> The first paragraph does have weasel words "any other
> suitable unique DN", but 

Ok, i currently can't access the IEEE standards, so i can not compare
myself. My reading of the OP was that it was a weakening.

> I really think that a serialNumber DN attribute

Agreed.

> to do other things can be a pain, but it can be done.

Right, this was my question to the OP as well. I was guessing its more
about minimizing cost for future built 10 million devices. Today you
would need to burn-in during manufacturing identity elements such as
specifically the serialNumber, so you need to devise a protected burn-in
process. If you just et the device generate a public key pair and you
simply capture the public key during manufacturing, maybe that is a
significant simplification when you talk 10 million devices. Just
guessing. In any case, serialNumber is a lot more useful when humans are
involved, but they may become less relevant when everything is
automated.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jul 2019 14:18:08 +1200

Let's be clear in the BRSKI text that our standard makes this a MUST
*even if* it is not mandatory in the IEEE standard. Of course we can do
that (and not including the serial number seems very sloppy), but we
should be explicit that our requirement is stronger than the IEEE.

Maybe it means that some light bulbs cannot be BRSKI pledges. I don't
think we care, because our model is that nodes containing management
smarts such as an ASA need to join the ACP, but managed nodes themselves
do not.

Regards
   Brian

---

From: "Mendelson, Tsippy" <[email-masked]>
Date: Wed, 31 Jul 2019 11:11:54 +0000

Hi,

My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE 802.1AR recommends this but BRSKI enforces this - makes this a MUST.

But behind the scenes this question was coming from considerations related to complexity that this adds to the manufacturing flow when required to provision every device with a certificate that includes its Serial Number :-).
This creates usability and security issues on the manufacturing line.

We are devising a solution for this manufacturing problem by using an embedded CA in a RoT / Hardware TEE in the platform for this purpose - but there are concerns with this implementation as well. Therefore I wanted to clarify this requirement. (Although I agree that it makes perfect sense).

Regarding: 
" If you just let the device generate a public key pair and you simply capture the public key during manufacturing, maybe that is a significant simplification when you talk 10 million devices"

This is a very interesting remark as we are actually thinking of a solution where the Platform Identifier in the Ownership Voucher (that the OEM uploads to their inventory from the manufacturing line) would include 2 components:
1. The Serial Number assigned by the OEM to the platform - this could be a Service Tag or perhaps a hash of all serial numbers of devices included in the platform - or something else the OEM chooses - but as it can be a hash we allocate 32 bytes for it.

2. A hash of the Public Key of a key pair that is generated by the Platform RoT for identity / TEE - this would be the public key in the IDevID certificate. When using an embedded CA (in the RoT hardware) to issue IDevID certificates, this would be the Public Key in the certificate of the embedded CA that the IDevID Certificate is rooted to.

Altogether 64 bytes.

Using an embedded CA enables revoking and replacing the key and certificate used for identity attestation easily, after a FW update that increases the security version number. 

Regards,
Tsippy

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, July 31, 2019 05:18
To: Toerless Eckert <[email-masked]>; Michael Richardson <[email-masked]>
Cc: Jayanna, Prabhu <[email-masked]>; Mendelson, Tsippy <[email-masked]>; [email-masked]; Ruan, Xiaoyu <[email-masked]>
Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009

Let's be clear in the BRSKI text that our standard makes this a MUST *even if* it is not mandatory in the IEEE standard. Of course we can do that (and not including the serial number seems very sloppy), but we should be explicit that our requirement is stronger than the IEEE.

Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think we care, because our model is that nodes containing management smarts such as an ASA need to join the ACP, but managed nodes themselves do not.

Regards
   Brian

On 31-Jul-19 11:11, Toerless Eckert wrote:
>> So if the 2018 has "SHOULD" here, then that's a strengthing of the 
>> language, not a weaking.
>> The first paragraph does have weasel words "any other suitable unique 
>> DN", but
> 
>> I really think that a serialNumber DN attribute (as opposed to the 
>> serialNumber certificate attribute) is needed for BRSKI to 
>> interoperate well.
> 
> Agreed.
> 
>> If someone has a 10 million devices in the field which can be field 
>> upgraded to run BRSKI (while still in a not-yet enrolled state in a 
>> box), then let's talk about this.  Maybe it's actually 10,000,000 TPM 
>> devices with IDevIDs already generated, but no serialNumber in it.  
>> Getting the JRC code right to do other things can be a pain, but it can be done.
> 
> specifically the serialNumber, so you need to devise a protected 
> burn-in process. If you just et the device generate a public key pair 
> and you simply capture the public key during manufacturing, maybe that 
> is a significant simplification when you talk 10 million devices. Just 
> guessing. In any case, serialNumber is a lot more useful when humans 
> are involved, but they may become less relevant when everything is 
> automated.
> 
> Cheers
>     Toerless
> 
>> --

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 19:59:28 +0200

> My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE 802.1AR recommends this but BRSKI enforce…

Ack.

> This creates usability and security issues on the manufacturing line.

Thanks. Thats what i was guessing im my reply.

> 1. The Serial Number assigned by the OEM to the platform - this could be a Service Tag or perhaps a hash of all serial numbers of devices included in the platform - or something else the OEM choose…

I can not quite imagine what you are calling a "platform". Could give
give one or two examples ?

> 2. A hash of the Public Key of a key pair that is generated by the Platform RoT for identity / TEE - this would be the public key in the IDevID certificate. When using an embedded CA (in the RoT ha…

RoT ? TEE ?

> Using an embedded CA enables revoking and replacing the key and certificate used for identity attestation easily, after a FW update that increases the security version number. 

See above, i can't quite imagine the solution and its intended
workflows, but it sounds as if oyu wanted to figure out a variation of BRSKI/MASA
to actually enroll IDevID instead of LDevID...

It seems the main problem you want to solve is how client devices should
identify themselves to the MASA (or however else you want to call the
manufacturer or OEM backend) without a classical certificate IDevID and
without upfront tracking of any other form of serial IDs by the
manufacturer ? 

I am not sure about all useful crypto mechanisms to solve this, but
obviously you could have something like a platform-id in a TPM chip
thats the same for all devices for the platform, and the only operation
permitted is some proof of knowledge of that shared secret by the MASA
(e.g.: hash(nonce+secret) or the like).

Of course if you can born something unique into the devices during
manufacturing, you could do something like very_long_serial=random(seed), seed
becomes the platform identifier, and device identifies by sending
masa-private-key encrypted serial to MASA. Or something like that.

Crypto folks would likely have better suggestions ;-)

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 20:02:24 +0200

> should be explicit that our requirement is stronger than the IEEE.

Right.

> smarts such as an ASA need to join the ACP, but managed nodes themselves

GRASP, BRSKI, ACP are meant to also be independently reuseable,
not every device using  eithrer of them needs the full ANI.

My argument is rather that BRSKI as defined (mandating serialNumber) is
well representing whats used/required in well known type of devices and
that followon work can (IMHO) easily expand it for additional
constrained device solutions.

Cheers
    Toerless

-- 
---
[email-masked]