is whether or not attributes were collected in an authenticated or unauthenticated manner metadata we care about?

[djhaynes]

As part of feedback on the vulnerability assessment scenario, it was asked if authenticated data always takes precedence over unauthenticated data. This needs to be discussed further, but, we should consider whether or not attributes were collected in a authenticated or unauthenticated manner is metadata that we care about and if we should include it in the information model (e.g. similar how we want to capture if an attribute can be used for designation/identification or if it is has privacy concerns).

Please see the following mailing list thread for more information.

http://www.ietf.org/mail-archive/web/sacm/current/msg03597.html

[henkbirkholz]

This issue is probably related to the domain of data provenance.

What I understand: Just reading the text "authenticated data always takes precedence over unauthenticated data" implies that the data is collected from a data source/target endpoint (as data origins inside a sacm domain should always be authenticated and easy to identify).

This would be valuable provenance metadata that could be consumed by post-processing sacm components.

There was a similar question about "transport method" (e.g. encrypted or unencrypted transport, not to be confused with sacm transport that is used between sacm components) on the list that might be related to this one, I think.

There are probably other factors that can also be used to assess "confidence in integrity" or "level of assurance".

[djhaynes]

Agree.

If the WG agrees that authenticated data always takes precedence over unauthenticated data, I think you are correct. However, another option might be to make this precedence configurable in evaluation guidance. Yet another option might be to define an algorithm that specifies how precedence should be handled and when. Anyways, thinking through these options and how we want to handle this is where I think we need further discussion.

Agree.

Do you have a pointer to the question on the list?

Agree.

[sacm]

Hi Danny,

I would agree that authenticated data should always take precedence over unauthenticated data (i.e., an administrator should not be able to choose to believe unauthenticated data over authenticated data when policies are to be evaluated).

But I have a naïve question: Is all authenticated data "created equal"? That is, don't we want to consider the quality of the authentication (e.g., certificate versus multi-factor authentication).

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: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Thu, Jan 7, 2016 at 9:52 AM, Danny Haynes notifications@github.com wrote:

Agree.

If the WG agrees that authenticated data always takes precedence over unauthenticated data, I think you are correct. However, another option might be to make this precedence configurable in evaluation guidance. Yet another option might be to define an algorithm that specifies how precedence should be handled and when. Anyways, thinking through these options and how we want to handle this is where I think we need further discussion.

Agree.

Do you have a pointer to the question on the list?

Agree.

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/35#issuecomment-169685109 .

---

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

[djhaynes]

That is a good question and I don't know that I have a definitive answer. Although, I do agree that all authenticated data is not necessarily created equal. It probably depends on the details of the authentication mechanisms. For example, what if the multi-factor authentication includes a mandatory 25-character password, passcode token, fingerprint recognition, and a key to get into the only room where the endpoint/service can be accessed/activated from. That seems like it would be equivalent to a certificate (at least for practical purposes) :).

I think when we start getting into the "quality" of something whether it is authentication, collected data, etc. it starts to get very subjective and will likely be something that is dependent on the organization deploying the SACM ecosystem and their risk tolerance.

In these cases, I don't think we want to mandate a specific behavior. Rather, I think we want to provide organizations with the information and mechanisms to tailor the SACM ecosystem to address their needs and tolerances. Of course, we need to be careful not to create something that is overly complex and unusable.

[stevensj]

Agree. Good discussion and great point on the slippery slope related to varying quality levels of authenticated results - for example a limited privileges service account vs. root level permissions will differ in scan accuracy. However, if there is an opportunity provide a high level category or an ability to notate a greater trust to authenticated data in the event it is compared to a future unauthenticated result - ideally this could accommodate broader enterprise vulnerability programs.

[henkbirkholz]

Maybe the IM could provide a (optional) set of categories to be rated/scored in regard to a collection task, e.g. level of authentication, level of transport encryption, level of attestation, level of privilege, level of assurance (these are just examples from the top of my head). I am not sure if this goes into the right direction or down a slippery slope, though. These would be a set of attributes we can define in the IM, I think. How scope and meaning of the values are defined or interpreted could be sacm domain specific (similar to a framework, maybe including an informational guidance document to elaborate on common practice later on).

[henkbirkholz]

Do you have a pointer to the question on the list?

I cannot seem to find it again... maybe the corresponding contributor is reading this?