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

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 23 Jan 2015 11:36:46 -0600

SACM Endpoint ID Design Team Notes
2015-01-23
==================================

Agenda:

	* Reminder:
		- WebEx Chat and SACM Jabber Room
		- Recording will be (is) enabled
	* Note takers?
	* Revisit Temporal Data/ID Attributes
	* Endpoint ID Example Continued
		- Providing provenance information
	* Next Steps

Attendees:
	Adam Montville (SACM WG Host)
	Lisa Lorenzin (Call-in User_4)
	Clifford Kahn
	Henk Birkholz
	Jarrett Lu
	Jessica Fitzgerald-McKay
	Jim Bieda
	Ron Colvin

Overview
========
Both Cliff and Henk, separately, wanted to revisit some information: Whether assertions should be signed, revisit Temporal Data and ID attributes, whether we should expect things like IP addresses and MAC addresses will be available in all cases.  We added this set of conversations to the agenda and carried on.  What follows are the amended notes from last time and our next steps.  

Note that in the interest of making forward progress further discussion on areas already covered should be conducted on the SACM mailing list.

Amended, Ongoing Notes
======================

Scenarios:

	- Scenario A: Software on an endpoint is asserting posture relating to the endpoint's software inventory and configuration.

Endpoint Identity Assertion
---------------------------

	* All endpoint attributes can be used to establish identity
	* We are defining a core set of (primary) attributes that can be used to assert identity in a consistent fashon
	* Other (secondary) attributes can be used to check an identity assertion or to further define the endpoint's identity (e.g. configuration, software inventory, capability)

Attribute/value pairs
---------------------

	Identity attributes (used to determine what the endpoint is; to be provided regardless of other posture attributes):

		* Certificates (e.g., device, user, drive, other hardware)
			- Device mandatory 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 abou the security considerations of insecure DNS deployments
		
		* Interface(s) (comprehensive, if possible)
			- MAC address(es)
			- 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.
		
		* Other cryptographic information (e.g., IPSec Key-hash, HIP-HIT (RFC4423, 5201), 802.1AR)
			- NOTE: Investigate options to determine if they should be included as primary attributes; post a summary of how to use these specs
				- Cliff: HIP-HIT
				- Lisa: IPSec Key - Certificate or Hash - may be transient
				- Henk: 802.1AR - Appendix E in specification
		
		* Tool-specific identitier - provided by the software making the assertion
			- SHOULD be provided
			- 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 softare. NOTE: Need to discuss more.

Temporal Data
-------------

Capture a timestamp when a given AVP was true

	* If periodic, a timestamp at present time
	* If event-based, an interval last-change to present time

A timestamp indicating when the observation is made by the collector

A timestamp indicating when the assertion was received - consumer (e.g., collector, borker, repo)

	* Think about compositional model of assertions - Asserting additional details related to another assertion

Provenance Data
---------------

	The SACM component that made the assertion
		- An assertion of the identity of the software used (e.g., vendor, product, version, etc.)
		- The instance of the software (e.g., the device the software was run on, the installation of the software) - could be an endpoint identity assertion as well - may be the same as the endpoint or different if external to the endpoint
			- Reuse the identity information from the authentication to establish the identity of the reporter.
		- Cryptographic ifnormation that can be used to authenticate the provenance assertion
		- (FOR CONTINUED DISCUSSION) Some questions on the call about if providing provenance information is required in all cases; self-reported - may/should; other-reported - must
	
	The endpoint attribute assertions (if any) on which the assertion is based
	
	Information about the method used to derive the assertion

Other Data
----------

	Endpoint uniquely identified?  True or false; very subjective; ask larger WG

Other Considerations
====================

	* Write security considerations speaking to uniqueness of any identifying attribute - address malicious or accidental cases where uniqueness may be compromised

Future Discussion Points
------------------------

	* Discuss identification information from bios/firmware (e.g. serial numbers, asset tags, VM id) that can be queried on the device using software

NEXT STEPS (Agenda Items to track)
==================================

	* Wrap up temporal data discussion, if needed
	* Discuss providing provenance information
	* Review cryptographic information from Lisa, Cliff, Henk
	* Discuss ID information from BIOS firmware

---

From: Ira McDonald <[email-masked]>
Date: Fri, 23 Jan 2015 15:32:11 -0500

Hi,

I've just read the Endpoint ID Design Team minutes from last week and this
week.

I'd like to comment on this statement in today's minutes:

"Other (secondary) attributes can be used to check an identity assertion or
to further
define the endpoint's identity (e.g. configuration, software inventory,
capability)"

Premise:  Endpoint posture consists of endpoint identity and endpoint state
assertions.

Comment:  Endpoint configuration, software inventory, and capability info
are all
properly characterized as endpoint state assertions.  Conflating them with
endpoint
identity is counterproductive and non-intuitive (for users and
administrators).  The
main exception is endpoint *network* configuration info (datalink, network,
transport
addresses).  This is a weakness of the English word "configuration" in the
SACM
context (and a good reason to avoid the term or always use it with prefix
qualifiers).

BTW - Serial numbers, asset identifiers, etc. are also endpoint identity
assertions
(and sometimes admins configure them) - more reasons to avoid using the
flaky
stand-alone term "configuration" in SACM documents.

Conflating installed software versions (for example) with endpoint identity
assertions
is inherently counterproductive.

<I have now donned my flame-retardant suit...>

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Jan 23, 2015 at 12:36 PM, Adam W. Montville <
[email-masked]> wrote:

> Both Cliff and Henk, separately, wanted to revisit some information:
> Whether assertions should be signed, revisit Temporal Data and ID
> attributes, whether we should expect things like IP addresses and MAC
> addresses will be available in all cases.  We added this set of
> conversations to the agenda and carried on.  What follows are the amended
> notes from last time and our next steps.
>
> Note that in the interest of making forward progress further discussion on
> areas already covered should be conducted on the SACM mailing list.
>
>
> Amended, Ongoing Notes
> ======================
>
> Scenarios:
>
>         - Scenario A: Software on an endpoint is asserting posture
> relating to the endpoint's software inventory and configuration.
>
>         * We are defining a core set of (primary) attributes that can be
> used to assert identity in a consistent fashon
>         * Other (secondary) attributes can be used to check an identity
> assertion or to further define the endpoint's identity (e.g. configuration,
> software inventory, capability)
>
>
> Attribute/value pairs
> ---------------------
>
>         Identity attributes (used to determine what the endpoint is; to be
> provided regardless of other posture attributes):
>
>                         - Consider how to specify type: multiple
> attributes for each type or type qualifier
>
>                         - Interfaces may be nested (e.g., overlay networks
> - VLANs) - NOTE: Need to verify that standardized methods are available to
> do this.
>
>                         - NOTE: Investigate options to determine if they
> should be included as primary attributes; post a summary of how to use
> these specs
>                                 - Cliff: HIP-HIT
>                         - 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
> softare. NOTE: Need to discuss more.
>
>
> Temporal Data
> -------------
>
>         * Think about compositional model of assertions - Asserting
> additional details related to another assertion
>
>
> Provenance Data
> ---------------
>
>                 - The instance of the software (e.g., the device the
> software was run on, the installation of the software) - could be an
> endpoint identity assertion as well - may be the same as the endpoint or
> different if external to the endpoint
>                         - Reuse the identity information from the
> authentication to establish the identity of the reporter.
>                 - (FOR CONTINUED DISCUSSION) Some questions on the call
> about if providing provenance information is required in all cases;
> self-reported - may/should; other-reported - must
>
>         * Write security considerations speaking to uniqueness of any
> identifying attribute - address malicious or accidental cases where
> uniqueness may be compromised
>
> Future Discussion Points
> ------------------------
>
>         * Discuss identification information from bios/firmware (e.g.
> serial numbers, asset tags, VM id) that can be queried on the device using
> software
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 23 Jan 2015 22:06:33 +0000

I don’t think we can separate endpoint identity and endpoint state assertions. Here is my thinking on this:

Axiom #1: Endpoint posture consists of the set of all configuration items.

Typically, the set of all posture attributes on an endpoint is defined by all available configuration items on the device. I use the term “configuration item” to refer generally to all hardware, software, and software configuration settings. In the last case I am also including configuration of bios and other firmware. I guess capability would also fit into this as well.

Axiom #2: Endpoint posture is asserted as a set of endpoint posture attribute/value pairs.

Each endpoint posture attribute represents a specific instance of hardware, software, or a software configuration setting.

Axiom #3: A set of endpoint posture attributes exists that is generally useful for identifying endpoints.

Let’s call this set “primary identifying attributes”. By “generally” I mean useful on many, but maybe not all types of endpoints or deployment scenarios. These are the attributes that we want to call out to provide a minimal level of interoperability for identification. If the attribute exists on the endpoint and the collecting software can interrogate it, the attribute must be provided. This is what we are focusing our efforts on in the design team meetings.

Axiom #4: The set of identifying attributes is a subset of the set of all endpoint posture attributes.

I don’t see much value in differentiating configuration settings vs. identifying attributes. In most cases identifying attributes are configurable. In some cases, identifying attributes may also be assessed for compliance. I think it is easier to think of an identifying attribute as a special type of posture attribute.

Axiom #5: Some portion of the remaining endpoint attributes not in the set of “primary identifying attributes” may also be useful in identifying the endpoint in specialized cases.

Let’s call this set “secondary identifying attributes”. These are the things that don’t make the cut in the first set because they do not have broad enough applicability to be standardized and/or required to be provided if available. I know this is somewhat blurry, but I don’t see a good way around this.

I agree with Ira; I do not see installed software attributes fitting either the primary or secondary case. We need to talk more about the concept of capability as well. Capabilities may also fall into the secondary category, but I am not sure at this point.

Any thoughts on the above?

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Friday, January 23, 2015 3:32 PM
To: Adam W. Montville; Ira McDonald
Cc: [email-masked]
Subject: Re: [sacm] Endpoint ID Design Team 2015-01-23 Notes

Hi,

I've just read the Endpoint ID Design Team minutes from last week and this week.

"Other (secondary) attributes can be used to check an identity assertion or to further
define the endpoint's identity (e.g. configuration, software inventory, capability)"

Premise:  Endpoint posture consists of endpoint identity and endpoint state assertions.

Comment:  Endpoint configuration, software inventory, and capability info are all
properly characterized as endpoint state assertions.  Conflating them with endpoint
identity is counterproductive and non-intuitive (for users and administrators).  The
main exception is endpoint *network* configuration info (datalink, network, transport
addresses).  This is a weakness of the English word "configuration" in the SACM
context (and a good reason to avoid the term or always use it with prefix qualifiers).

BTW - Serial numbers, asset identifiers, etc. are also endpoint identity assertions
(and sometimes admins configure them) - more reasons to avoid using the flaky
stand-alone term "configuration" in SACM documents.

Conflating installed software versions (for example) with endpoint identity assertions
is inherently counterproductive.

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Fri, Jan 23, 2015 at 12:36 PM, Adam W. Montville <[email-masked]<mailto:[email-masked]>> wrote:
SACM Endpoint ID Design Team Notes
2015-01-23
==================================

Agenda:

        * Reminder:

Attendees:

Overview
========

Amended, Ongoing Notes
======================

Scenarios:

Attribute/value pairs
---------------------

Temporal Data
-------------

Provenance Data
---------------

Other Data
----------

Other Considerations
====================

Future Discussion Points
------------------------

[email-masked]<mailto:[email-masked]>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 23 Jan 2015 18:38:32 -0500

Hi Dave,

TCG and some other folks (ITU-T for example) have distinguished endpoint
attributes *in a given environment* as being useful for identity (and
therefore
termed endpoint identity assertions) or more properly state (running state
of hardware and software, manifests of software, current configuration of
access control and user/device rights in general, capabilities of hardware
and software, etc.).

The distinction is useful in the real world, because database records are
going
to have keys (I hope) that comprise a set of identity assertions for
efficient
subsequent correlation of logs.

I don't like discarding the idea of endpoint state as separable from
endpoint
identity.  But perhaps that's what the SACM community wants.

Cheers,
- Ira

On Fri, Jan 23, 2015 at 5:06 PM, Waltermire, David A. <
[email-masked]> wrote:

> Typically, the set of all posture attributes on an endpoint is defined by
> all available configuration items on the device. I use the term
> “configuration item” to refer generally to all hardware, software, and
> software configuration settings. In the last case I am also including
> configuration of bios and other firmware. I guess capability would also fit
> into this as well.
>
>
>
> Each endpoint posture attribute represents a specific instance of
> hardware, software, or a software configuration setting.
>
>
>
> Let’s call this set “primary identifying attributes”. By “generally” I
> mean useful on many, but maybe not all types of endpoints or deployment
> scenarios. These are the attributes that we want to call out to provide a
> minimal level of interoperability for identification. If the attribute
> exists on the endpoint and the collecting software can interrogate it, the
> attribute must be provided. This is what we are focusing our efforts on in
> the design team meetings.
>
>
>
> I don’t see much value in differentiating configuration settings vs.
> identifying attributes. In most cases identifying attributes are
> configurable. In some cases, identifying attributes may also be assessed
> for compliance. I think it is easier to think of an identifying attribute
> as a special type of posture attribute.
>
>
>
> Axiom #5: Some portion of the remaining endpoint attributes not in the set
> of “primary identifying attributes” may also be useful in identifying the
> endpoint in specialized cases.
>
>
>
> Let’s call this set “secondary identifying attributes”. These are the
> things that don’t make the cut in the first set because they do not have
> broad enough applicability to be standardized and/or required to be
> provided if available. I know this is somewhat blurry, but I don’t see a
> good way around this.
>
>
>
> I agree with Ira; I do not see installed software attributes fitting
> either the primary or secondary case. We need to talk more about the
> concept of capability as well. Capabilities may also fall into the
> secondary category, but I am not sure at this point.
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Ira McDonald
> *Sent:* Friday, January 23, 2015 3:32 PM
> *To:* Adam W. Montville; Ira McDonald
> *Cc:* [email-masked]
> *Subject:* Re: [sacm] Endpoint ID Design Team 2015-01-23 Notes
>
>
>
> Hi,
>

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 25 Jan 2015 12:21:27 -0500

Hi Dave, Adam,

There are some groups attempting to develop
SACM capabilities for NFV implementations
where the end points may be quite transient
- instantiated during a designated time period
for a particular Forwarding Graph and Service
Deployment Flavor.

Is the design team considering SACM uses in
an NFV environment?  I'm cross copying the
newly started NFV IRTF group which is considering
NFV security mechanisms.  It's possible perhaps
to conceptualize SACM implementations as NFV
Service Deployment Flavors.

--tony

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 26 Jan 2015 16:55:14 +0000

Hi Tony,

The idea of considering SACM for NFV deployments sounds promising and certainly aligned with the short-term goal of the NFVRG aimed at service verification. I'd like to explore the possibilities, including knowing better what a Service Deployment Flavor is...

Be goode,

On 25 Jan 2015, at 18:21 , Tony Rutkowski <[email-masked]> wrote:

> Nfvrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nfvrg

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição