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

[Laurence Lundblade <[e-mail]>]

I haven’t read this thread in detail yet, but here’s a picture of what I think we’re trying to to create terminology for for the TEE / phone / SoC uses cases. Definitely does NOT apply to TPM-based systems.



The SoC is typical of a mobile phone (except there are likely to be ten more subsystems) with a TEE.
All subsystems are booted with secure/trusted boot — the code is authenticated by public key crypto (no TPM involved).
TEE can access all memory (lots of green arrows)
Individual subsystems can only access the memory they have been allowed access to so they live largely in their own partition
The chip HW registers contain things like the state of the HW debug facilities and the version and type of the chip

One particular attestation architecture works like this:
The attester lives in the TEE and owns the signing keys
The attester in the TEE creates claims about all sorts of stuff about Android including SW versions, measurements of files and measurements of running images. It can do this because it has access. Samsung TIMA is like this.
The attester in the TEE creates the location claim by access the position location HW directly
The attester in the TEE creates the HW version and debug state claims by access those HW registers directly

EAT uses the term “entity” to loosely refer to everything in the diagram. Many of those things are less secure than the TEE. The submods and security level claims are in the EAT draft to describe all this. For example, all the claims about Linux Android would appear in a submod that is labeled as lower security and as “Linux Android”. 

So using what Ned proposed the TEE is the attesting computing environment and most other parts, either collectively or individually are the attested computing environment(s). 

I don’t have fully formed opinion on this terminology yet, but wanted to describe the TEE-oriented set up for context.

LL



> On Oct 4, 2019, at 2:55 PM, Henk Birkholz <[e-mail]> wrote:
> 
> Sry, I used github directly to reply to the last issue comment, but that is apparently not forwarded to the rats list. Here is my reply to Kathleen's last comment:
> 
> 
> TL;DR yes, endorsements are a "form of attestation", but they are not attestation evidence. Endorsements are part of the attestation provisioning workflows.
> 
> 
> 
> During the chartering, the proponents made their case for a complete inclusion of remote attestation procedures and the resulting consensus was to do phases via chartering. There was a split into the "attestation evidence workflows", which is currently chartered, and the "attestation provisioning workflows", which is not currently chartered.
> 
> In achieving this compromise, the proponents where also adamant about including both workflows in the architecture I-D from the very beginning (as an "exception" so to speak) and luckily this also reached consensus - otherwise the document would not really make sense.
> 
> To answer your question: yes, endorsements are a "form of attestation". Nevertheless they are not attestation evidence, but part of the attestation provisioning workflows. This is also the reason why the RATS terminology is rather complex. To simply "attest to something" or "conduct attestation" is semantically mixing two quite separate and distinct workflows.
> 
> The authors of the architecture I-D are very invested in unifying as much as they can in this first phase though. Currently, the architecture I-D defines Evidence, Endorsements & Reference Values to be composed of Claims. The context gives them different scope, audience and intent, e.g. Attestation Evidence in the form of an EAT. That means we are using assertions and claims basically as synonyms, which is a bit tricky because in the IETF a Claim is a specialization of assertion and a data model concept used in web tokens. In RATS and especially in the RATS EAT I-D, Claims MAY be key value pairs in JWT or CWT that can be registered in IANA registries, but Claims MAY also be assertions that are represented in other data models (most prominently attributes in pub-key/identity or attribute certificates and YANG modules).
> 
> "Winding up with lots of formats": We surely want to prevent that, but we have to take into account what is used today globally.
> 
> "Terminology in the submitted flow draft that covers this scenario": While draft-fedorkow-rats-network-device-attestation makes use of concepts such as IDevID, LDevID, IAK and LAK, it does not elaborate on Endorsements and EK, which is okay, because they are.. well, currently out-of-scope. I know (obviously) that draft-birkholz-rats-tuda does use endorsement documents and corresponding endorsement keys, but that work was started before the chartering of RATS.
> 
> 
> Viele Grüße,
> 
> Henk
> 
> On 04.10.19 22:01, Kathleen Moriarty wrote:
>> On Fri, Oct 4, 2019 at 3:53 PM Smith, Ned <[e-mail] <mailto:[e-mail]>> wrote:
>>    See inline [nms]____
>>    __ __
>>    On 10/4/19, 12:17 PM, "Kathleen Moriarty"
>>    <[e-mail]
>>    <mailto:[e-mail]>> wrote:____
>>    __ __
>>    __ __
>>    __ __
>>    On Fri, Oct 4, 2019 at 1:56 PM Smith, Ned <[e-mail]
>>    <mailto:[e-mail]>> 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.
>> Could an endorsement be a form of attestation so the charter does not need to be updated?  If we wind up with lots of formats, it'll be impossible to manage with code being used by an entity for which they each chose their own format. From the submitted flow draft that covers this scenario, I'm not sure the terminology was clear enough on the point to separate those out and intentionally exclude endorsements.
>>    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".____
>>    __
>> This was helpful, thank you.
>> Kathleen
>>    __
>>        ____
>>        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"
>>        <[e-mail] <mailto:[e-mail]>>
>>        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
>>        [e-mail] <mailto:[e-mail]>
>>        https://www.ietf.org/mailman/listinfo/rats____
>>    ____
>>    __ __
>>    -- ____
>>    __ __
>>    Best regards,____
>>    Kathleen____
>> -- 
>> Best regards,
>> Kathleen
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats