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

Michael Richardson <mcr@sandelman.ca> Mon, 07 October 2019 12:32 UTC

Return-Path: <mcr@sandelman.ca>
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 8F55D1200CC for <rats@ietfa.amsl.com>; Mon, 7 Oct 2019 05:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 l_ZdlkI83sck for <rats@ietfa.amsl.com>; Mon, 7 Oct 2019 05:32:49 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA9B1200B1 for <rats@ietf.org>; Mon, 7 Oct 2019 05:32:48 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [80.233.45.41]) by relay.sandelman.ca (Postfix) with ESMTPS id B0BD71F47F; Mon, 7 Oct 2019 12:32:47 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 34B852B6B; Mon, 7 Oct 2019 14:33:34 +0200 (CEST)
From: Michael Richardson <mcr@sandelman.ca>
To: "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>
cc: "rats@ietf.org" <rats@ietf.org>
In-reply-to: <HE1PR0701MB2267E23FFE8FF91F5DAC6FD58FCF0@HE1PR0701MB2267.eurprd07.prod.outlook.com>
References: <HE1PR0701MB2267E23FFE8FF91F5DAC6FD58FCF0@HE1PR0701MB2267.eurprd07.prod.outlook.com>
Comments: In-reply-to "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com> message dated "Mon, 15 Jul 2019 08:57:23 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 07 Oct 2019 14:33:34 +0200
Message-ID: <1882.1570451614@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/0eIP6UwZG7AMdWvsdwIasHgaVRw>
Subject: [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 12:32:51 -0000

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

Oliver, Ian (Nokia - FI/Espoo) <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)

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