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

From: Henk Birkholz <[email-masked]>
Date: Fri, 5 Jun 2015 15:31:18 +0200

Basis for discussion on content regarding subsections added.

Cheers,
Henk

On 05/22/2015 06:01 PM, Clifford Kahn wrote:
> 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”.)

Context:
Every SACM Capability (which are composed into SACM Components) can 
provide (aka produce) an output (called a Result in SACM). Both a 
Collection Capability and an Evaluation Capability, for example, produce 
Results, which can be consumed by other SACM capabilities/components. 
But these Results are of different quality/purpose/content.

If the Result is a set of "raw" Endpoint Attributes, I would advise not 
to call them an Assertion Result, but a Collection Result, to highlight 
that an Assertion is already a refinement/augmentation of raw Endpoint 
Attributes that can be observed. Another reason would be that the actual 
Assertion could be done on another Endpoint (with a separate Component) 
via a Capability separate from the Collection Capability.

That said, both a Collection Capability and a Assertion Capability could 
be part of the same SACM Component (residing on the same Endpoint) and 
the Result produced by the Collection Capability could automatically 
(without any further input from the Control Plane or Guidance) be 
qualified by an Assertion Capability internally.

>
> 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 AttributeValues (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-19were
> 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)

Context:
In e.g. TCG IF-MAP metadata or SCAP-AI separate Endpoint 
Attributes/Values of the same Endpoint can be associated. Another very 
prominent example of associated attributes are the data nodes of a YANG 
schema tree. Attributes/Leafs that are bundled in an container are 
associated with that container concept. This association can resemble a 
tree structure or more complex graphs.

A basic concept to structure/associate Endpoint Attributes with each 
other should be part of a SACM IM, I think. Or are there good reasons 
that speak against including this concept?

Also, a simple differentiation of Endpoint Attributes/Values into "value 
states that are wanted" (e.g. compliance targets) and "values that can 
be observed at the moment" (e.g. collection results), might be an 
approach worthwhile to consider? Both will be payload information of the 
SACM Data Plane, I think?

>
> 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
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Clifford Kahn <[email-masked]>
Date: Fri, 5 Jun 2015 14:01:34 +0000

I had an action item to draft a subsection. On the principle that anything worth doing is worth doing at the last minute, here it is ...

4.x.1. Common Identifying Attributes 

4.x.1.1 IP Address

Range of values: MUST be an IPv4 or IPv6 unicast address,
	and optionally a scope string.

	This information model does not prescribe the actual data representation,
	as that is left to data models. However, the data representation MUST
	be equivalent (reversibly mappable to) what is stated in the following
	documents.

	For IPv4, MUST conform to https://tools.ietf.org/html/rfc791, section 3.2. 
		MUST NOT be a 127.* address (a loopback address).
		MUST NOT be a 255.* address (a broadcast address).

	For IPv6, https://tools.ietf.org/html/rfc3587.
		MUST NOT be a multicast address.
		SHOULD NOT be a link-local address.

	Scope string: an administratively assigned string denoting the IP routing domain.
	Implementations MUST support this.
	Administrators may use it to avoid ambiguity, for example
	if network address translation (NAT) is in use.

Meaning:
	The asserter attests that at the time of observation (plus or minus
	epsilon) the endpoint had the right to use, or was communicating using,
	each specified IP address.

	"Had the right" means, for example, was assigned the address by
	DHCP. 

	ISSUE: Do we need to capture the distinction between the right
	and the reality in the info model? 
	Perhaps yes, because IP spoofing is a reality.

Multiplicity:
	An endpoint attribute assertion MAY contain one or more IP addresses.

Conditions of inclusion:
	Each endpoint attribute assertion
	about the endpoint MUST include all IP addresses of the endpoint
	that are known to the asserter.

	If the asserter is the on the endpoint, it is expected to know
	and include all of the endpoint's IP addresses.

	If the asserter puts content into an endpoint attribute
	assertion based on a non-NATted IP communication from
	the endpoint,
	the assertion MUST include at least the IP address
	from that communication. (ISSUE: How can an asserter
	know whether it's NATted? Or, for that matter, whether an
	L3 proxy is in between? Maybe we'd better make this a SHOULD.) 

Data model requirements:
	All SACM data models MUST support this entire subsection.

4.x.1.2 MAC Address

4.x.1.3	Hardware Serial Number

4.x.1.4 Certificate

4.x.1.5 Public Key

4.x.1.6 Tool-Specific Identifier

4.x.1.5 Public Key

4.x.1.6 Tool-Specific Identifier

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]] 
Sent: Friday, May 22, 2015 12:41 PM
To: Clifford Kahn
Cc: [email-masked]
Subject: Re: [sacm] A potential outline of Identifying Attributes section of Information Model

Thanks Cliff

few comments inline

> 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>

> 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?
> (Lying endpoint? etc)
"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

> Things that can cause misidentification
"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

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 5 Jun 2015 14:14:30 +0000

Any thought on requirements to bring back all IP addresses from all network interfaces on a given endpoint?  I think the format and other info makes sense for individual IP addresses.  However, for identification, IP and MAC pairs that represent a logical "network interface" are likely much better identifiers than just one or the other.

I would hope that an information model would acknowledge and leverage the fact that IP and/or MAC addresses aren't generally used alone, but are layer 2 and layer 3 identifiers for a given endpoint.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Clifford Kahn
Sent: Friday, June 05, 2015 10:02 AM
To: [email-masked]
Cc: Lisa Lorenzin; Adam W. Montville; Waltermire, David A.
Subject: Re: [sacm] A potential outline of Identifying Attributes section of Information Model

4.x.1.1 IP Address

Meaning:

Multiplicity:

Conditions of inclusion:

Data model requirements:

4.x.1.2 MAC Address

4.x.1.4 Certificate

4.x.1.5 Public Key

4.x.1.5 Public Key

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]] 
Sent: Friday, May 22, 2015 12:41 PM
To: Clifford Kahn
Cc: [email-masked]
Subject: Re: [sacm] A potential outline of Identifying Attributes section of Information Model

Thanks Cliff

few comments inline

<snip>

<snip>

Proprietary IDs?
External IDs?

<snip>

<snip>
Context

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Jun 2015 08:35:12 -0700

> Sent: Friday, June 05, 2015 7:02 AM
> To: [email-masked]
> I had an action item to draft a subsection. On the principle that anything worth
> doing is worth doing at the last minute, here it is ...
> 

Do you need to say it is not a "preferred address" - similar to the link-local address restriction?

> 	if network address translation (NAT) is in use.

Scope strings are interesting.  However does this imply a potential need to create a new DHCP item so that it can be sent out to a device for reporting back?  Is there such a string already?

> 	Perhaps yes, because IP spoofing is a reality.

I am not sure that you can do this.  If there is such a distinction, it would be reported by a different entity than the end-entity.   I.e.  the DHCP server can state the name of the server which has the right to an address, the end-entity could be misconfigured and not know that it does not have the right or it could just be out right lying.

> "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>
> "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
> 
> >
> > Clifford Kahn
> >

---

From: Jerome Athias <[email-masked]>
Date: Sat, 6 Jun 2015 08:33:33 +0300

@Clifford: Thanks, happy to see progress and improvements
@Henk: valuable comments and good wording. I do concur that we should
have the "composition" concept (is there a better word?) introduced
@Joseph: I agree that we would need, or, it would be good to have, a
mechanism to describe a (timestamped) composed element for the
NetworkConfiguration of an endpoint. (meantime could a VLAN ID be
useful?)

Best regards