Subject: [sacm] Endpoint ID Design Team Meeting Notes: 2015-02-13

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 13 Feb 2015 14:35:42 -0600

SACM Endpoint ID Design Team Notes
2015-02-13
==================================

Agenda:

	* Reminder:
		- WebEx Chat and SACM Jabber Room
		- Recording will be (is) enabled
	* Endpoint ID Example Continued
		- Update on updating Information Model draft
		- POSTPONED Continued Provenance Discussion
			- Virtual Interim Considerations
			- W3C investigation considerations
	* Next Steps
		- Could we use a "by week"?

Attendees:
	Clifford Kahn
	Danny Haynes
	David Waltermire
	Jim Bieda
	Ron Colvin
	Lisa Lorenzin
	Adam Montville
	Jessica Fitzgerald-McKay

Overview
========
We had some technical difficulties at the outset of the meeting, but eventually decided to start talking about how we start updating the Information Model and postponing the provenance discussion until next week.  We ended the formal part of the meeting at about half past the hour and allowed the balance of the 2-hour block for Dave and Cliff to further discuss the structural changes of the IM draft.

To update the Information Model, we might consider:
	- Identify the information element gaps between current IM draft and Endpoint ID
	- We should more robustly define the entities in the relationship diagram
	- We have a notional model of an Endpoint Identity Assertion, and the IM draft should be updated with this infomration as well (perhaps that an endpoint attribute assertion can be an identity assertion)
	- 

Additional Comments
	- It's noted that we haven't yet indicated the normative information in the IM that would help determine whether specific data models would be compliant with the IM.
	- Concise is good.  We have made conclusions that could be distilled.
	- 

Way Forward
	- We're not 100% clear on how we want to organize the notion of Endpoint Assertion and/or Endpoint Identity Assertion (for next week)
	- Focus our efforts this go around on what a good organizational structure might be to convert the balance of the notes into the information model (this week)
	- Work on the ERD (this week)
	- Dave and Cliff will get together to determine how to split things out.
	- PROV will be pushed out

Amended, Ongoing Notes Pertaining to Endpoint Identification
=============================================================

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

	What constitutes provenance:
		* Assessing confidence
			* Identity of the reporter itself (possibly endpoint identity but may be software component identity)
			* Have some idea of what that thing is
			* Have some sort of timestamp
			* Is entity aware that it’s “self reporting” or “other reporting”

	3 Aspects of Provenance from W3C:
	1. Chain of Custody:
		* Who said the information
		* Who handles the information
		* Endpoint is in chain
		* SACM component is in chain
		* Should include how information was transported

	2. Method (“Process” in W3C terminology)
		* How did you go about harvesting

	3. Basis

	We should provide enough information for the consumer to determine degree of confidence.  May require guidance about what may or may not constitute some degree of confidence (perhaps an informational draft?). TODO: Need to recruit people to write this informational draft (certain areas in this set of notes could be used as a basis for such a draft).

	Reporter’s identity and the timestamp should be a MUST in all instances.  Others may lean toward SHOULD, because they may not always be possible.  

	Example: IP address of an endpoint
		Goal is to associate IP address with Unique endpoint ID.
			Endpoint self-report
			Third-party assigns IP address reporting (e.g. IP address mgt sys)
			Third-party observer (e.g. profiler, infrastructure witnessing traffic)

		We want provenance for that IP address attribute to tell us from where the information came.  If it’s observed, is it authoritative, or is it simply passive?  We want to know the observation timestamp.

		CoC is who is doing the reporting.
		Process is how observation was made/communicated.
		Object-oriented Provenance is the source of the observation

	Note that endpoints can’t really “lie” about third-party observations; caution if the observer is not in a position to see the accurate observation (e.g. NAT’d environments).

	Other observations from discussion:
		It’s valuable to capture time auth/observation occurred
		Every AVP should have its own timestamp.  
			Wouldn’t that be the timestamp of the attribute itself?

	TODO: Gap analysis for tying in W3C work to SACM - how do we hook into that work in a way that doesn’t bring in the whole elephant when we need only the trunk and the leg?  Cliff will iterate one more time, people will review and comment as appropriate before next meeting (2/13). Need to investigate the W3C concepts a bit further to determine how they might apply to SACM - find an example of how provenance would be generated/used.

	FUTURE WORK: Consider the “comment” mechanism as in IF-MAP - possibly something that can come later (subsequent SACM “phase”).

	DISCUSS: Transport security considerations may apply to Chain of Custody and Method, is there a “place” better than others to include this type of information in the model?

	DISCUSS: Is there any way to generalize the notion of chain of custody, method, basis, to then generalize “confidence”?  

	DISUCSS: Chain of custody considerations

	Notes previous to 2/6 conversation:

		* 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
	* Start preparing for IETF 92

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 13 Feb 2015 15:51:42 -0500

A question regarding this effort:

So there will be a list of primary and secondary attributes.

These attributes will be represented in some notation, such as 
name/value pairs.  Some, if not all, of these attributes will also be 
used for security evaluations.

Because this is being defined prior to the adoption of a data format for 
representing the assessment guidance, isn't there a risk that the 
representation of endpoint ID attributes will not be compatible with the 
guidance, necessitating duplication of collection?

--gun

On 2/13/2015 3:35 PM, Adam W. Montville wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 13 Feb 2015 22:23:12 +0000

I believe this is a real risk if we get too prescriptive in the information model. To avoid this we could discuss the data and relationships that need to be provided without implicitly or explicitly defining syntax or structure. This would allow for flexibility in how a given data model could be structured, but in doing so would provide a list of must-haves to be included in the data model.

Thoughts?

Have a great weekend!
Dave

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, February 13, 2015 3:52 PM
To: Adam W. Montville; [email-masked]
Subject: Re: [sacm] Endpoint ID Design Team Meeting Notes: 2015-02-13

These attributes will be represented in some notation, such as name/value pairs.  Some, if not all, of these attributes will also be used for security evaluations.

Because this is being defined prior to the adoption of a data format for representing the assessment guidance, isn't there a risk that the representation of endpoint ID attributes will not be compatible with the guidance, necessitating duplication of collection?

--gun

On 2/13/2015 3:35 PM, Adam W. Montville wrote:
> 	* 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
> ---------------------
>
> 		* Think about compositional model of assertions - Asserting 
> additional details related to another 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
> 		
> 		- Issues relating to compromise of endpoint attributes (lying 
> endpoints) - Perhaps slandering other endpoints as a result
>
> 	* Discuss identification information from bios/firmware (e.g. serial 
> numbers, asset tags, VM id) that can be queried on the device using 
> software
>
>
>

---

From: Jerome Athias <[email-masked]>
Date: Sat, 14 Feb 2015 08:20:15 +0100

I concur
That makes sense for me to work first on data/relationships

On Friday, February 13, 2015, Waltermire, David A. <
[email-masked]> wrote:

> I believe this is a real risk if we get too prescriptive in the
> information model. To avoid this we could discuss the data and
> relationships that need to be provided without implicitly or explicitly
> defining syntax or structure. This would allow for flexibility in how a
> given data model could be structured, but in doing so would provide a list
> of must-haves to be included in the data model.
>
> Thoughts?
>
> Have a great weekend!
> Dave
>
> From: sacm [mailto:[email-masked] <javascript:;>] On Behalf Of
> Gunnar Engelbach
> To: Adam W. Montville; [email-masked] <javascript:;>
> These attributes will be represented in some notation, such as name/value
> pairs.  Some, if not all, of these attributes will also be used for
> security evaluations.
>
> > We had some technical difficulties at the outset of the meeting, but
> eventually decided to start talking about how we start updating the
> Information Model and postponing the provenance discussion until next
> week.  We ended the formal part of the meeting at about half past the hour
> and allowed the balance of the 2-hour block for Dave and Cliff to further
> discuss the structural changes of the IM draft.
> >
> >       - We have a notional model of an Endpoint Identity Assertion, and
> the IM draft should be updated with this infomration as well (perhaps that
> an endpoint attribute assertion can be an identity assertion)
> >       -
> >
> > Additional Comments
> >       - It's noted that we haven't yet indicated the normative
> information in the IM that would help determine whether specific data
> models would be compliant with the IM.
> >       - We're not 100% clear on how we want to organize the notion of
> Endpoint Assertion and/or Endpoint Identity Assertion (for next week)
> >       - Focus our efforts this go around on what a good organizational
> structure might be to convert the balance of the notes into the information
> model (this week)
> >       - Scenario A: Software on an endpoint is asserting posture
> relating to the endpoint's software inventory and configuration.
> >
> >       * We are defining a core set of (primary) attributes that can be
> used to assert identity in a consistent fashon
> >       Identity attributes (used to determine what the endpoint is; to be
> provided regardless of other posture attributes):
> >
> >                       - Consider how to specify type: multiple
> attributes for each type
> > or type qualifier
> >
> >                       - Think abou the security considerations of
> insecure DNS
> > deployments
> >
> >                       - Interfaces may be nested (e.g., overlay networks
> - VLANs) - NOTE: Need to verify that standardized methods are available to
> do this.
> >
> >                       - 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
> >                                       - 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)
> >                                       - Likely not a primary identity
> attribute, but likely useful to include as an aspect of posture.
> >                               - Henk: 802.1AR
> >                                       - A strong, globally unique
> identifier (re: iDevID - preinstalled; lDevID - enterprise defined).
> >                                       - 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.
> >                                       - 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.
> >
> >                       - 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.
> > 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.
> >
> >                       * Identity of the reporter itself (possibly
> endpoint identity but may be software component identity)
> >       We should provide enough information for the consumer to determine
> degree of confidence.  May require guidance about what may or may not
> constitute some degree of confidence (perhaps an informational draft?).
> TODO: Need to recruit people to write this informational draft (certain
> areas in this set of notes could be used as a basis for such a draft).
> >
> >       Reporter’s identity and the timestamp should be a MUST in all
> instances.  Others may lean toward SHOULD, because they may not always be
> possible.
> >
> >
> >                       Third-party observer (e.g. profiler,
> infrastructure witnessing
> > traffic)
> >
> >               We want provenance for that IP address attribute to tell
> us from where the information came.  If it’s observed, is it authoritative,
> or is it simply passive?  We want to know the observation timestamp.
> >
> >       Note that endpoints can’t really “lie” about third-party
> observations; caution if the observer is not in a position to see the
> accurate observation (e.g. NAT’d environments).
> >
> >       TODO: Gap analysis for tying in W3C work to SACM - how do we hook
> into that work in a way that doesn’t bring in the whole elephant when we
> need only the trunk and the leg?  Cliff will iterate one more time, people
> will review and comment as appropriate before next meeting (2/13). Need to
> investigate the W3C concepts a bit further to determine how they might
> apply to SACM - find an example of how provenance would be generated/used.
> >
> >       FUTURE WORK: Consider the “comment” mechanism as in IF-MAP -
> possibly something that can come later (subsequent SACM “phase”).
> >
> >       DISCUSS: Transport security considerations may apply to Chain of
> Custody and Method, is there a “place” better than others to include this
> type of information in the model?
> >
> >       DISCUSS: Is there any way to generalize the notion of chain of
> custody, method, basis, to then generalize “confidence”?
> >
> >               * A timestamp indicating when the assertion was received -
> consumer
> > (e.g., collector, borker, repo)
> >
> >               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.
> >               The endpoint attribute assertions (if any) on which the
> assertion is
> > based
> >
> >               - uniqueness of any identifying attribute - address
> malicious or accidental cases where uniqueness may be compromised
> >       * 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
> > ------------------------
> >
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>
> [email-masked] <javascript:;>