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

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.  Having a standard format
and evaluation method (TEEP) for this use case is then very important
across vendors int he supply chain.  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