Re: [Rats] Entity vs. role

"Panwei (William)" <william.panwei@huawei.com> Wed, 30 March 2022 04:10 UTC

Return-Path: <william.panwei@huawei.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 980CE3A003E for <rats@ietfa.amsl.com>; Tue, 29 Mar 2022 21:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 CCBV3MKBx2D5 for <rats@ietfa.amsl.com>; Tue, 29 Mar 2022 21:10:22 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE963A0045 for <rats@ietf.org>; Tue, 29 Mar 2022 21:10:21 -0700 (PDT)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KStFB677nz67TN2; Wed, 30 Mar 2022 12:07:42 +0800 (CST)
Received: from kwepeml500001.china.huawei.com (7.221.188.162) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 30 Mar 2022 06:10:16 +0200
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500001.china.huawei.com (7.221.188.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 30 Mar 2022 12:10:15 +0800
Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Wed, 30 Mar 2022 12:10:15 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "Smith, Ned" <ned.smith@intel.com>, "Eric Voit (evoit)" <evoit@cisco.com>, Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>, Thomas Fossati <tho.ietf@gmail.com>
Thread-Topic: [Rats] Entity vs. role
Thread-Index: AQHYPe6PgQWbu8zDYE+F8zzrq4lIsazK/ScAgAA6DoCAABj+AIAABWwAgAASgoCAAK6ugIAAUWwAgAFuMYCAAA4uAIAAGUyAgAABcoCAAFKJgIAHcZMggABTqoCAAR8X8A==
Date: Wed, 30 Mar 2022 04:10:14 +0000
Message-ID: <2623a76b783b473e94d47457c764beaa@huawei.com>
References: <3407CFB9-B713-4E13-BDA3-08EC7B5A905E@intel.com> <CAObGJnOxU0vfxzzZ9tv1J64KHDigxLcEMrgx0gDy97bE7NQJcA@mail.gmail.com> <E20F61DD-8775-4E68-8E56-E6EC92682A18@island-resort.com> <CAObGJnOv8ePE=R6vvdg5uib3Y9=WS8A5vcOdpWY0sREXA98aPQ@mail.gmail.com> <2BC14C43-80D0-4611-BEA0-9D9B9948BE0C@island-resort.com> <BYAPR11MB31255F64BDB773DB93A0C6CCA1179@BYAPR11MB3125.namprd11.prod.outlook.com> <9BFD1E45-569D-4E2F-BCD7-5DA6FF5A1BDF@island-resort.com> <SN6PR11MB3135EBAF7783D637C7BBA04AA1189@SN6PR11MB3135.namprd11.prod.outlook.com> <70179B54-6E99-4AD0-B28D-00284AA6BC86@island-resort.com> <86F9EC57-C752-407A-8E8E-C3C2C3A97F8A@intel.com> <716BA0A9-0EDE-425E-BE17-A072AF04832E@island-resort.com> <SN6PR11MB313507647DEB776A425ED124A1199@SN6PR11MB3135.namprd11.prod.outlook.com> <4A131D6A-F012-4B71-B5F7-A7129414D7E6@intel.com> <d203b82c5e2b4422b23aebec0d9f64f2@huawei.com> <4D346B42-70D4-4426-8036-B01B419316BA@intel.com>
In-Reply-To: <4D346B42-70D4-4426-8036-B01B419316BA@intel.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.99.246]
Content-Type: multipart/alternative; boundary="_000_2623a76b783b473e94d47457c764beaahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/JLHtmNx1Pr4CgIDnjsgK0Y-3zvc>
Subject: Re: [Rats] Entity vs. role
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: Wed, 30 Mar 2022 04:10:28 -0000

Hi Ned,

According to the definition of Attester: Attester is a role performed by an entity, Attester generates Evidence which is appraised to infer the trustworthiness of this **Attester**. And in the Evidence are the claims about the attributes of the Target Env and the Evidence is signed by the Attesting Env, so inferring the trustworthiness of the Attester is inferring the trustworthiness of the Attesting Env and the Target Env, so the Attester includes both the Attesting Env and the Target Env.
From the perspective of actions, it is true that an Attester mainly has the two actions (a) and (b). But action (a) involves Attesting Env and Target Env at the same time, because the claims are the attributes about the Target Env, and this action happens within the Attester. So, again, my understanding is that the Attesting Env and Target Env are both included in the Attester.

But when you say “The Attesting Env implements the Attester role”, it gives me the feeling that Attester collects claims from the Target Env, which makes the Target Env become a role at the same level as Attester, Verifier, and Relying Party. So, this is how I’m confused.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Smith, Ned
Sent: Wednesday, March 30, 2022 12:47 AM
To: Panwei (William) <william.panwei@huawei.com>; Eric Voit (evoit) <evoit@cisco.com>; Laurence Lundblade <lgl@island-resort.com>
Cc: rats@ietf.org; Thomas Fossati <tho.ietf@gmail.com>
Subject: Re: [Rats] Entity vs. role

If the capabilities or actions that an Attester performs includes (a) collection of claims and (b) creation of evidence which generally implies signing of collected claims. Then a Target Environment doesn’t do either (a) or (b). Target Env appears to be a passive component of the Attester (entity) rather than something that implements the Attester role within the Attester (entity).

It may be reasonably inferred that (b) could include (c) storage of keys / claims or (d) incorporation of freshness and recentness values.

The layering example suggests that if an Attesting Env is included in a Target Env, the target Attesting Env is passive and relies on the outer Attesting Env until evidence is created before the target (passive) Attesting Env becomes active. Hence, it is correct to refer to it as the Target Env until its trustworthiness details have been processed by the outer Attesting Env.

The system of Target and Attesting Environments are abstract terminology for ways to deconstruct / compose the Attester entity.

The RATS Arch is both an introduction to attestation concepts (and hence needs to use prose that is consumable by uninitiated readers; and a framework for more formal representation of the parameters and capabilities for assessing trustworthiness. It’s difficult to achieve both objectives in a short document. I think it does a pretty good job of that, but it isn’t perfect.

From: "Panwei (William)" <william.panwei@huawei.com<mailto:william.panwei@huawei.com>>
Date: Monday, March 28, 2022 at 9:10 PM
To: "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>, "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>, Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>, Thomas Fossati <tho.ietf@gmail.com<mailto:tho.ietf@gmail.com>>
Subject: RE: [Rats] Entity vs. role

Hi Ned,

I feel confused by this sentence “Th Attesting Env is a component (entity) that implements an Attester role”.

In section 3.1 of the Arch draft, it says:
   As shown in Figure 2, an Attester consists of at least one Attesting
   Environment and at least one Target Environment co-located in one
   entity.
In my understanding, the combination of Attesting Env and Target Env implements the Attester role.

Besides that, the definition of Attester is:
   Attester:  A role performed by an entity (typically a device) whose
      Evidence must be appraised in order to infer the extent to which
      the Attester is considered trustworthy, such as when deciding
      whether it is authorized to perform some operation.
According to this definition, the Attester is going to be inferred whether it’s trustworthy. And to be specific, its trustworthiness is inferred based on the authenticity of the Attesting Env and the attributes (or claims) of the Target Env. So the Target Env must be a part of an Attester role.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Smith, Ned
Sent: Friday, March 25, 2022 2:07 AM
To: Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>>; Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: rats@ietf.org<mailto:rats@ietf.org>; Thomas Fossati <tho.ietf@gmail.com<mailto:tho.ietf@gmail.com>>
Subject: Re: [Rats] Entity vs. role

Th Attesting Env is a component (entity) that implements an Attester role. Presumably, there is a Target Environment from which the AE collects claims. The TE isn’t implementing the Attester role (hence it isn’t an Attester). The Arch draft takes some liberties to improve readability for a wide audience at the expense of potentially confusing those who want to put a fine point on things.

BTW there are implied entities hosting Verifier A and RP / Verifier B. Otherwise, it wouldn’t be interesting to talk about the message exchange sequences (which are presumably signed by the entities behind the roles).
-N

From: "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>
Date: Thursday, March 24, 2022 at 2:11 PM
To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Cc: Thomas Fossati <tho.ietf@gmail.com<mailto:tho.ietf@gmail.com>>, "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>
Subject: RE: [Rats] Entity vs. role

Yes, the four boxes on top enclose RATS architecture roles required for the ar4si "Below Zero Trust" use case.

Eric

From: Laurence Lundblade, March 24, 2022 9:06 AM
Isn’t everything in this diagram a role?  If not, shouldn’t it be?


     .----------------.

     | Attester       |

     | .-------------.|

     | | Attesting   ||             .----------.    .---------------.

     | | Environment ||             | Verifier |    | Relying Party |

     | '-------------'|             |     A    |    |  / Verifier B |

     '----------------'             '----------'    '---------------'

           time(VG)                       |                 |

             |<------Verifier PoF-------time(NS)            |

             |                            |                 |

    time(EG)(1)------Evidence------------>|                 |

             |                          time(RG)            |

             |<------Attestation Results-(2)                |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |<------Relying Party PoF-----------------(3)time(NS')

             |                            |                 |

   time(EG')(4)------AR-augmented Evidence----------------->|

             |                            |   time(RG',RA')(5)

                                                           (6)

                                                            ~

                                                         time(RX')

LL




On Mar 24, 2022, at 12:35 PM, Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote:

Technically, the RATS Architecture is informational. Hence, no normative “requirements” but that doesn’t mean a I-D based on the architecture should assume conceptual messages can be routed to some other role or that some other role can produce a different conceptual message.

The main point of this thread is to highlight the difference between role and entity. And to try to avoid conflating them. But they are intimately related nevertheless. The examples I provided help illustrate how they relate but without conflation.
-Ned

From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Date: Thursday, March 24, 2022 at 11:45 AM
To: "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>
Cc: Thomas Fossati <tho.ietf@gmail.com<mailto:tho.ietf@gmail.com>>, "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Subject: Re: [Rats] Entity vs. role

It seems to me now that we need to sort out some of these use cases a little better as Henk suggested in the room in Vienna.

On Mar 23, 2022, at 1:54 PM, Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:

From: Laurence Lundblade, March 23, 2022 4:03 AM
...

Ironic in a way — I want to forward/passthrough Evidence in Results, you are forwarding/passingthrough Results in Evidence :-)

<eric> It is not me that puts Results in Evidence.  It is the definitions in the architecture document which requires it *must* be specified this way.

5.1 describing the passport model does not imply or require (or preclude) two verifiers.

Section 5.1 does not require that AR be embedded in a new AE message when sent from the device to the RP. It puts no requirements on that transmission. I don’t think it even Requires the Results be relayed by something that has security properties.

None of the examples in section 16 work this way.

I think the design is a fine and good, but I don’t see it in my read of the architecture document. (I searched for occurrences of “passport”). Apologies in advance if I’ve missed something in the architecture document.

LL