Subject: Re: [sacm] A potential outline of Identifying Attributes section of Information Model

From: Clifford Kahn <[email-masked]>
Date: Fri, 22 May 2015 16:01:56 +0000

All,
Here's the outline, after refinement in today's IDT meeting. Name are who plans to take the next step on the subsection.

                                                Cliff
4.x. Identifying Attributes
(State the goals.)
Want a consumer to be able to tell whether two endpoint attribute assertions concern the same endpoint.
Therefore, we specify attributes that enable a consumer to discern this.
(Why this is not simple)
(ISSUE: In this section, are we only wanting SACM consumers to be able to distinguish endpoints from one another? Or do we want to enable other entities, such as humans, to identify an endpoint too? J W comments that a human would want to identify a device as: "e.g. "the red iPhone owned by Mr Jones, in building 3, 2nd floor, room 213, cubicle 16, with a dent on the upper right side, serial number 15SQ67B12", telephone number 345-123-6543".)

(Not in scope for this section:

*         Identifying of particular assessment targets on an endpoint (e.g. a particular piece of software, a database instance, web site, etc)

*         Characterization, which should have its own 4.x section.)

4.y. Endpoint Attribute Assertions, Raw and Derived
(Henk: We shouldn't call them "raw assertions".)
4.x.1. Common Identifying Attributes (Cliff)
(TODO: Come up with a template for describing an attribute.)
(This section has normative language for providers.)
(MUST/SHOULD/MAY language about
* when and whether an endpoint attribute assertion is to include the attribute
* what the attribute says about the endpoint -- the *meaning* of the attribute
* range of values (mostly by reference to other RFCs)
* whether data models have to include them
)
*         IP address
*         MAC address
*         Hardware serial number
*         Certificate
*         Public key
*         Tool-specific identifier
*         ...
(Minor side note: "Tool-specific identifier" suggests that two tools could never agree on a tool-specific identifier. But a community may agree on one, and might even create a formal standard. So I don't think they are tool-specific. I think all that's important is that each of these attributes has a type and meaning *not* specified by the SACM internet drafts. Not sure what to call them.)

4.x.2. Properties of Attribute Values (Dave)
(Explain each)
(Should these properties be expressed in the information model? Yes. So, we need normative language for providers.)
* Stability
                volatile - persistent - mutable
* Multiplicity:
* Does the value generally refer to only one endpoint, or to multiple?
* Does an endpoint generally have multiple values of the attribute, or only one?
* Accuracy:
How often is the value true vs false? What can make a false value happen? (Lying endpoint? etc)
* Commonness
(Or other language; I found that the terms from 4.11.2 in https://tools.ietf.org/html/draft-ietf-sacm-information-model-01#page-19 were not bad at all, and adapted them.)

(Matrix of attributes and their typical properties
Commentary on how the properties of an attribute depend on circumstances.
Deployer SHOULD take their local circumstances into account.
SACM components SHOULD be customizable accordingly. (We need to flesh this out.)
)

(Try to have SHOULDs and maybe even MUSTs about how consumers should use the attributes.)

4.x.3. Associated Attributes (Henk)

4.x.4. How Consumers Use This Stuff
(Some normative language, at least MAYs, about drawing conclusions from this information. How do they tell whether two endpoint attribute assertions concern the same endpoint, etc.)
(Joining assertions together into bigger assertions.)

4.x.5. Identification of Endpoints where SACM Components Reside
Every information element needs identifying attributes of its producer's endpoint. (Provide normative language. SHOULD? MUST?)
Specifically, in an endpoint attribute assertion, we need identifying attributes of the asserter's endpoint. If the asserter is external, the assertion will contain identifying attributes of two endpoints.
(Discuss what this information is for.)

4.x.6. Misidentification
(Includes attacks as well as just general malfunctions; Security Considerations section will refer to here.)
Effects of misidentification
Things that can cause misidentification
How minimize misidentification

Appendix: Examples of Endpoint Identification in Action
(Some of our test cases)

Appendix: Mapping to SACM Use Cases and Requirements

Clifford Kahn
Principal Engineeer, Technical Lead

---

From: Jerome Athias <[email-masked]>
Date: Fri, 22 May 2015 19:41:05 +0300

Thanks Cliff

few comments inline

2015-05-22 19:01 GMT+03:00 Clifford Kahn <[email-masked]>:
> All,
>
> Here’s the outline, after refinement in today’s IDT meeting. Name are who
> plans to take the next step on the subsection.
<snip>

> (Henk: We shouldn’t call them “raw assertions”.)

While it's clear that we need 2 distinct constructs, the distinction
could come from the "Method of Collection".

> 4.x.1. Common Identifying Attributes (Cliff)
<snip>

> (Minor side note: "Tool-specific identifier" suggests that two tools could
> never agree on a tool-specific identifier. But a community may agree on one,
> and might even create a formal standard. So I don't think they are
> tool-specific. I think all that's important is that each of these attributes
> has a type and meaning *not* specified by the SACM internet drafts. Not sure
> what to call them.)

Proprietary IDs?
External IDs?

> 4.x.2. Properties of Attribute Values (Dave)
<snip>
> * Accuracy:
(vs "level of fidelity"... I prefer talking about Confidence + Trust Level)

> How often is the value true vs false? What can make a false value happen?
"A machine that has already been infected with malicious software can
make false reports on its identity and the software it is running.",
TCG ECP V1 Rev 10

> * Commonness
<snip>
> Commentary on how the properties of an attribute depend on circumstances.
Context

> 4.x.6. Misidentification
>
> (Includes attacks as well as just general malfunctions; Security
> Considerations section will refer to here.)
>
"A machine that has already been infected with malicious software can
make false reports on its identity and the software it is running.",
TCG ECP V1 Rev 10

> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Jerome Athias <[email-masked]>
Date: Fri, 22 May 2015 19:57:18 +0300

4.x.6. Misidentification

you could find interesting
https://www.trustedcomputinggroup.org/files/static_page_files/1B8D6839-1A4B-B294-D005B7E08AFD599C/Endpoint%20Compliance%20Profile%20v1r10.pdf

5.2 Threat Model and 5.3 Countermeasures