Re: [Rats] Supply Chain Attestation (was Re: 3 Use cases)

"Smith, Ned" <ned.smith@intel.com> Mon, 07 October 2019 18:33 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616D21200E9 for <rats@ietfa.amsl.com>; Mon, 7 Oct 2019 11:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRw3zteaa9sP for <rats@ietfa.amsl.com>; Mon, 7 Oct 2019 11:33:55 -0700 (PDT)
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB561200F5 for <rats@ietf.org>; Mon, 7 Oct 2019 11:33:55 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2019 11:33:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.67,269,1566889200"; d="scan'208,217";a="344810319"
Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga004.jf.intel.com with ESMTP; 07 Oct 2019 11:33:54 -0700
Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 7 Oct 2019 11:33:54 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.122]) by ORSMSX156.amr.corp.intel.com ([169.254.8.15]) with mapi id 14.03.0439.000; Mon, 7 Oct 2019 11:33:53 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Michael Richardson <mcr@sandelman.ca>
CC: "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Supply Chain Attestation (was Re: 3 Use cases)
Thread-Index: AQHVfSmKYMgPnUiotk21jzEyn2HuJKdPgTUA
Date: Mon, 07 Oct 2019 18:33:52 +0000
Message-ID: <29358179-382F-4660-B012-0327274343AE@intel.com>
References: <HE1PR0701MB2267E23FFE8FF91F5DAC6FD58FCF0@HE1PR0701MB2267.eurprd07.prod.outlook.com> <1882.1570451614@dooku.sandelman.ca> <CAHbuEH6=O7zwyKD3-NAG=128dFtd7BVZ0QKEPTUcCLmJeenEGg@mail.gmail.com>
In-Reply-To: <CAHbuEH6=O7zwyKD3-NAG=128dFtd7BVZ0QKEPTUcCLmJeenEGg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-originating-ip: [10.255.94.100]
Content-Type: multipart/alternative; boundary="_000_29358179382F4660B0120327274343AEintelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qCDnZDXkHVrOUOp0bOtCYvcWRmI>
Subject: Re: [Rats] Supply Chain Attestation (was Re: 3 Use cases)
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 18:33:59 -0000

See inline [nms]

On 10/7/19, 9:09 AM, "RATS on behalf of Kathleen Moriarty" <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org> on behalf of kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>> wrote:



On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <mcr@sandelman.ca<mailto:mcr@sandelman.ca>> wrote:

{sorry for the time-warp email, responding to you was important to me}

Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com<mailto:ian.oliver@nokia-bell-labs.com>> wrote:
    > Supply Chain Attestation

    > A device is shipped from an OEM via some delivery mechanism and is
    > received by a customer. The customer requires assurance that the device
    > has not been tampered with. This differs from the usual attestation
    > scenarios between a device/element and attestation server/verifier in
    > that this requires knowledge of the partial or full configuration of
    > the device being shipped and configured before introduction into the
    > customer's environment.

    > This use case then requires interaction between two attestation points
    > to ensure that the integrity of the device has not changed with regards
    > to a) the device, b) the original [possibly partial] configuration, c)
    > the device manufacturer's measurements and d) the receiver - customer's
    > - measurements..

There are quite a number of entities that are looking for the attestation
that involves not the device, but the configuration as well.

I think that this fits into 5.1: Device Capabilities/Firmware Attestion.
I think that the need for sensitivity to configuration is generally something
that the TCG RIV work:
     The TCG RIV Reference Document addresses the problem of knowing if a networking device
     should be part of a network, if it belongs to the operator, and if it is RUNNING
     APPROPRIATE SOFTWARE.

Guy has posted their document as draft-fedorkow-rats-network-device-attestation, which
makes it much more accessible if you aren't a TCG member (I'm not).

You allude (but are perhaps not explicit enough) in your second paragraph
that there is some interaction between different attesters to generate the
required set of claims needed.  Do you imagine that this is done via multiple
signatures on a claim set, or some kind of nested claim structure, or perhaps
use of passport claim for one part, followed by a background-check style
process for the second. (Dave Thaler's slides included that option too)

I would guess a nested claim structure so that you could 'wrap'  a claim set and signature of code that is relied upon.
[nms] In a decomposition of a device there can be components that are ‘attested’ and components that are ‘attesting’. The architecture expects that for every attested component there SHOULD be at least one attesting component. Nesting and decomposition logic needs to preserve these trust relationships. The expectation of a Verifier is the/a correct decomposition is known and will be the basis for assessing Evidence where Evidence nesting structure should provide proof that the expected trust relationships are intact. Otherwise, that could be a condition for Verifier to fail the attestation assessment.

I think there are 3 classes of nesting logic:

  1.  Subcomponent(s) that are Attested by a parent component (single layer attestation of a multi-layered decomposition)
  2.  Subcomponent(s) that are Attested by a parent component  and Attesting other subcomponents (layered attestations)
  3.  Subcomponent(s) that are Attested by more than one parent component (e.g. countersigned or co-signed)

Having a standard format and evaluation method (TEEP) for this use case is then very important across vendors int he supply chain.
[nms] A TEE can be both an Attesting and an Attested environment. The same TEE can’t be both unto itself however. A manufacturer issued device certificate, attribute certificate or manifest can be used to capture claims about the attested (TEE) environment that has no other attesting environment. (FYI - Much of the industry would call this a root of trust). The mfg issued cert / manifest is considered by the architecture to be “Endorsement” values since there isn’t an Attesting environment (on the platform) that produces Evidence. The architecture draws a line between devices as principal entities and manufacturers as principal entities. The former relating to Attestation Evidence and the latter to Asserters and Endorsements.

Your other suggestion could work as well, but the consistent ablity to validate will be very important.  I'd like to follow the discussion and thoughts of others.

Best regards,
Kathleen
--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca<mailto:mcr@sandelman.ca>  http://www.sandelman.ca/        |   ruby on rails    [





_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats


--

Best regards,
Kathleen