[Rats] 答复: RATS use cases review

["Xialiang (Frank, Network Standard & Patent Dept)" <[e-mail]>]

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]
主题: [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