Subject: [sacm] Endpoint ID Design Team Notes + Recording: 2015-04-24

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 24 Apr 2015 10:59:58 -0500

Agenda
Continued Test Case Discussion
Complete Network Profiler discussion
Start/complete Management Component discussion

Acknowledged Test Cases
Network Profiler (Cliff)
COVERED - SACM Collector on an endpoint (Danny)
Management Component managing collection of endpoints (Cliff)
COVERED - Evaluator (Danny)
COVERED - Datastore (Danny)

Materials (including recordings, once complete) are available here
https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0

NOTES:
Finishing up the discussion on our Network Profiler test case.

When Cliff is going through some of these attributes, I’m having difficulty explicitly reconciling between our primary/secondary attributes.  Cliff is now saying that “Network Interface” as a primary attribute is a mistake.  

It appears that our current list of identifying attributes are insufficient for a network profiler.  The assertion here is that we need both IP address and MAC address to be primary identifying attributes.

In going through Cliff’s scenarios, here’s the list of attributes he believes are pertinent:
Authenticated (to the source) identity of endpoint
Certificate
User credentials in some form (username or some other “identifying string”)
MAC address
Endpoint characteristics (one or more of)
Manufacturer
Model
OS
OS Version
Device Type
IP address
MAC address

On “authenticated identity of endpoint”:  Cliff is clarifying that this could be cryptographic information, such as a certificate or user credentials (in some form: username, or some other “identifying string”).  

Dave and Cliff are having a discussion about the nature of identification and whether these identifications are of primary concern to SACM.  If we don’t include some of these components in SACM, we should note when such attributes can be at least validated if not authenticated.  For example, IP-MAC associations can be validated or, under some circumstances, authenticated.

In a case where a RADIUS server (or any external attribute collector) is saying anything...the identity is part of the provenance of a given assertion.  The component could be compromised, so we need to capture this information in some way.  

Now moving to the next test case: External attribute collector that uses a management protocol.  See http://www.ietf.org/mail-archive/web/sacm/current/msg02602.html <http://www.ietf.org/mail-archive/web/sacm/current/msg02602.html>.  Primary examples of such protocols are: NETCONF, SNMPv2, SNMPv3, proprietary management protocols (i.e. SSH into the endpoint and run proprietary commands).  The primary difference between this and the “internal” attribute collector is that there are two endpoints to identify:
The ID of the external attribute collector and/or the endpoint on which it runs (part of provenance)
The ID of the endpoint, as attested by the collector

This requires identifying attributes such as:
IP address
Cryptographic information
Public key (for NETCONF - or anything - over SSH, for example)
Certificate or public key (for NETCONF - or anything - over TLS, for example)
Credentials of some type (i.e Kerberos-sourced information)

Dave raises the question: Is it SACM’s responsibility to label all artifacts dealing with identification?  Sometimes these things have different degrees of authentication or validation.  Cliff believes we need to enumerate at least some of these things.  If we don’t enumerate everything, then we should at least provide some manner to identify identifiers - a controlled vocabulary/registry.

Endpoint attributes used for identity need to be stable and certain.  Whatever registry/controlled vocabulary we’re going to leverage, there needs to be some good language for expert review.

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 24 Apr 2015 20:00:40 +0000

I doubt we'll arrive at an "authoritative" list of unique identifiers.  Hardware and application GUIDs, to include motherboard serial number, BIOS GUID, and management agent GUIDs are some of the higher confidence identifiers, but there may the thousands of them on a device, so an exhaustive listing is unlikely to be achievable.
	
	It's probably better to establish a standard way to represent the GUIDs, network data, PKI attributes, and other identifiers in a way that two applications/users can determine which identifiers they have in common than to try to find them all.
	
	The device identifier matching algorithm that looks to be the "best" that I've been able to build compares identifiers between two candidate device matches and goes through from the "highest confidence" matches down to the lowest confidence, based on the relative likelihood that different identifiers will results in correct and unique matches with minimal false positives and false negatives.  I believe it is equally important to establish which identifiers can be trusted to determine that a given device, application, or other subject is *not* the same as the one it is being compared to.  That way, lower confidence matches can be rejected.
	
	It's also viable to believe that combinations of identifiers, taken together, result in better identification than identifiers taken one at a time.
	
	Joseph L. Wolfkiel
	SCM Engineering Lead
	DISA ID52
	(301) 225-8820
	[email-masked]

	-----Original Message-----
	From: sacm [mailto:[email-masked]] On Behalf Of Adam W. Montville
	Sent: Friday, April 24, 2015 12:00 PM
	To: sacm
	Subject: [sacm] Endpoint ID Design Team Notes + Recording: 2015-04-24

	Agenda
	
	* Continued Test Case Discussion
	
	* Complete Network Profiler discussion
	* Start/complete Management Component discussion

	Acknowledged Test Cases
	
	* Network Profiler (Cliff)
	* COVERED - SACM Collector on an endpoint (Danny)
	* Management Component managing collection of endpoints (Cliff)
	* COVERED - Evaluator (Danny)
	* COVERED - Datastore (Danny)

	* https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0

	NOTES:

	
	
	* Authenticated (to the source) identity of endpoint
	
	* Certificate
	* User credentials in some form (username or some other “identifying string”)
	
	* MAC address
	* Endpoint characteristics (one or more of)
	
	* Manufacturer
	* Model
	* OS
	* OS Version
	* Device Type
	
	* IP address
	* MAC address

	
	
	Now moving to the next test case: External attribute collector that uses a management protocol.  See http://www.ietf.org/mail-archive/web/sacm/current/msg02602.html.  Primary examples of such protocols are: NETCONF, SNMPv2, SNMPv3, proprietary management protocols (i.e. SSH into the endpoint and run proprietary commands).  The primary difference between this and the “internal” attribute collector is that there are two endpoints to identify:
	
	1. The ID of the external attribute collector and/or the endpoint on which it runs (part of provenance)
	2. The ID of the endpoint, as attested by the collector

	* IP address
	* Cryptographic information
	
	* Public key (for NETCONF - or anything - over SSH, for example)
	* Certificate or public key (for NETCONF - or anything - over TLS, for example)
	
	* Credentials of some type (i.e Kerberos-sourced information)