Re: [Rats] RATS use cases review

["Panwei (William)" <[e-mail]>]

Hi Jessica and Frank,

The RATS charter says to standardize the information model for assertions/claims about system components characteristics scoped by the specific use-cases, so I think identifying what information should be attested is helpful. But the RATS charter also says to standardize interoperable protocols to securely convey assertions/claims, and I think categorizing the use case based on the type of information collected may not help archive this goal.
Different devices/services have different characteristics and different requirements, for example, the network devices like routers and switches are all composited devices and may have the out-of-band links for doing the RA, while the IoT devices are more resources-constrained and may have to use the public Internet.
In order to prevent omissions, I suggest that we can first categorize the use cases by the devices/services (in other word, Attester) types, then consider the how the RA can be used by these devices/services (including the function requirements and trigger conditions, e.g., attesting the device’s boot processes after it reboots), and last analysis how these devices/services do the RA (including what information should be attested and what requirements should the conveying protocols have).
After such analysis, if we find that there are not many differences among different devices/services, we can re-adjust the sections. But before the analysis done, I don’t know if we can foresee the differences don’t exist.

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

From: RATS [mailto:[e-mail]] On Behalf Of Xialiang (Frank, Network Standard & Patent Dept)
Sent: Thursday, July 11, 2019 12:06 PM
To: Jessica Fitzgerald-McKay <[e-mail]>; [e-mail]
Subject: [Rats] 答复: RATS use cases review

Hi Jessica,
Good point and topic!

Categorizing the use cases on the type of information collected is a possible, but maybe not the best way. Since this kind of difference seems to have no much influence to the RATS protocol design.

I have no definite answer to it now, but propose more options for discussion:

1.       Define different use cases for device/service types: network device, IoT device, web service, NFV, …

2.       Define different use cases from different functional requirements: boot time attestation, running time attestation, periodic attestation, on-demand attestation, on-change attestation, mutual attestation, batch attestation, pub/sub mode attestation, …

3.       Trigger condition of RA: device initial provisioning, device reboot, device post-update, line card insert/removal, some key event on phone/IoT device (i.e., execute key app, read important data), …

4.       Partial combination of the above use cases

B.R.
Frank

发件人: RATS [mailto:[e-mail]] 代表 Jessica Fitzgerald-McKay
发送时间: 2019年7月11日 1:54
收件人: [e-mail]<mailto:[e-mail]>
主题: [Rats] RATS use cases review

Hello, all,

I  took a careful read of the use cases document. I notices that Sections 5.1 - 5.6.2 each are variations on the themes of attesting to a device's:

- identity
- hardware inventory
- software inventory
- firmware
- configuration

Section 5.1 is fairly explicit about that.

Section 5.2 seems to be describing a particularly reslient remediation to hardware/software vulnerabilities (presumably discovered via a device's hw/sw attestation?).

Sections 5.3 and 5.4 are concerened with the configuration of a device's hardware or software TEE.

Section 5.5 describes how these forms of attestation are directly applicable to critical infrastructure. While I am sure there will be protocol restrictions for that type of device, the idea of what is being attested to is the same here as it is for other device types.

Section 5.6.1 seems to be relatively the same as the TEE/ML use cases. And, 5.6.2 admits to being essentially a subsection of the same.

In this light, the right approach is to organize the document around the information that is being attested (the above list, plus end-user information (section 5.6.3), geographic attestation (section 5.7), and connectivity attestation (section 5.8)), with perhaps additional information on how these types of attestation can be combined in support of things like, say, critical infrastructure security, etc.

What does the work group think?

Thanks,
Jess