Re: [Rats] [ietf-rats-wg/eat] Definition and usage of the term 'entity' (#16)

"Smith, Ned" <ned.smith@intel.com> Fri, 04 October 2019 19:53 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 AD7731200B4 for <rats@ietfa.amsl.com>; Fri, 4 Oct 2019 12:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 4wkIwdYKN3uQ for <rats@ietfa.amsl.com>; Fri, 4 Oct 2019 12:53:30 -0700 (PDT)
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 CE902120025 for <rats@ietf.org>; Fri, 4 Oct 2019 12:53:30 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2019 12:53:29 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.67,257,1566889200"; d="scan'208,217";a="217267345"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga004.fm.intel.com with ESMTP; 04 Oct 2019 12:53:29 -0700
Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 4 Oct 2019 12:53:28 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.122]) by ORSMSX159.amr.corp.intel.com ([169.254.11.209]) with mapi id 14.03.0439.000; Fri, 4 Oct 2019 12:53:26 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
CC: ietf-rats-wg/eat <reply+ABPMCSFS3MJKQGCWIELN36V3UTAZLEVBNHHBX3OMDM@reply.github.com>, ietf-rats-wg/eat <eat@noreply.github.com>, "rats@ietf.org" <rats@ietf.org>, Comment <comment@noreply.github.com>
Thread-Topic: [Rats] [ietf-rats-wg/eat] Definition and usage of the term 'entity' (#16)
Thread-Index: AQHVetkBfNNVei6RdUGYFkMEDIesFKdKxG4AgACLqID//5T9AA==
Date: Fri, 04 Oct 2019 19:53:26 +0000
Message-ID: <D5CE0BA1-E9A8-4B20-A9BB-3A6BBCE1F1D7@intel.com>
References: <ietf-rats-wg/eat/issues/16@github.com> <ietf-rats-wg/eat/issues/16/538489003@github.com> <E4998B54-DD72-46BA-8022-38F95F46021A@intel.com> <CAHbuEH7Wr-6+ADcRDpoq7m_iDjndkaKWW5MRSG9DUDdc8c_f5A@mail.gmail.com>
In-Reply-To: <CAHbuEH7Wr-6+ADcRDpoq7m_iDjndkaKWW5MRSG9DUDdc8c_f5A@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.24.10.171]
Content-Type: multipart/alternative; boundary="_000_D5CE0BA1E9A84B20A9BB3A6BBCE1F1D7intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/T_MEVGjf29SFG6sx7o2Qx6NLjYI>
Subject: Re: [Rats] [ietf-rats-wg/eat] Definition and usage of the term 'entity' (#16)
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: Fri, 04 Oct 2019 19:53:34 -0000

See inline [nms]

On 10/4/19, 12:17 PM, "Kathleen Moriarty" <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>> wrote:



On Fri, Oct 4, 2019 at 1:56 PM Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote:
The architecture defines:

· Entity:  a user, organization, device or computing environment.

· Principal:  an Entity that implements RATS Roles and creates provable Claims or Attestation Results (see [ABLP] and [Lampson2007]).

· Attesting Computing Environment:  a Computing Environment capable of monitoring and attesting a target Computing Environment.

· Attested Computing Environment:  a target Computing Environment that is monitored and attested by an Attesting Computing Environment.

The attested computing environment is the subject of attestation which clearly is creating provable claims.

The ‘attested’ environment may be less clearly a Principal. At one point the list suggested the architecture should define a term “target of attestation” or “attestation target” (or something similar). The term “attested computing environment” seems close to this. Do we think the attested environment is semantically the same as “subject of the attestation”?

Using Lampson’s definition of Principal, an expression of attributes (aka claims) is itself a principal.

There are lots of cases where ‘entity’ is used to refer to organizations and users (see https://csrc.nist.gov/glossary/term/entity ). Given the broad use of the term to mean: a “user, organization, device or process” it might not make sense for RATs to change its scope. The RATS Arch used the term “computing environment” instead of process because not every computing environment has an operating system.

An “attested computing environment” is clearly intended to be a “computing environment” and hence is an Entity according to the arch draft.

And from a review of the EAT draft (again), I am reading this as the attestation based on the installed code with the attestation performed at boot to match what was installed.  This would verify that the code was what the system administrator installed and configured.  As opposed to code being attested by the creator, which might be done with the same format, but would assure the code was as he creator expected.

I'm asking about this clarification in light of supply chain and the flow document:
https://datatracker.ietf.org/doc/draft-fedorkow-rats-network-device-attestation/?include_text=1

Does the supply chain use case hold in these definitions or is there some reason why we might not care about attestations on code from the originator that might include code it relies upon when chained attestations are considered?  This would expand out the definition of entity as well.
[nms] The RATS architecture describes the “attestations on code from the originator” as “Endorsements” from “Asserters”. The architecture tries to avoid using the term “attestation” in this context as collection of reference values (Endorsements) isn’t the same as providing proof and evidence (and the charter ruled this out of scope for now). The NIST definition of Entity includes supply chain entities (aka Asserters).

If the RATS charter were updated to allow definition of “Endorsements” it might make sense to propose using JWT/CWT as a binding. The Architecture draft defines endorsements [here] as a specialization of Claims. Claims in Evidence can be semantically linked to claims in Endorsements. This is intentional so that verification is less susceptible to semantic misdirection.
[here]

  *   Endorsements are reference Claims about the environment protecting the Attesters capabilities to create believable Evidence (e.g. the type of protection for an attestation key).  It answers the question "why Evidence is believable".


If the EAT draft’s use of entity is semantically equal to the architecture draft use of “attested computing environment” then possibly it makes sense for the EAT draft to begin using this term instead?

The architecture draft potentially could be more clear as to whether an “Attested computing environment” is both an entity and a principal or just an entity. It seems clear that an “attesting computing environment” is a Principal.

Is EAT limited to 'attested computing environments' or a broader definition of entity?

Kathleen


Ned

On 10/4/19, 10:27 AM, "Laurence Lundblade" <notifications@github.com<mailto:notifications@github.com>> wrote:


EAT and Architecture are absolutely NOT aligned on the term entity. See my recent email comments on the architecture document.

My basis for closure is that the architecture document will define some term that is the is used to refer to the subject of the attestation. Maybe we shouldn't close this until the architecture doc starts tracking issues formally.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/ietf-rats-wg/eat/issues/16?email_source=notifications&email_token=ABPMCSG6S47KPNKHPDRK3TDQM54ILA5CNFSM4ID7KXSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMLBKY#issuecomment-538489003>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABPMCSAPK5BFFBWNGO2SLZTQM54ILANCNFSM4ID7KXSA>.
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats


--

Best regards,
Kathleen