Subject: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 23 Apr 2014 23:37:11 +0000

My apologies; I had hoped to post this message earlier, but I have been experiencing some computer problems that made editing impossible.

Thanks for all the comments on the draft!

The following six questions represent the remaining identified issues with the use cases document. These issues where posted to this list prior to the IETF 89 meeting and were discussed at that meeting. Based on the feedback received on the list and at the meeting, I have created an updated set of proposed changes to the -06 use cases. These reasoning behind these changes are described in the following, along with proposed text modifications indicated by text in [square brackets].

Please let me know if you have any concerns with these changes. If there are any specific concerns that cannot be resolved on the list, we will discuss them at the virtual meeting and reconfirm on the list.

The draft is nearing a point where we can begin WG last call shortly after the virtual meeting. If you have any additional issues with the -06 draft, please provide comments in a separate thread. We can discuss them at the virtual meeting as well to keep things moving forward.

Chairs, I am happy to post an -07 draft as early as tomorrow based on these changes. It would be good to post an update at least a couple days before the virtual interim meeting to allow the full text to be considered. In doing this, we can always revert any changes as needed if any concerns are raised. I can also hold off if that is preferred as well. Please advise.

Regards,
Dave

Question #1: Should section 2.1.2 make use of authentication information pertaining to discovered target?

Resolution (modified based on discussion at the IETF 89 SACM WG meeting):

The Endpoint Discovery building block may use information that was previously defined by humans and/or collected using automation to determine the current or historic presence of endpoints in the environment. It was suggested to include available authentication information as a source for identifying discovered endpoints.

Proposed text change:

2.1.2.  Endpoint Identification and Assessment Planning

{snip}

   Endpoint Discovery:  To determine the current or historic presence of

         endpoints in the environment that are available for posture

         assessment.  [In support of discovery, endpoints are identified

         using information previously obtained when the device

         authenticated to a network or using other collection mechanisms

         to gather identification and characterization data.]

Question #2: In section 2.1.2: Are we missing a building block that determines what previously collected data, if any, is suitable for evaluation and what data needs to be actually collected?  Should a building block be identified that evaluates existing data to determine if it is current enough for use in the evaluation or if current data should be collected anyway according to a policy?

Resolution (modified based on discussion at the IETF 89 SACM WG meeting):

Add text to the building block "Posture Attribute Identification" to address analysis of previously collected data to determine what additional data, if any, to collect.

Proposed text change:

2.1.2.  Endpoint Identification and Assessment Planning

{snip}

   Posture Attribute Identification:  Once the endpoint targets and
         [component
         their associated asset] inventory is known, it is then necessary
         to calculate what posture attributes are required to be
         collected to perform the [desired] evaluation.  [If existing
         stores of posture data are available, they are queried using
         the Data Query building block (see section 2.1.1) to determine
         what previously collected posture data, if any, is suitable for
         the evaluation.  Retrieved data is analyzed to determine if it
         is complete and current enough for use in the evaluation.  Any
         unsuitable or missing posture data is identified for
         collection.]

         If this is driven by guidance, then the Data Query and/or Data
         Retrieval building blocks (see section 2.1.1) may be used to
         acquire this data.

Question #3: In section 2.1.4: Posture Attribute Evaluation, what if data is unavailable or is not current enough to support the evaluation? This could be caused if collection did not occur (for some reason) and previous collection was too old.

Resolution (modified based on discussion at the IETF 89 SACM WG meeting):

The WG discussion identified the following characteristics to be addressed:

*         Knowing the "liveliness" of the information is important. For example when was the data acquired.

*         For a set of results, what was the provenance of the data used to generate the results.

*         What is the level of assurance of the results from assessing the data. Recognize that the process will have "shades of grey."

Proposed text changes:

2.1.4.  Posture Evaluation

{snip}

   The building blocks of this use case are:

{snip}

   Posture Attribute Value Query:  If previously collected posture
         attribute values are needed, the appropriate data stores are
         queried to retrieve them[. using the Data Query building block
         (see section 2.1.1).]  If all posture attribute values are
         provided directly for evaluation, then this capability may not
         be needed.

{snip}

   Posture Attribute Evaluation:  The comparison of posture attribute
         values against their expected results as expressed in the
         specified guidance.  The result of this comparison is output as
         a set of posture evaluation results.  [Such results include any
         information needed to understand the posture attribute data
         used in the evaluation, the provenance (e.g., liveliness,
         source) of this data, or if any data was unavailable for
         analysis.  This will enable consumers of the results to
         determine a level of assurance over the result set.]

Questions #4 & 5: The end of section 2.1.4 states "Completion of this process represents a complete assessment cycle as defined in Section 2." Since this indicates completion of the section 2 process, it would be reasonable for section 2.2 to follow. However, an additional use case section 2.1.5 follows. Section 2.1.5 has been commented on as being duplicative of the previous use case in section 2.1.4 with the exception of the "Change Detection" building block. Suggest integrating the content into section 2.1.4.

Resolution (modified based on discussion at the IETF 89 SACM WG meeting):

The WG discussion identified that evaluation should mean general evaluation. While posture assessment of expected vs. actual state is defined in the charter, evaluators will need to do other types of analysis as well (e.g., trending, retro-active analysis, etc.) The evaluation use case should not be so restrictive that makes other types of assessment impossible. Based on the feedback, an integration of sections 2.1.4 and 2.1.5 has been made that simplifies the use cases, while addressing the intent of both sections.

It was also suggested that the section should be renamed "Posture Attribute Evaluation".

Proposed text changes:

2.1.4.  Posture [Attribute] Evaluation

   This use case [describes represents the process action] of [evaluating analyzing] collected posture
   attribute values [representing as part of an assessment.  The primary focus of this
   use case is to support evaluation of] actual endpoint state against
   the expected state selected for the assessment.

{snip}

   The building blocks of this use case are:

   [Collected Posture Change Detection:  An operator or application has a
         mechanism to detect the availability of new or changes to
         existing posture attribute values.  The timeliness of detection
         may vary from immediate to on-demand.  Having the ability to
         filter what changes are detected will allow the operator to
         focus on the changes that are relevant to their use and will
         enable evaluation to occur dynamically based on detected
         changes.]

{snip}

   [While the primary focus of this use cases is around enabling the
   comparison of expected vs. actual state, the same building blocks will
   support other analysis techniques that can be applied to collected
   posture attribute data (e.g., trending, historic analysis).]

   Completion of this process represents a complete assessment cycle as
   defined in Section 2.

Question #6: In section 2.2.4, should we include other building block references?

Resolution (unchanged):

Suggest making no changes as it appears that the current referenced building block adequately covers the usage scenario.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 24 Apr 2014 10:37:02 +0000

All - please consider the proposed changes and send your comments NOW.

David - I suggest that you post the update on Monday morning the latest, which would be roughly 48 hours before the virtual interim.

Thanks and Regards,

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Thursday, April 24, 2014 2:37 AM
To: [email-masked]
Subject: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

Regards,
Dave

Proposed text change:

{snip}

Proposed text change:

{snip}

Proposed text changes:

{snip}

{snip}

{snip}

Proposed text changes:

{snip}

{snip}

Resolution (unchanged):

---

From: Adam Montville <[email-masked]>
Date: Thu, 24 Apr 2014 16:40:38 -0500

Dave, thanks for sending this out.  

I'll be sending my comments for each proposal individually.  Most are pretty benign comments about readability and such.

>          to gather identification and characterization data.]

Does this proposed addition imply a preference for "information previously obtained when the device authenticated to a network" over "other collection mechanisms" as it is written?  Also, would it be any easier to read if "in support of discovery" were removed?

---

From: Adam Montville <[email-masked]>
Date: Thu, 24 Apr 2014 16:41:26 -0500

>          Retrieval building blocks (see section 2.1.1) may be used to

The larger block of text being proposed might be easier to read like this: "Existing posture data is queried for suitability using the Data Query building block (see section 2.1.1).  Such posture data is suitable if it is complete and current enough for use in the evaluation.  Any unsuitable posture data is identified for collection."

---

From: Adam Montville <[email-masked]>
Date: Thu, 24 Apr 2014 16:42:09 -0500

On Apr 23, 2014, at 6:37 PM, Waltermire, David A. <[email-masked]> wrote:

> ·         Knowing the “liveliness” of the information is important. For example when was the data acquired.
> ·         For a set of results, what was the provenance of the data used to generate the results.
> ·         What is the level of assurance of the results from assessing the data. Recognize that the process will have “shades of grey.”
>  
> Proposed text changes:
>  

Did we mean to say "expected results" or "expected values" in that first sentence (not part of the proposal)?

The previous WG discussion identified "liveness", provenance, and results assurance.  I understand why the proposed text has been added to address these three bullet points.  But, it also seems that what's being proposed is really just a single "bucket" which then describes qualities of the things we might put into that bucket.  In other words, it's presenting a list (just as the bulleted list does) that starts with what we want and then presents examples of what we want as a continuance of what we want. 

Is this equivalent to what we want to see written?  "Such results include metadata required to provide a level of assurance with respect to the posture attribute data and, therefore, evaluation results.  Examples of such metadata include provenance and or availability data."

---

From: Adam Montville <[email-masked]>
Date: Thu, 24 Apr 2014 16:43:48 -0500

On Apr 23, 2014, at 6:37 PM, Waltermire, David A. <[email-masked]> wrote:

> It was also suggested that the section should be renamed “Posture Attribute Evaluation”.
>  
> Proposed text changes:
>  

A bit of a nit, but I like the use of commas after "new" and "existing" respectively.  It's probably grammatically correct as written, but it feels easier to read (to me) when it looks like this: "An operator or application has a mechanism to detect the availability of new, or changes to existing, posture attribute values.  

>    posture attribute data (e.g., trending, historic analysis).]

Would there be any reason here to include something about "other analysis techniques" being out of scope to our expected set of specifications?

---

From: Adam Montville <[email-masked]>
Date: Thu, 24 Apr 2014 16:44:15 -0500

> Suggest making no changes as it appears that the current referenced building block adequately covers the usage scenario.

+1

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Apr 2014 17:47:01 +0000

I'm happy to remove "In support of discovery".

The text is not intended to imply a preference for information gathered during network authentication, but that does seem to be a natural place to get it from when available. I believe the real preference here is to use machine-accessible sources of identification information if possible.

Can you suggest some text to use as a replacement?

Thanks,
Dave

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 5:41 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

On Apr 23, 2014, at 6:37 PM, Waltermire, David A. <[email-masked]<mailto:[email-masked]>> wrote:

Proposed text change:

{snip}

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Apr 2014 17:48:51 +0000

I like this refinement. If there is no other concerns about your proposed text, I'll make the change.

Thanks,
Dave

Proposed text change:

{snip}

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Apr 2014 17:52:50 +0000

I believe it should be "expected values." Good catch.

I like your proposed text. If there is no other concerns, I'll make the change.

Thanks,
Dave

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 5:42 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

Proposed text changes:

{snip}

{snip}

{snip}

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Apr 2014 18:05:44 +0000

Comments below.

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 5:44 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

Proposed text changes:

{snip}

[daw: I agree. I'll make the change if there are no other objections.]

{snip}

[daw: It depends on what piece of the solution you a referring to as being out of scope.

If we create a spec around defining evaluation expressions, I would not expect it to have to handle all possible analysis approaches. At minimum it will need to support analysis of expected vs. actual state and it should not be held up by accounting for a broader scope.

On the other hand, change detection, posture attribute value query, etc. should not be approached in a way that arbitrarily limits its usefulness. This is what we are acknowledging here. I could change "blocks will support" to "blocks can support" to weaken the assertion.

Do you have any proposed text changes that you would like to make here?]

---

From: Adam Montville <[email-masked]>
Date: Fri, 25 Apr 2014 13:52:08 -0500

On Apr 25, 2014, at 1:05 PM, Waltermire, David A. <[email-masked]> wrote:

> [daw: I agree. I’ll make the change if there are no other objections.]
> 
> 
>  
> {snip}
>  
> On the other hand, change detection, posture attribute value query, etc. should not be approached in a way that arbitrarily limits its usefulness. This is what we are acknowledging here. I could change “blocks will support” to “blocks can support” to weaken the assertion.
>  

Something Dave Harrington expressed in a different thread struck a chord with me.  It was about keeping a crisp distinction between spec and implementation - not reaching too far into the implementing application’s space.  For some reason, the proposed text feels like it’s blurring that line.  This is because I don’t think it’s the responsibility of this working group to specify, for example, things like trending of results.  Instead, I think it’s our responsibility to enable that capability by ensuring that what we do specify is good enough for the obvious extended uses, but is also extensible to handle unanticipated extended uses.

I think your suggestion to change “will” to “can” is a good one.

---

From: Adam Montville <[email-masked]>
Date: Fri, 25 Apr 2014 14:41:16 -0500

On Apr 25, 2014, at 12:47 PM, Waltermire, David A. <[email-masked]> wrote:

> I’m happy to remove “In support of discovery”.
>  

Ok, so authentication information is *one* potential “machine-accessible sources" of identification information.  I think that helps make the concept clear.

> Can you suggest some text to use as a replacement?

Would something like the following be a suitable replacement:

"Endpoints are identified in support of discovery using information previously obtained or by using other collection mechanisms to gather identification and characterization data.  Previously obtained data may originate from sources such as network authentication exchanges."

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Apr 2014 22:55:11 +0000

Thanks for the text. I like the change, I'll incorporate it along with your other suggestions on Monday.

Have a good weekend!

Dave
________________________________
From: Adam Montville <[email-masked]>
Sent: Friday, April 25, 2014 3:41:16 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

On Apr 25, 2014, at 12:47 PM, Waltermire, David A. <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Dave

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 5:41 PM
To: Waltermire, David A.
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Remaining Open Issues with draft-ietf-sacm-use-cases-06

Proposed text change:

{snip}