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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 08 October 2019 11:05 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 DDCF01200B7 for <rats@ietfa.amsl.com>; Tue, 8 Oct 2019 04:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yt2CYgpLOqRU for <rats@ietfa.amsl.com>; Tue, 8 Oct 2019 04:05:26 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47DD120089 for <rats@ietf.org>; Tue, 8 Oct 2019 04:05:25 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id k9so14394707oib.7 for <rats@ietf.org>; Tue, 08 Oct 2019 04:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6FDnERYBVvAppyCpAmlYa0HG3i6Lh4EKi2bCk9dA5L4=; b=c14TIOIlaAbhZ96fz2L1OziNp/3Y5a/0LAnD0GUZaPb9K8PIp9Od5D5cNt0ur6RLui sCZ9POTNV8uBAqlUFP/5uvw/4xOmd/mjJ4an91ioKkyerjOKAWjJT5ybWFIhBMyCVkzV PtiFGYg+hjd9UqoGcct0RyiDvW2+mIL+9Vh+eptVlmSyPyJKYuJ4iIORszCd8p4pcOYF m1sGXZCx+0YBlVt4KAvZdRNb0f0dCUoiubJgZKdYCAmfMYl55rLuVfVGNdtDRsIHOgbM 1rLQOqU1f67p9dbuG2YQUX6Vdw4YfJuFvYP/UX6/tnmN99Wu9VQUfNeXwbWLlK0NTiBw sjTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6FDnERYBVvAppyCpAmlYa0HG3i6Lh4EKi2bCk9dA5L4=; b=akZngnHys1ZX15cBz/OEpvmE5/g2V4xgOxSr1ew+kCLs+KE56EDi1vKFtztjL3Plak HCVFKAUtMGZQ1qFJh0aXyPml3JDx2nnsPIEEedj7csa2PyycsxmlkI3ySzRNLmgYV6NP r3bJdPvRBBGkZmj1dIJ5igyDr+PyOeDxAsXu4NFuGsd2Ls0vA37RNkZsQbus976CeOub s1xk8lQ1Y+jTeiS4ij9qGVCxDke73aw3RowlgPetx3al+Xqw/1SuhmRRFI2IImoNuKKE iwpcmJMX9QWwYi3CZiO21nnkr6VClTghXboi6ZaD0ddkYlyME9bcimBUXhbVNpJ/62HD jLBg==
X-Gm-Message-State: APjAAAWFzHuT0Ayw4DYjqxRK1D5H8hI5OTd7n3CH7kSCW3fUagFF0duL cD/W1RGEW3+ngIKKgXeotHdjI9j/Fbk1vWTWlaI=
X-Google-Smtp-Source: APXvYqztTMYWolmgpDyk7GkH6cAXMHxs/rDWhyGclgIsaRG4NpSXiBvsCDsvZKMp7SYXoO0uH2RzYuCNrgKZbVebpfg=
X-Received: by 2002:aca:4744:: with SMTP id u65mr3216342oia.164.1570532725181; Tue, 08 Oct 2019 04:05:25 -0700 (PDT)
MIME-Version: 1.0
References: <HE1PR0701MB2267E23FFE8FF91F5DAC6FD58FCF0@HE1PR0701MB2267.eurprd07.prod.outlook.com> <1882.1570451614@dooku.sandelman.ca> <CAHbuEH6=O7zwyKD3-NAG=128dFtd7BVZ0QKEPTUcCLmJeenEGg@mail.gmail.com> <29358179-382F-4660-B012-0327274343AE@intel.com>
In-Reply-To: <29358179-382F-4660-B012-0327274343AE@intel.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 8 Oct 2019 07:04:48 -0400
Message-ID: <CAHbuEH5CrfikXn1SGRM+Fb2ChSd6YH_W5SexXkph+Mfa8wH7Jg@mail.gmail.com>
To: "Smith, Ned" <ned.smith@intel.com>
Cc: Michael Richardson <mcr@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031511505946425c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/RNeodC9ysd-mkCZfm6bC8GFY72M>
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: Tue, 08 Oct 2019 11:05:29 -0000

On Mon, Oct 7, 2019 at 2:33 PM Smith, Ned <ned.smith@intel.com> wrote:

> See inline [nms]
>
>
>
> On 10/7/19, 9:09 AM, "RATS on behalf of Kathleen Moriarty" <
> rats-bounces@ietf.org on behalf of kathleen.moriarty.ietf@gmail.com>
> wrote:
>
>
>
>
>
>
>
> On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <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> 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)
>
>
If you are just talking about the TEE case and not the manufacturer signing
use case, then the signatures do build from the base.  But for what I would
call supply chain, the manufacturer or software developing organization is
the one to provide the signature and they know what software, modules. or
components they rely upon.  Therefore, the 3 classes are not painting the
right picture for what I would call the supply chain use case.  That's why
your nesting module looks different than what I stated, where I was talking
about what you are calling "endorsements'.



>
>    1.
>
>
>
> 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
>

I was referring to the protocol from TEEP, OrTPv2, not the TEE.  There are
a few use cases and the parties shift for the use cases, I believe there
are some use cases that do not require a TEE.


> 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.
>

Best regards,
Kathleen

>
>
> 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  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>


-- 

Best regards,
Kathleen