Subject: [sacm] Definition of endpoint attribute assertion

From: Clifford Kahn <[email-masked]>
Date: Mon, 8 Dec 2014 11:46:52 +0000

At the meeting, there was a feeling that the definition of "endpoint attribute assertion" needed improving. The concept is pivotal. Here's a try. 

I would add one sentence at the beginning, and would reorder the text. The definition would read like this:

An endpoint attribute assertion represents a direct observation by an attribute collector, or a conclusion drawn by an evaluator. It asserts that specified attribute-value pairs were true of some endpoint, throughout a specified time interval.  An endpoint attribute assertion has: 
* One or more attribute-value pairs (AVPs)
* A time interval over which the assertion holds
* Endpoint uniquely identified? True or false
* Provenance, including: 
    o The SACM component that made the assertion
    o The endpoint attribute assertions (if any) on which this assertion is based
    o Information about the method used to derive the assertion

Clifford Kahn
Principal Engineer/Technical Lead

---

From: Ira McDonald <[email-masked]>
Date: Mon, 8 Dec 2014 14:57:53 -0500

Hi Cliff,

+1 - good summary.

Cheers,
- Ira

On Mon, Dec 8, 2014 at 6:46 AM, Clifford Kahn <[email-masked]>
wrote:

> At the meeting, there was a feeling that the definition of "endpoint
> attribute assertion" needed improving. The concept is pivotal. Here's a try.
>
> An endpoint attribute assertion represents a direct observation by an
> attribute collector, or a conclusion drawn by an evaluator. It asserts that
> specified attribute-value pairs were true of some endpoint, throughout a
> specified time interval.  An endpoint attribute assertion has:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 8 Dec 2014 22:36:18 +0000

To me your definition defines both an endpoint attribute assertion and a rough model for asserting an endpoint identity.

This being said, I believe an “endpoint attribute assertion” can serve a dual purpose from an information model perspective. In addition to asserting an endpoint identity it can contain additional assertions on endpoint posture for the purpose of communicating endpoint posture. True?

On the Endpoint ID Design Team call we also defined an “Identifying Attribute” which is an AVP in your definition for “endpoint attribute assertion.”

An “Identifying Attribute” is defined as: an observation made at a specific point in time that can be used standalone or in combination with other observations to identify an endpoint; a subset of endpoint attributes.

If so, is it important to indicate that an AVP is part of the set of AVPs that assert an endpoint identity vs. the set of AVPs that are simply assertions of endpoint posture?

Another way to look at this is the endpoint identity is part of the “header” while the endpoint posture is part of the “body”. Is this an important distinction? Some prior work in this area (e.g., SCAP) makes this type of distinction, which is why I am asking.

One reason for this type of distinction is it is often not possible to express endpoint posture using simple attribute-value pairs. For example, for configuration settings, you need to express the software instance for which the setting is applied to, the name of the setting, and multiple properties of the setting value to include its datatype and actual value. Does this same complexity exist for identifying attributes?

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Monday, December 08, 2014 2:58 PM
To: Clifford Kahn; Ira McDonald
Cc: [email-masked]
Subject: Re: [sacm] Definition of endpoint attribute assertion

Hi Cliff,

+1 - good summary.

Cheers,
- Ira

On Mon, Dec 8, 2014 at 6:46 AM, Clifford Kahn <[email-masked]<mailto:[email-masked]>> wrote:
At the meeting, there was a feeling that the definition of "endpoint attribute assertion" needed improving. The concept is pivotal. Here's a try.

Clifford Kahn

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Clifford Kahn <[email-masked]>
Date: Tue, 9 Dec 2014 02:59:33 +0000

Dave,
Great questions. You write:

➢ This being said, I believe an “endpoint attribute assertion” can serve a dual purpose from an information model perspective. In addition to asserting an endpoint identity it can contain additional assertions on endpoint posture for the purpose of communicating endpoint posture. True?

Yes. We are on the same page. 

You write:

➢ Another way to look at this is the endpoint identity is part of the “header” while the endpoint posture is part of the “body”. Is this an important distinction? Some prior work in this area (e.g., SCAP) makes this type of distinction, which is why I am asking.

The latest draft takes the view that this distinction is *not* sharp. I think it is not sharp.  

Let’s get concrete. Some seemingly obvious identifying attributes for SACM follow:
- Machine account names (for example, from Active Directory or from a Trusted Platform Module )
- Addresses (IP, MAC, etc)
- Unique identifiers, assigned for inventory and SACM purposes

We need addresses as identifying attributes, because often, an address is the best identifying attribute available to a network sensor. 

Can an address also be subject to compliance rules? I suggest it can. Address is a clue to location. If an endpoint’s address indicates that it is in a less protected location than it should be, that endpoint may need scrutiny. 

What about the account name of the user using an endpoint?  Clearly that account name does not, in any simple way, identify the endpoint. It can, however, be an excellent clue to the endpoint's identity in a very common case, which I will explain below. The account name can be a compliance factor as well. If someone unusual or untrusted signs into an endpoint, one might lower one’s trust in the endpoint’s integrity. 

So, both address and user account name can plausibly be identifying attributes *and* compliance attributes. 

I suspect we can easily find many more such examples.  

Is the distinction between "identifying" attributes and "posture" attributes important? If it's not, we should just simplify by erasing it. (Occam's razor.) 

I do see some import. An implementation needs to know which attributes are frequently used as keys. Identifying attributes are frequently used as keys. 

You write:

➢ One reason for this type of distinction is it is often not possible to express endpoint posture using simple attribute-value pairs. For example, for configuration settings, you need to express the software instance for which the setting is applied to, the name of the setting, and multiple properties of the setting value to include its datatype and actual value. Does this same complexity exist for identifying attributes?

I think the draft says that the values in the attribute-value pairs can be structured -- for example, XML -- for example, YANG descriptions. 

I suggest that identifying attributes can be structured. Location (for example) can consist of a room number, floor, building address, VLAN ID, and geo-location, at least. There is a case for using location to distinguish two endpoints. If my endpoint's MAC address occurs in another country, the odds are it's not my endpoint -- unless I'm known to be on location in that country. 

I do not see structured values for identifying attributes creating a *semantic* problem. Queries can select based on structured properties. XPath, for example, does that.  I think the problem is not *semantics* but *efficiency*. 

I suggest we try not to *preclude* structured identifying attributes, but that we also don't work hard on perfecting them. If they are valuable, industry will innovate, and standardization will come later. 

Here is my very realistic usage scenario:
1. Sue brings her smart phone to work and registers it as a Bring Your Own Device. The registration system allocates a unique ID for the device, and creates a long-lived endpoint attribute assertion saying:
a. Unique ID = 
b. User account = Sue (denoted by username, distinguished name, or whatever) 
c. MAC address = 012345-6789ab
d. etc
Sue may log into several endpoints. The MAC address differentiates the endpoints Sue logs into. A MAC address alone is not a great unique identifier. But the MAC address + the user account is better.  

2. At a later time, Sue’s smart phone signs into a wireless access point, using 802.1X. During the sign-in, the RADIUS server learns the username (because she authenticated) and the MAC address (because that comes as a RADIUS attribute). The RADIUS server creates an endpoint attribute assertion saying:
a. User account = Sue
b. MAC address = 012345-6789ab
c. Etc

3. The wireless access point performs DHCP snooping. As soon as Sue’s smart phone gets an IP address, the WAP tells the RADIUS server (with a RADIUS Accounting attribute, if you really want to know). The RADIUS server adds the IP address to the already published endpoint attribute assertion. 
a. User account = Sue
b. MAC address = 012345-6789ab
c. IP address = 1.2.3.4
d. Etc

4. A network sensor observes something about the compliance of Sue’s smart phone. This observation takes the form of an endpoint attribute assertion that includes the phone’s current IP address. 

5. By joining the three assertions, an evaluator can connect the sensor’s observation to the phone’s unique ID. 

Note that the user account is an essential identifying attribute for this scenario. 

It seems likely that many other attributes will be found useful for identifying endpoints, depending on the situation. 

Sorry for the motor-fingers. 

Best,
			Cliff

From: Waltermire, David A. [mailto:[email-masked]] 
Sent: Monday, December 08, 2014 5:36 PM
To: Ira McDonald; Clifford Kahn
Cc: [email-masked]
Subject: RE: [sacm] Definition of endpoint attribute assertion

Thanks,
Dave

Hi Cliff,

+1 - good summary.

Cheers,
- Ira

On Mon, Dec 8, 2014 at 6:46 AM, Clifford Kahn <[email-masked]> wrote:
At the meeting, there was a feeling that the definition of "endpoint attribute assertion" needed improving. The concept is pivotal. Here's a try.

Clifford Kahn