Subject: [sacm] Endpoint ID Design Team Notes: 2015-01-30

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 2 Feb 2015 10:37:53 -0600

SACM Endpoint ID Design Team Notes
2015-01-30
==================================

Agenda:

	* Reminder:
		- WebEx Chat and SACM Jabber Room
		- Recording will be (is) enabled
	* Note takers?
	* Endpoint ID Example Continued
		- Review cryptographic information from Lisa, Cliff, Henk
		- Discuss ID information from BIOS software
		- Wrap up temporal data discussion, if needed
		- Providing prvenance information
	* Next Steps

Attendees:
	Adam Montville (SACM WG Host)
	David Waltermire
	Carolin Latze
	Charles Schmidt
	Chris Inacio
	Clifford Kahn
	Danny Haynes
	Henk Birkholz
	Jim Bieda (Call-in User_8)
	Lisa Lorenzin
	Ron Colvin (Call-in User_1)

Overview
========
We changed up the priority of the agenda so that we could consider ID attribute "covered", so Lisa, Cliff, and Henk provided a five-minute (each) overview of the areas they were going to research.

Amended, Ongoing Notes
======================

Scenarios:

	- Scenario A: Software on an endpoint is asserting posture relating to the endpoint's software inventory and configuration.

Endpoint Identity Assertion
---------------------------

	* All endpoint attributes can be used to establish identity
	* We are defining a core set of (primary) attributes that can be used to assert identity in a consistent fashon
		- High level of assurance, attributes can be authenticated
	* Other (secondary) attributes can be used to check an identity assertion or to further define the endpoint's identity (e.g. configuration, software inventory, capability)

Attribute/value pairs
---------------------

	Identity attributes (used to determine what the endpoint is; to be provided regardless of other posture attributes):

		* Certificates (e.g., device, user, drive, other hardware)
			- Device mandatory if available on device; favored by consumers of the assertion
			- Others if available as associated with the session
			- Use whole cert or some aspect (e.g., public key)
		
		* Hostname(s) - configured on the device; may be multiple and possibly of different kinds
			- Consider how to specify type: multiple attributes for each type or type qualifier
		
		* FQDN(s) (if available); some hosts may have multiple; also list DNS aliases
			- Sourced from the DNS infrastructure
			- Think abou the security considerations of insecure DNS deployments
		
		* Interface(s) (comprehensive, if possible)
			- MAC address(es)
			- IP address(es)
				- Including additional IPs assigned to the interface
			- Interfaces may be nested (e.g., overlay networks - VLANs) - NOTE: Need to verify that standardized methods are available to do this.
		
		* Other cryptographic information (e.g., IPSec Key-hash, HIP-HIT (RFC4423, 5201), 802.1AR)
			- NOTE: Investigate options to determine if they should be included as primary attributes; post a summary of how to use these specs
				- Cliff: HIP-HIT
					- Experimental implementation at the moment; not a lot of adoption
					- ID is a public key; an endpoint can have more than one
					- A public key might be a good identifier type in general for SACM; public keys tend to exist, even when a certificate doesn't (e.g. SSH)
				- Lisa: IPSec Security Associations (SA)
					- The SA contains the IPSEC keys and what algorithms are in use
					- Unable to differentiate by source IP address
					- Keys can rotate, and may be less useful as a result					
					- Likely not a primary identity attribute, but likely useful to include as an aspect of posture.
				- Henk: 802.1AR
					- Appendix B in specification discusses use of TPM
					- The standard's intent is to support unattended operation
					- A strong, globally unique identifier (re: iDevID - preinstalled; lDevID - enterprise defined).
					- lDevID can be generated specifically for SACM uses
					- Any xDevID has to ahve a certificate.  Could a public key from the certificate be used as the identifier?
					- How would a SACM component know of the ID?  It could be collected from both the endpoint as well as the device making a network access control decision.
					- The secret (e.g. certificate) does not need to be hardware rooted
					- How widely is this implemented?  About 6 years old.  Many infrastructure vendors have implementations, but not much use has been seen.
				- Other notes:
					- To include public keys, we need to discuss: what algorithm was used and the intended use of the key as data points?  Need to consider authentication using private keys.
		
		* Tool-specific identitier - provided by the software making the assertion
			- SHOULD be provided
			- May be session scoped if the tool is not able to distinguish an endpoint across sessions
			- May be omitted if the tool is unable to distinguish the endpoint across multiple assertions

		* Identification information from bios/firmware (e.g., serial numbers, asset tags, VM id) that can be queried on the device using softare. NOTE: Need to discuss more.
			- Assets are compositional.  Some components may have specific identifiers.  It would be useful to indicate which component has a specific identifying attribute.
			- Information should be made available by all manufacturers
			- If available should be provided as an attribute

Temporal Data
-------------

A timestamp indicating when the observation is made for a given AVP:

	* If periodic, a timestamp at present time
	* If event-based, an interval last-change to present time
	* A timestamp is included on an attribute-by-attribute basis

For information that changes frequently having the ability to poll and represent the poll interval is beneficial.  

Time to Live (TTL) values provide an indication of when a given aspect of state will change.  Provide when naturally occurring (e.g., a tool will know when the DHCP lease expires). MAY be provided if applicable.

	- Do not include in current model unless we have a good use case.

Provenance Data
---------------

	DISUCSS: Chain of custody considerations

		* A timestamp indicating when the assertion was received - consumer (e.g., collector, borker, repo)

		* Think about compositional model of assertions - Asserting additional details related to another assertion

	The SACM component that made the assertion - the identity of the software providing the information
		- An assertion of the identity of the software used (e.g., vendor, product, version, etc.)
		- The instance of the software (e.g., the device the software was run on, the installation of the software) - could be an endpoint identity assertion as well - may be the same as the endpoint or different if external to the endpoint
			- Reuse the identity information from the authentication to establish the identity of the reporter.
		- Cryptographic ifnormation that can be used to authenticate the provenance assertion
		- (FOR CONTINUED DISCUSSION) Some questions on the call about if providing provenance information is required in all cases; self-reported - may/should; other-reported - must
	
	The endpoint attribute assertions (if any) on which the assertion is based
	
	Information about the method used to derive the assertion

Other Data
----------

	Endpoint uniquely identified?  True or false; very subjective; ask larger WG

Other Considerations
====================

	* Write security considerations speaking to 
		- uniqueness of any identifying attribute - address malicious or accidental cases where uniqueness may be compromised
		- Issues relating to compromise of endpoint attributes (lying endpoints) - Perhaps slandering other endpoints as a result

	* When authenticating as part ofa SACM posture exchange, the authentication information should be incorporated into an endpoint identity assertion.  Should be a MUST for any endpoint that has the capability to authenticate.

Future Discussion Points
------------------------

	* Discuss identification information from bios/firmware (e.g. serial numbers, asset tags, VM id) that can be queried on the device using software

NEXT STEPS (Agenda Items to track)
==================================

	* Coordinate Information Model updates on list
	* Provenance discussion at next meeting (February 6)