Endpoint Identity Design Team Concepts 2/9/2015

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

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

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?

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.

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

Endpoint Identity Assertions

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

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.

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.

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

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.

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!

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.

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”

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

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)

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

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

Challenges

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?

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?

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?

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?

Next Steps

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

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