Differentiate semantics of collection results vs. assertions

[adammontville]

This issue was raised during the 2015-04-17 endpoint ID design team meeting. At issue is whether a "collection result" embodies an "assertion", or if the "collection result" is simply an attribute-value pair (AVP). From one perspective, the AVP simply is; from another perspective, the AVP is asserting that the attribute A "has value" V.

[llorenzin]

Resolution - use the term "collection result" to refer to the triple of data source:attribute:value "target endpoint" "has IP address" "$foo" Avoid using the term assertion in relation to collection result. A collection result by itself is not an assertion.

[llorenzin]

Lisa to sync up with Cliff and find out a) whether, and b) if so, why, he prefers the term "assertion" for a collection result.

[llorenzin]

Comments from 9/30 SACM working session call: Jess - entirety of what you get when you collect is the collection result (including metadata - timestamp etc.) Triple by itself is an assertion An assertion is a statement of fact - I have this IP address Henk - comment from Cliff is that by saying this AVP is about a specific target endpoint, collector is enriching the AVP In the SACM domain, there is no free-floating fact - always a minimal assertion Not sure the term "assertion" is necessary Up to us to name the outcome of a SACM component providing information In this problem domain, collection result and assertion may be the same thing, decide what to call it Lisa - would like to pick one name or the other to refer to the AVP / information collected from the target endpoint Henk - not sure what the term "assertion" means in context of SACM domain Collection result might be a better term Josh - assertion is tied nicely to trust assertion / SAML result Collection result is clear Consensus - no change, Lisa to check with Cliff, if no objection we'll use collection result

[jimsch]

I think it would be useful to have, perhaps just in terminology for now, a clear distinction between a single AVP and a collection of AVPs with meta-data (i.e. a collection result).

[adammontville]

Notes from @llorenzin in the comment two days ago lists 'Not sure the term "assertion" is necessary'. As a contributor, I wonder if we should keep it around. An assertion is a statement of fact until it's proven otherwise. A given collector may assert what it believes to be a fact, when another collector may assert something differently to counter the first. An assertion, ultimately, may or may not hold true. For now, we are treating an assertion from a collector as a fact, but in the future we may have a different perspective.

[ncamwing]

I'm good with using the term "collection results" as to me "assertion" has other connotations to which I'm not sure from a standards perspective we can enforce (e.g. what is factual vs. not.....unless we enforce the definition of "assertion" as more of authenticity that the results actually came from the specific provider presenting the info).

As to making a distinction of one vs. a collection.....a collection could also be comprised of a single element, so trying to understand why a distinction is needed?

[llorenzin]

I contacted Cliff about this, and here is his comment: [cliff] An assertion is true or false.

A collection result is a collection. Collections are not true or false.

Truth value is good:

• It makes you pin down what you are saying about the external world. For example, ip-mac links are a collection. But what do they say about the world, precisely? They don't say anything, precisely. And that causes interoperability problems.
• Truth value makes you realize that something false may be asserted. Truth value emphasizes the need (in some environments) for cross-checking, and for asking "who says" questions.

If "assertion" is too laden, perhaps another word can be found that avoids the overload but does give a truth value. "Claim"?

I would be glad to participate in a discussion. [/cliff]

[llorenzin]

LL - collection result is a free-floating piece of data (i.e. MAC-IP association) and an assertion is that that data is from a target endpoint IM - separate operation to evaluate the trustworthiness of that statement - needs to be evaluated based on the collector (from a TNC client might be more reliable than from an external collector) Separate point of - is this believably correct value? LL - one great example is IP-MAC associations - a DHCP server is somewhat authoritative, collector listening in network is less authoritative, could be a hop away helps to know what kind of element is doing the collection IM - also places limitations on freshness - IP-MAC from a DHCP server may have happened months ago, observation is current DR - don't know yet what kind of authentication may be required in order to validate the association between the collector and the endpoint Believe we have something in the requirements to say that in some cases, there must be an option to authenticate and refresh periodically collector may have at least capability of knowing with which authorization the endpoint is trusted

[llorenzin]

NCW - connotation is of some cryptographic binding to what you're asserting LL - don't think that's true in general, don't want it to be true for SACM Others? JL - no DH - don't think so, but have heard people say it needs to be addressed Assertion is a fact about an endpoint at some point in time Beyond that, need to have some way to ensure its integrity IM - in IEEE, TCG/TMS, heavily use ITU online dictionary of security terms - entire ISO/IEEE/IETF They define assertion as "a statement made by an entity without accompanying evidence of its validity" That's how all ITU and ISO standards use assertion Know people think assertion is associated with truth, but truth - that is, evidence - is a separate word DH - +1 LL - that would seem to answer Adam's question that started this whole thread Possible resolution to use the term assertion to mean a collection result associated with the target endpoint it came from Define assertion in the terminology document by reference to the ITU NCW - my vote would be that we just don't use the term assertion LL - based on the ITU definition, why would a collection result published into SACM not be an assertion? IM - if it had no provenance, it's an assertion LL - so you're saying if it has provenance it's disqualified? evidence is different from provenance JFM - under what circumstances would we have a collection result without provenance? LL - never should - data collector is provenance IM - all of our assertions do have provenance LL - I believe our collection results become assertions when the collector states them by publishing them to the SACM ecosystem IM - agree - they are AVPs that have some provenance NCW - long thread here, new readers may have other definitions LL - resolve that by pointing to ITU definition as how we use the term IM - include in our terminology draft the ITU definition LL - anyone else have a concern about defining an assertion as a collection result published into SACM by a collector? no DR - mention the source as the ITU document - think this is the way forward IM - suggest that when we use common security terms, if not in the IETF 4949 glossary or too ambiguous / out of date, use the ITU glossary always says where the latest normative definition is LL - open issue for terminology to sanity-check all entries against the ITU glossary DR - like this approach NCW - can live with this Agreement - define an assertion as a collection result published into SACM by a collector, mention the source as the ITU document No change needed to architecture draft