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

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 27 Feb 2015 10:13:03 -0600

Participants please review for accuracy.

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

Agenda

	Reminder:
		- WebEx Chat and SACM Jabber Room
		- Recording will be (is) enabled
	Endpoint ID Example Continued
		- Pruning Discussions
			* "Sufficient" for "primary" identity attributes
			* Is "account" as an identity attribute in scope?
		- BIOS/Firmware information for identification
		- Should ASCII diagram survive as-is?
		- Provenance Discussion (W3C considerations)
	Next Steps
		- Review priorities that need to get done
		- Potentially come up with recommendations regarding additional concepts

Attendees
	Clifford Kahn
	Danny Haynes
	David Waltermire
	Lisa Lorenzin
	Ron Colvin
	Adam Montville

Overview
========
Talking over the agenda. Defer provenance discussion to some other point.
Reserve time at the end of the call to review priorities that need to get done and decide of the time we need to deal with.  Agenda modified accordingly.

Pruning Discussion.
We have a set of things that is open-ended - we can keep adding to the set of attributes that "identify" an endpoint.  What we want to do is arrive at a succinct list of *primary* attributes, and right now we have a lot.  

We have some cases to consider:

	1. Only one authenticated primary identity attribute
	2. More than one authenticated primary identity attributes
	3. No authenticated primary idenity attributes
		a. Netowork observations + appropriate information for correlation
		b. Infrastructure services (e.g. DHCP, Kerberos)
			 i. Sniffing on the wire
			ii. Looking at service information directly

There are some implications from the above.  With (1), we more than likely have some cryptographic information.  With (2) we probably have something in addition to cryptographic (but not cryptographic) information.  With (3) we have "third-party" or "observed" information that may not be cryptogrpahic in nature.  It really seems that we've defined a continuum of identity strength (1 strong; 3 weaker).

Addresses are probably the best identity we have today - tools already do this.  An address augmented with some cryptographic certificate makes sense.  

Dave is suggesting that we should we come up with a list of different kinds of device types, and Cliff seems to agree.   What are the useage scenarios we want to cover, then determine whether we have the right attributes, then identify gaps and what we can do to prune the extra attributes.

List the attributes and show how they would come together.  We'll have sets of operational security and privacy considerations that would be based on such an analysis.  

There seem to be two parts to this: 1) Idenity assertions and 2) how to validate those assertions.

Ensure that the identity attribute maps to a type of device (which mappigns apply), then how to validate this.  We want to be descriptive, not prescriptive.  We should consider operational concerns, however.  We should provide "may" considerations in the form of suggestions about how these descriptions would be used.  

We are goign to have requirements (e.g. MUST) on producers that they provide information on the subject of validation.  We are not going to require them to adhere to a specific validation method (e.g. MAY).  The intent is not to use new validation methods.

We may need to capture the validation method for conveyance to relying parties.  For example, if there are multiple consumers, the data from which would be later aggregated, and they use disparate validation methods, then there should be a way to express that validation method so that the aggregation can determine more about whether to rely on that information.

We should consider reaching out to folks in the management area to figure out whether there is existing work that can help us here (e.g. current standards, best current practices).

Who can write some scenarios?  Call for scenarios to be sent to list (Dave and Adam will work on this early next week).

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
	* Provenance information from W3C PROV
	* Is "account" as an identity attribute in scope?
	* Should *the* ASCII diagram survive as-is, or should it be replaced (with something more robust) or broken apart?  Is the diagram something we want to explicitly state as being normative?

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

	* Dedicate next week's time to developing scenarios for pruning
	* Review priorities that need to get done
	* Potentially come up with recommendations regarding additional concepts needing work

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 27 Feb 2015 11:55:20 -0500

A couple notes as I skimmed this:

- For the non-authenticated cases it's possible to generalize the 
primary attributes, but for the authenticated cases the primary 
attributes and how to use them will be different for each platform.

- In the non-authenticated case for a remote network, the only reliable 
pieces of information are the IP address and time stamp* (MAC address is 
possible for Windows machines and some implementations of samba).

- There is not a straightforward hierarchy of reliability for 
identification attributes:  the algorithm for determining the likelihood 
of a correlation is as important as the attributes themselves and should 
be a part of the standard to have any chance of consistent results.

- Should there be an allowance for proprietary solutions?  Asset 
management systems, as an example, that create their own unique 
identifier for known systems.

- Reliable asset identification isn't a necessity for all uses cases.

* This could be augmented via port scanning and/or OS fingerprinting, 
but both are costly operations that don't offer a great deal of useful 
information.

--gun

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