Re: [EAT] Terminology definitions (was Re: Scope, Goals & Background for RATS)
Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Fri, 21 September 2018 13:09 UTC
Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E2B130E78; Fri, 21 Sep 2018 06:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 MWeQxsp7rV7R; Fri, 21 Sep 2018 06:09:16 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 481B1130E73; Fri, 21 Sep 2018 06:09:15 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8LD9AGv016678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Sep 2018 15:09:11 +0200
Received: from [134.102.163.186] (134.102.163.186) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Sep 2018 15:09:05 +0200
To: Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <92996be3-67cb-1581-0f60-46ede56034af@sit.fraunhofer.de>
Date: Fri, 21 Sep 2018 15:09:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.163.186]
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/y4w5w0x80Wd9gEEz_e9OrLA3Eis>
Subject: Re: [EAT] Terminology definitions (was Re: Scope, Goals & Background for RATS)
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2018 13:09:20 -0000
Hello Laurence, please find replies and comments in-line: On 09/21/2018 01:14 AM, Laurence Lundblade wrote: > Here’s my comments / suggestion for simplifying and clarifying the > terminology. The fewer terms the better. > > >> * Assertion: Defined by the ITU in X.1252 as "a statement made by an >> entity without accompanying evidence of its validity”. > Seems like we can do without this definition entirely. Trying to be > simpler... True. To scope the discussion we pulled in a terminology section to agree upon what we mean and create a common understanding of the scope. Assertion was pulled in, as not every claim (sets) are essentially assertions and they can be elevated in expressiveness via signing to become Attestation Claims, but not every Attestation Claim is Attestation Evidence. E.g. GPS coordinates cannot typically be verified via reference values (which is already a term abstracted for discussion - reference integrity measurement manifests - RIMM - would be more precise), unless the system is supposed to stay, for example, in exactly on place, or city, or country, I'd assume. Typically RIMM provide values that have to match. Reference values that define a scope that would match I have yet to encounter. > >> * Attestation Claim: Information about some characteristics or >> attributes that affect device trustworthiness. > Would just prefer to use “Claim”. Add examples: measurements of running > SW, GPS location, boot state, HW and SW Versions. > > A Claim is used by the Relying Party to evaluate device trustworthiness. > Saying it /affects/ device trustworthiness is confusing. Claims do not > change the device. Trustworthiness is a characteristic assessed by the Verifier (root of trust for verification) based on Attestation Evidence. In different domains, the trustworthiness of the exact same thing using RATS can be assessed differently (depending of the policies, e.g. critical infrastructure domain vs. eCommerce . In general, the creation of Attestation Claims of course do not change the device :) > > >> * Attestation Evidence: Proof for one or more Attestation Claims >> (characteristics, attributes, ...) that affect device >> trustworthiness, such as its hardware identity, firmware, >> software, configuration or composition, compliance status and >> runtime state. Attestation Evidence may be consolidated through >> the use of cryptographic hash and key generation algorithms. >> Attestation Evidence veracity may be augmented by Claimant >> signatures over portions of the Attestation Evidence. Note that >> Claims are non-proven assertions as opposed to Attestation Evidence. > How about just “Signed Claims” or “Secure Claims". Same comment about > “affect” as above. Definition can be just “Claims that have been signed > or similarly secured for Conveyance.” As stated above, a signed claim (set) is not automatically a semantic equivalent to evidence. Attestation Evidence can only be produced by a RoT of Reporting, while (signed) claim sets are produced by a RoT of Measurement. tl;dr very specific and detailed example on software component integrity in this comment To give a very concrete common example: In the domain of software component integrity, where (Co)SWID can be used as RIMM, a Linux-based OS is capable of producing IMA (Integrity Measurement Architecture) logs (other OS have equivalent capabilities). In a nutshell, the OS creates hash values about every software component executed (typically from FS, with smaller things these are blockdevice identifier, addresses/offsets) in the order of execution over time. Measured/Verified Boot procedures (formerly called Secure Boot, a now deprecated term) allow the same kind of measurements of Computing Contexts started before the OS (prominent examples include UEFI/BIOS or Bootloaders). The point is, these staged Computing Contexts all have their own Claimants, none of them can create CWT today or in the foreseeable future, but in a Measured Boot architecture, they are able to take on the role of root of trust of measurement (RTM) and can create Attestation Claims. At some point, an "inbox-API" for a root of trust for reporting (RTR) is available in a Computing Context. This can be a, for example, a specific proto-enclave, a CC-certified trust-zone, or a TPM Trusted Software Stack - the exact technology underneath does not matter, but a set of specific capabilities are required, e.g. including but not limited to: based on root of trusts, a physical coupling to the system that is "measured", protection of execution, and a shielded location. Attestation Claims (in this example the IMA logs) can be consumed by a RTR "inbox-API" - in the temporal sequence they were created in - in order to produce a very specific hash value that can only be created, if these exact Attestation Claims in that order are measured by the RTMs and then available to the RTR. Wrt Software Component Integrity, the output of the RTR is Attestation Evidence that can only be created, if the correct software components are executed in the intended order - and no other software component is executed. Consumer of that Attestation Evidence is a Verifier (root of trust of verification). On the Verifier side: A corresponding RIM wrt to the Attestation Evidence would be the expected hash values that are created by the RTR (Attester). A corresponding RIMM wrt to the Attestation Claims would be an appropriate Manifest of (Co)SWIDs. Typically, there are points in time at which especially interesting Attestation Evidence (in our example the RTR hash values) can be created: after each staged Computing Context, for example (and in this example, this would be the already mentioned UEFI, bootloader, kernel, etc.). If the RTR does not produce the exact Attestation Evidence that is expected, the Attestation Claims (e.g. secure audit logs) can provide more insight into which software component was "out of line". In summary - in this example there are multiple Claimants that create Attestation Claims, are RTMs, and cannot create tokens. There is also a hardware RTR that consumes (a large volume of) Attestation Claims in order to create very specific Attestation Evidence about the current integrity of software components that are or were in execution. Interoperable network protocols are required to convey Attestation Claims, Attestation Evidence, RIM(M)s, and the policies of local attestation (see Andrea's and Monty's replies before) in a way that a verifier can create an assessment of a communication partners trustworthiness. > > >> * Attester: An endpoint that has a root-of-trust for reporting (RTR) >> and implements a conveyance protocol, authenticates using an >> Attestation credential, collects Attestation Evidence about itself >> and presents it to a consumer of evidence (e.g. a Relying Party or >> a Verifier). >> >> * Claimant: An entity that make an assertion to a certain property >> regarding the trustworthiness of an entity. This may be the >> binding of an Attester to an RTR or any other kind of property. > Commenting on Attester and Claimant together. We need a term for the > “subject” of the Claims, so I propose replacing “Claimant” with “Entity” Measurment's about a different system than yourself or "on behalf" of another system is a gap that we did not address explicitly in the text yet. But I think that is a very good proposal. As implied by the example above, I'd strongly recommend to retain the role of Claimant, but add the "subject" of the Claim as a term. Entity though is one of the most generic term right after "thing" - and I would like to see a little more specialized term. > > * Entity: that about which the Claims are made. Often referred to as a > device. Examples are a phone, IoT Device or Router. It can also be a > submodule of a device. > * Attester: the part of an Entity that secures the claims (securing is > typically done by signing). It turns “Claims” into “Signed Claims”. > A TPM is an example of this. > > > Think we should avoid the term “authentication” as seems more for > protocols like SASL and EAP.. I see your point. We were struggling about "authentication" a lot, as attestation is often misinterpreted to scoped to enable "stronger authentication". Remote Attestation Procedures include the scope of establishing trust in the identity of the communication partner and also the endorsement of capabilities of, for example, a component that is an Attester (RTR). But Remote Attestation is not limited to this specific subset of capabilities/semantics. We should try to word-smith text that avoids the term authentication, I think. > > >> * Conveyance: The transfer of Attestation Evidence between Attester >> and Verifier, facilitated by network protocols that are reliable, >> secure and can prove the freshness of Evidence, if required. > >> * Reference Values: Information that can be matched with collected >> Attestation Evidence to determine if the device's operational >> state complies with an intended/expected operational state (e.g. >> Reference Integrity Measurements). > Prefer "Reference Claims" so they are clearly tied to the term Claim. I > could live without definition entirely if we really wanted to be simple. As, for example, signed (Co)SWID can be Reference Values (in that case RIMM) and as those exceed the semantic of a single claim, I really am not comfortable with reducing the scope of Reference Values to Claims. The Creation of Attestation Evidence ranges from simple to rather complex, I think. That is why creating appropriate network protocols also requires a lot of running code and modularity. > > >> * Relying party: An entity that consumes and assesses Verifier >> results for the purpose of improved risk management, operational >> efficiency, security, privacy (natural or legal person) or safety. >> The Verifier and Relying Party functions may be tightly integrated. > I think the common and general definition is any server / service like > an online bank, e-commerce site, enterprise document server and such > whether or not the asses Claims. I propose: As the role of Relying Party can, but does not have to be coupled with the role of Verifier (appraisal of Attestation Claims can be a very computing intensive task and can require a large volume of Reference Values), I'd still recommend to make a distinction between entities that consume Attestation Claims and Attestation Evidence. The assumption here is that a relying party can process Attestation Claims that do not have to be appraised, but are considered trusted due to implicit attestation. > > * Relying Party: More generally any server or service like an online > bank or e-commerce site. Here a server or service that consumes and > assesses Verifier results for the purpose of improved risk > management, operational efficiency, security, privacy (natural or > legal person) or safety. The Verifier and Relying Party functions > may be tightly integrated. > > >> * Remote Attestation: The procedure of supplying Attestation >> Evidence to a communication partner via an Attester using network >> protocols for Conveyance. > I’d kind of prefer to leave this out as the whole document is about it. > If it is kept in, I think it should refer to the whole end-end process. I am unsure about this. A concise definition might really help, but I assume this one can be worded better? How do other individuals think about this? > >> * Root of Trust: The base entity for a chain of trusts that builds >> up trust in an overall system. > Some people think roots-of-trust are the boot ROM, embedded secret keys > and such in a device. Other people think they are X.509 root > certificates published by CAs used for verifying chains. It’s not clear > which you are referring to. That said, I think we should just remove > this definition from the charter. It doesn’t seem essential. This point of view I do not share. Roots of trusts (the last "s" is intentional) are an essential part of this effort, I think. If they are often mistaken (as are, for example certificates and identities), I think we should rather make the effort and create standards that (at least in the RATS domain) make very precisely clear what intent, scope and audience are. > >> * Verifier: An endpoint that has a root-of-trust for verification >> and implements a conveyance protocol, verifies Attestation >> credentials and may authenticate using Attestation Evidence or >> other credentials, appraises Attestation Evidence against >> Reference Values or policies and makes verification results >> available to Relying Parties. > I propose: > > * Verifier: A server or service that receives Signed Claims and > processes them by verifying the signature and possibly comparing to > Reference Claims. Please see the example above and the intended separation of duty ("offloading the burden of appraisal"). > > > Finally, I’d like to add: > > * Token: a collection of Signed Claims that is Conveyed from the > Attester to the Verifier If I am not mistaken, EA-Tokens do not have to be signed (which is good, as some specific technologies deployed for the foreseeable future cannot sign a CWT). Also, I think the separation of Attestation Claim and Attestation Evidence is a necessity and mandated by their disjunct semantic. > * Entity Manufacturer: The company that made the Entity. The Entity > Manufacturer configures the Attester with signing keys. It may also > be the Verifier or supply signature verification keys to the Verifier. I agree that an endorsement of the capability of an entity (or system component - entity is quite generic, see RFC4949. I am an entity, I think, and my parents have nothing to do with this) is very important. If that is your intent here, I totally agree, but think that more word-smithing will be required. > > > LL > > Viele Grüße, Henk > > > >> On Sep 18, 2018, at 1:26 AM, Henk Birkholz >> <henk.birkholz@sit.fraunhofer.de >> <mailto:henk.birkholz@sit.fraunhofer.de>> wrote: >> >> Hi all, >> >> we pushed an initial document to the RATS github in order to focus the >> discussion about remote attestation procedures a bit. >> >>> https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md >> >> We included a background section to better highlight the meaning of >> the term "attestation" in general. Hence, there is a trade-off between >> clarity and conciseness, which is one of the things we would like to >> get feedback about. >> >> Naturally, we are also very interested in feedback about the >> illustrated difference between explicit attestation and implicit >> attestation. >> >> Viele Grüße, >> >> Henk >> >> >> >> >> >> _______________________________________________ >> EAT mailing list >> EAT@ietf.org <mailto:EAT@ietf.org> >> https://www.ietf.org/mailman/listinfo/eat >
- [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Denis
- Re: [EAT] [Rats] Scope, Goals & Background for RA… Fuchs, Andreas
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Denis
- Re: [EAT] Scope, Goals & Background for RATS Carsten Bormann
- Re: [EAT] Scope, Goals & Background for RATS Michael Richardson
- Re: [EAT] Scope, Goals & Background for RATS Michael Richardson
- Re: [EAT] Scope, Goals & Background for RATS Eric Voit (evoit)
- Re: [EAT] Scope, Goals & Background for RATS Carsten Bormann
- Re: [EAT] Scope, Goals & Background for RATS Melinda Shore
- Re: [EAT] Scope, Goals & Background for RATS Smith, Ned
- Re: [EAT] Scope, Goals & Background for RATS Laurence Lundblade
- [EAT] Implicit vs Explicit Attestation (was Re: S… Laurence Lundblade
- Re: [EAT] Scope, Goals & Background for RATS Diego R. Lopez
- [EAT] Terminology definitions (was Re: Scope, Goa… Laurence Lundblade
- Re: [EAT] Terminology definitions (was Re: Scope,… Henk Birkholz
- Re: [EAT] Implicit vs Explicit Attestation (was R… Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] [Rats] Terminology definitions (was Re:… Smith, Ned
- Re: [EAT] Scope, Goals & Background for RATS Laurence Lundblade
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Diego R. Lopez
- Re: [EAT] Implicit vs Explicit Attestation (was R… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Fuchs, Andreas
- Re: [EAT] Implicit vs Explicit Attestation (was R… Henk Birkholz
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Wheeler, David M
- Re: [EAT] Implicit vs Explicit Attestation (was R… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Smith, Ned
- [EAT] Naming (was Re: Scope, Goals & Background f… Laurence Lundblade
- [EAT] EAT additions to Charter (was Re: Scope, Go… Laurence Lundblade
- Re: [EAT] EAT additions to Charter (was Re: Scope… Suresh Marisetty
- Re: [EAT] Naming (was Re: Scope, Goals & Backgrou… Diego R. Lopez
- Re: [EAT] EAT additions to Charter (was Re: Scope… Carl Wallace
- Re: [EAT] Naming (was Re: Scope, Goals & Backgrou… Laurence Lundblade