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

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 1 May 2015 11:06:19 -0500

Agenda
Endpoint Identification Attribute Analysis (see EIDT Summary deck)
Next Steps

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

Notes
Adam reviewed the deck we might start with at the virtual interim.

Cliff is concerned about the timeframe we have available at the virtual interim.  Danny is suggesting that we provide some definitions.  

Dave: We want to define the space each test case covers.

We are probably still going to want to meet even if all we want to do is write RFC text, we’ll probably want to meet a few times for that.  Seems to be some agreement for this.

We seem to have agreement as to the structure of the virtual interim presentation.  Moving on to Danny’s analysis of endpoint identity attributes (primary/secondary).

Ron notes that for user certificates as an endpoint identity, it may be the case that that particular user may not be the only user for that endpoint - there could be other users - and that user may be “present” across multiple endpoints.

We are recognizing that our desire for flexibility may be at a crossroads with respect to any “mandatory to implement” issues.  

There are many enterprises out there who use hostnames and FQDNs.  It sounds like Cliff might have that same problem.  What we’re doing, if we demote these things, is to imply that cryptographic information (or other primary attributes) must be available.  In some cases these may also be dynamically assigned (especially FQDNs).  

If Hostname and FQDN (or any other presumed-to-be-identifying attribute) do become secondary, should they be “lumped” under “configuration settings”?  It seems that, among other configuration items, these are “more important” than others - perhaps there needs to be a way to “apply” identification semantics to specific configuration items.

There’s a question about attribute value authority.  For example, what is authoritative for a hostname?  Ron claimed that, strictly speaking, the endpoint itself is authoritative.  

We’re certainly going to have some challenges for MUST and SHOULD when we’re coming up with the RFC text in the information model.  We really like to go with the ideal cases, but the reality is that not all organizations can live up to that ideal; in truth, and while this might change in the future, the threat models for many organizations likely don’t consider the case of lying endpoints (at this time).  

Important question: Is verification a necessary need for primary identifying attributes?  We should have a name for those attributes that can be verified.  Verifiable attributes are what you should prefer.  Unverifiable attributes should not be preferred, but can be used.  This may still have some challenges for normative language in RFC text.  We’re basically having trouble talking about the classes of identifying endpoints.  We have solidly “verifiable identifying attribute”.  We have solidly “unverifiable identifying attribute”.  But, how do we normatively state which of the “unverifiable identifying attributes” can be relied upon?  One suggestion was to look at other characteristics of unverifiable attributes, such as durability (a measure of assurance).  

For security considerations: Mention something about the risk of using unverifiable identifying attributes and/or such unverifiable identifying attributes without durability.

What do we mean by “verifiable” and “durable”?  If it’s mutable, but doesn’t mutate very often, is that durable?  Maybe not.  The mechanism for changing such an attribute might be interesting to consider.  Consider a MAC address.  This can be immutable or mutable, depending on the context.  Generally, a vendor-supplied MAC address could be considered immutable.  On the other hand, there are MAC address rotation schemes (used for security purposes) that would be better considered mutable.  

A real concern with these terms is that verifiability and durability are spectrums.  

In our information model we should indicate which identifying attributes are authenticated, can be authenticated, or would never be.  This speaks to the provenance of an endpoint attribute assertion.  However, verifying the originator of the data is different than knowing the correctness of the data.  

We keep finding problems with “primary” and “secondary”.  So, we’re right now struggling with this particular problem.  

So, let’s say that there are endpoint attributes that we believe can be identifying attributes.  For those identifying attributes, there are properties they may have: verifiability, durability, immutability, authenticate-able.

We can start talking about these “things” and their relationships:
An endpoint has endpoint attributes
An endpoint attribute may be used as an identifying attribute
An identifying attribute is verifiable (or not)
An identifying attribute is immutable (or not)
An identifying attribute is persistent (or not)
Considerations for how often it should be changed
An identifying attribute can be authenticated (or not)
An identifying attribute has a one-to-one relationship to its endpoint
An identifying attribute has a one-to-many relationship to its endpoint
An identifying attribute (class) has a many-to-one relationship to its endpoint
An identifying attribute (class) has a many-to-many relationship to its endpoint

Are “verifiable” and “authenticated” the same thing?  Probably not.

Now, with all of the attribute characteristics, do we need to identify “identifying attributes”, or can we say something along the lines of “preferred endpoint attributes used for endpoint identity should possess the following property sets...”.

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 1 May 2015 18:21:08 +0000

Did the group address identity differentiation versus identity matching?  The initial matching algorithm I deployed had significant problems with making incorrect matches because it couldn't, for example, determine that two device manifests/fingerprints with different NetBIOS FQDNs do not represent the same device, even if they have the same IP/MAC address pairs.

I'm also of the opinion that identifying attributes, compared in groups (e.g. hostname/IP/MAC) taken together and compared between device attribute groups are better indicators of identity matches than any single attribute in the group.  (e.g. your confidence that a person description containing a given height, skin color, hair color, and identifying mark would be a higher "confidence" match if it is the same, for each attribute, when compared with another person description containing attributes that all had the same value than looking at any single attribute, one-at-a-time.)

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 Adam W. Montville
Sent: Friday, May 01, 2015 12:06 PM
To: sacm
Subject: [sacm] Endpoint ID Design Team Meeting Notes: 2015-05-01

Agenda

*	Endpoint Identification Attribute Analysis (see EIDT Summary deck)
*	Next Steps

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

Notes

*	An endpoint has endpoint attributes
*	An endpoint attribute may be used as an identifying attribute
*	An identifying attribute is verifiable (or not)
*	An identifying attribute is immutable (or not)
*	An identifying attribute is persistent (or not)

	*	Considerations for how often it should be changed

*	An identifying attribute can be authenticated (or not)
*	An identifying attribute has a one-to-one relationship to its endpoint
*	An identifying attribute has a one-to-many relationship to its endpoint
*	An identifying attribute (class) has a many-to-one relationship to its endpoint
*	An identifying attribute (class) has a many-to-many relationship to its endpoint