1. Endpoint Identity Design Team Concepts
2/9/2015

2. Agenda Review terminology Discuss Endpoint Identity Assertion Model
Discuss Challenges
Discuss next steps

3. Primary Goals Define terminology
Provide an model to assert a set of identifying attributes that can be related to an endpoint observation.
Record the observer and time of observation
Describe the provenance of the identity assertion (e.g., identity, non-repudiation)
Provide for extensibility of identifying attributes and provenance data
Enable association of well-known endpoint identifiers chosen by a tool or organization
Enable correlation between different observations, over time, based on associated sets of identifying attributes
Assertions must be made with sufficient breadth to enable inferences to be made that separate observations are about the same endpoint
Focus on direct posture observation via clients and management protocols initially, network based observation secondly

4. Secondary Goals
Standardize a method to assert confidence over an identity assertion – Establish requirements
Provide confidence examples:
Authoritativeness - DHCP assignment of IP address vs. host assertion?
What are the interoperability concerns here?
Perhaps also exchange of confidence information? Reputation of the sender?

5. Terminology
Posture Attribute - From [RFC5209] as "attribute describing the configuration or status (posture) of a feature of the endpoint. A Posture Attribute represents a single property of an observed state."
Endpoint Attribute Assertion –Represents a direct observation by an attribute collector, or a conclusion drawn by an evaluator. It asserts that specified posture attribute-value pairs were true of some endpoint, at a specific time or throughout a specified time interval.
Identifying Attribute
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 posture attributes
Endpoint Identity Assertion - An Endpoint Attribute Assertion containing a subset of endpoint attributes (Identifying Attributes) used to establish endpoint identity.

6. Terminology (Continued)
All endpoint attributes can be used to establish identity, but not all attributes are as well suited.
Classes of Identifying Attributes
Primary
Available - Present on most platforms
Stable - Change infrequently
Authentic - High level of assurance, attributes can be authenticated
Secondary
Can be used to check an identity assertion or to further define the endpoint's identity (e.g. configuration, software inventory, capability)
Limited scope – Might not assist with identifying an endpoint across sessions

7. Endpoint Identity Assertions

8. Our working scenario
Software on an endpoint is asserting posture relating to the endpoint's software inventory and configuration state

9. An Endpoint Identity Assertion
Contents:
A set of identifying attributes
Provenance data
Each Identifying Attribute-value pair (AVP) will include 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
Other considerations:
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.

10. Endpoint Identifying Attributes
Primary candidates include:
Certificates (e.g., device, user, drive, other hardware)
MUST be provided 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 about the security considerations of insecure DNS deployments
Network Interface(s) (comprehensive, if possible)
MAC and 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.

11. Endpoint Identifying Attributes (Continued)
Primary candidates also include:
Tool-specific Identifier - provided by the software making the assertion
SHOULD be provided if available
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 software. 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
Other cryptographic information

12. Other Sources of Cryptographic Information
We investigated options to determine if they should be included as primary attributes:
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)
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.

13. Other Sources of Cryptographic Information (Cont’d)
We investigated options to determine if they should be included as primary attributes:
802.1AR
The standard's intent is to support unattended operation
Appendix B in specification discusses use of TPM
A strong, globally unique identifier (re: iDevID - preinstalled; eDevID - enterprise defined).
iDevID can be generated specifically for SACM uses
Any xDevID has to have 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.
Thanks to Cliff, Lisa, and Henk for their research!

14. Use of public keys 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 to verify the assertion.

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

16. W3C Provenance Model 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
 Method (“Process” in W3C terminology)
How did you go about harvesting / making the observation
How was the observation communicated
Basis

17. Provenance Examples
Goal is to associate IP address with Unique endpoint ID.
Endpoint self-reports
Third-party assigning IP address reporting (e.g. IP address mgt sys)
Third-party observer (e.g. profiler, infrastructure witnessing traffic)

18. +---------+ +---------+ +--------+____________________
|Hardware | |Software | __________|Location|*_______________ |
|Component| |Component| | * * | |
| | |
| | | | |
|* |* | ______|Credential|____________ | |
| | * * |* |* |
|Hardware | |Software| | | |
|Instance | |Instance| | | |Network |_______|Account| |
| | |Session |* |
|* |* *| *| | | *|
| |____ ______*|Network |__________
|_____________| Endpoint |_____ |Interface|* *|Address|
1| |0..1 |
| |
_____________|1 |* | |_____
| |________| *|Authorization|
| part-of> |
| |0..1
| |
| |*
| ___________________
| | AVP |____________|Endpoint |* <based-on |
^| * |Attribute|________ |
hosted-by| *| |Assertion|* | |
| | | |
| |produced-using |* |* | *|
| |V | |__________|
| | <based-on |Summary|
| | Method | |
| |produced-by *|
|____________________ |V |
|* | |
____________* |
| | guides> | SACM |__________________________|
|Guidance| | Component | <produced-by
*____________
<produced-by
..... Above this line is the monitorable world

19. Current Work - W3C Provenance Model
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.
Discussion:
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?
Is there any way to generalize the notion of chain of custody, method, basis, to then generalize “confidence”?
Chain of custody considerations

20. Challenges

21. Uniqueness and Cloning
Some identification data is subject to cloning
Virtualization: creating a copy of the endpoint
Assignment: assigning the same identification data to different endpoints
Some identification data is clone resistant (e.g. hardware-rooted device certificates)
How can SACM account for this?

22. Mutability of Endpoints
While some identification data may be stable, some changes to the endpoint may change the devices intended purpose (e.g., a change in operating system, replacing hardware)
Does this matter? If so, do we provide any guidance to address this?

23. Visibility Limits and Context
Some observations will not provide enough context
NAT scenarios where only private addresses are known to the observer?
How can SACM account for this?

24. Uncertainty There are no facts, only assertions
Identification data may be falsified
Need to cross check observations and inferences against each other
How does SACM account for corroboration using multiple methods?
How does SACM consider the reputation of the observer? Or the inferrer?
Is providing provenance data sufficient to address uncertainty?

25. Next Steps

26. Next Steps Continue Endpoint Identity Design Team discussions
Continued Provenance discussion at next meeting (February 13)
Need to update the Information Model for SACM F2F Meeting
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

27. Future Work
Consider the “comment” mechanism as in IF-MAP - possibly something that can come later (subsequent SACM “phase”).