Subject: Re: [sacm] Review on draft-ietf-sacm-ecp-02

From: Adam Montville <[email-masked]>
Date: Wed, 5 Sep 2018 12:25:39 -0500

Danny, thanks for going through all my comments, and for addressing those that you did. Please see in line for my responses.

Kind regards,

Adam

> On Aug 28, 2018, at 2:13 PM, Haynes Jr., Dan <[email-masked]> wrote:
> 
> Thanks Adam! I pulled your comments out and have addressed them in-line.
> Abstract: Add reference for ECP 1.0.
> [Danny]: Addressed.
> Section 1.1: Change control “4” to “3” and “. [CIS]” to “[CIS].”
> [Danny]: Addressed.
> Section 1.1: EPCP not previously defined. 
> [Danny]: EPCP is expanded in the first sentence of Section 1. Were you looking for something more?

No, I just missed it.
> Section 4.2: Does it filter? That’s partial evaluation.
> [Danny]: The only filtering occurs in the Posture Broker Server component of the Posture Collection Manager which receives a batch of attributes from the Posture Collection Engine and routes the attributes to the appropriate Posture Validator. With that said, I noticed we have text that says the Posture Collection Manager does not do any evaluation (4.2) as well as text that says the SWID Posture Validator can do evaluation (6.1.5.3.2). We need to update the SWID Posture Validator section to just say it can do some sanity checking and processing of data before storing it in the repository to make it consistent.  

Seems sane to me.

> Section 4.4: Normative MAY? There MAY be other instances of these :).  
> [Danny]: In this particular instance, it is non-normative because it’s just discussing the different components and what they can do at a high-level if that makes sense. It might be difficult to make this text normative because for the Posture Collection Engine and Posture Collection Manager components they won’t likely support the same capabilities given the technologies (i.e., data models, protocols, and interfaces) used across endpoint types (e.g., traditional vs. IoT). With that said, there is room to provide normative text for components in the EPCP Implementations section. Given all that, do you think it is okay to leave this text non-normative? 

Yes.
> Section 5: When is the target endpoint told what attributes matter and their tolerance ranges?
> [Danny]: Wouldn’t it be determined by the data models that are called out in the EPCP Implementations section?

That seems like an inference :-) To me, it's better to explain that, but mine is just one opinion.
> Section 5.1: NOTE: TO BE EXPANDED before WGLC?
> [Danny]: Yes, we will update this in the next draft.
> Section 5.6: It feels odd to allow authorized repo access w/o specifying an interface. That said…may have a good idea for such a draft down the road a place.
> [Danny]: Given that we don’t actually have a protocol or interface for this, I think it’s more of a note of what we want when we develop one. So, I think we are in agreement here? 

Seems that way.
> Section 6.2.4: Why not support fetch/polling via NETCONF and RESTCONF now?
> [Danny]: This should be supported through NETCONF and RESTCONF now. This text is just trying to say that we also want to support the self-reporting capabilities provided by Yang Push once it’s an RFC. 
> 

Ok. Is it worthwhile to also state NETCONF/RESTCONF?

> Section 6.3: Change “Update the policy…” to “Establish and update the policy…”
> [Danny]: Addressed.
> 
> Section 6.3: Why shouldn’t the API offer commands and policy interaction?
> [Danny]: Are you asking why the API shouldn’t offer endpoints the ability to issue commands and policy interactions?
> 

No. The API is enabling query, but no proactive tasks. How are policies managed? Seems that the API should enable that as well.

> Section 7.2/7.3: Aren’t vulnerability searches part of vulnerability management?
> [Danny]: I don’t see any reason why these two sections can’t be combined.
> 

Seems reasonable.

> Section 13: First paragraph in Security Considerations feels superfluous.
> [Danny]: Seems reasonable to remove the first paragraph.
> 
> Section 13.1: Do we need to discuss benefits? Feels introductory.
> Section 13.1: Says “A second security consideration…”. Unclear what the first was.
> [Danny]: Seems reasonable to just remove this section. If there is anything we really feel we need, let’s just succinctly work it into the Introduction section. 
> 

Cool.

> Section 13.2: This is where I usually expect Security Considerations to start.
> [Danny]: Agree. RFC 3552 states the purpose of the Security Considerations section is “…to encourage document authors to consider security in their designs and to inform the reader of relevant security issues...”.
> Section 13.2.1: “….a certain percentage of endpoints will always get compromised…”. This could be clarified. There will always be a certain percentage compromised.
> [Danny]: Addressed. Reworded to “While the EPCP provides substantial improvements in endpoint security as described in Section 13.1, endpoints can still be compromised. For this reason, all parties must regard data coming from endpoints as potentially unreliable or even malicious…”.

Thumbs up.
> Section 13.3: A lot of the countermeasures read like CIS Controls. Could get some love for CIS as a reference even Benchmarks. Really like the idea of referencing CIS Controls and NIST 800-53 controls.
> [Danny]: Great idea! Would you be will to include the references? We will gladly give you authorship credits for it :).

Sure. Give me a few days??
> Section 14: Not sure how Privacy Considerations will be received, but, it is the sane to me.
> [Danny]: Great.
> All: Various editorial changes (add/remove words, commas, etc.)
> [Danny]: Addressed.
> Thanks,
> 
> Danny
>  
>  
>  
> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Adam Montville
> Sent: Thursday, August 23, 2018 11:25 AM
> To: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> Subject: [sacm] Review on draft-ietf-sacm-ecp-02
>  
> All:
> 
> Over the past few weeks I've been reviewing this draft and providing comments along the way to the draft authors. Now that I'm through the entire draft, I'm posting it here for the entire group to see. I apologize in advance if you have difficulty reading my annotations in the PDF.
> 
> Kind regards,
> 
> Adam
> 
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Wed, 5 Sep 2018 20:53:47 +0000

Hi Adam,

More comments inline.

Thanks,

Danny

________________________________
From: Adam Montville <[email-masked]>
Sent: Wednesday, September 5, 2018 1:25 PM
To: Haynes Jr., Dan
Cc: <[email-masked]>
Subject: Re: [sacm] Review on draft-ietf-sacm-ecp-02

Kind regards,

Adam

On Aug 28, 2018, at 2:13 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

  *   Abstract: Add reference for ECP 1.0.

[Danny]: Addressed.

  *   Section 1.1: Change control “4” to “3” and “. [CIS]” to “[CIS].”

[Danny]: Addressed.

  *   Section 1.1: EPCP not previously defined.

No, I just missed it.

  *   Section 4.2: Does it filter? That’s partial evaluation.

Seems sane to me.

  *   Section 4.4: Normative MAY? There MAY be other instances of these :).

Yes.

  *   Section 5: When is the target endpoint told what attributes matter and their tolerance ranges?

[Danny]: I think it would be covered in the "provisioning" section in EPCP Transactions. In -03, I updated the "NOTE: TO BE EXPANDED" to say the following.

"An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components necessary to interact with the posture manager. Examples of such identifiers include MAC addresses, serial numbers, hardware certificates compliant with [IEEE-802-1ar], and
the identities of hardware cryptographic modules among others. Furthermore, in some cases, an endpoint may need to be provisioned with instantiations of data models if the posture collection engine is expecting posture information in that format. Once provisioning is complete, the endpoint is deployed on the network."

Does this help make it clearer? Or, if not, is there any text that you would like to see?

  *   Section 5.1: NOTE: TO BE EXPANDED before WGLC?

  *   Section 5.6: It feels odd to allow authorized repo access w/o specifying an interface. That said…may have a good idea for such a draft down the road a place.

Seems that way.

  *   Section 6.2.4: Why not support fetch/polling via NETCONF and RESTCONF now?

[Danny]: Section 6.2 contains normative references to NETCONF/RESTCONF. Are you looking for something more?

  *   Section 6.3: Change “Update the policy…” to “Establish and update the policy…”

[Danny]: Addressed.

  *   Section 6.3: Why shouldn’t the API offer commands and policy interaction?

[Danny]: I think I am confused. Doesn't the API already support managing the policy  in section 6.3 (i.e., establish and update the policy)?

  *   Section 7.2/7.3: Aren’t vulnerability searches part of vulnerability management?

Seems reasonable.

  *   Section 13: First paragraph in Security Considerations feels superfluous.

  *   Section 13.1: Do we need to discuss benefits? Feels introductory.
  *   Section 13.1: Says “A second security consideration…”. Unclear what the first was.

Cool.

  *   Section 13.2: This is where I usually expect Security Considerations to start.

  *   Section 13.2.1: “….a certain percentage of endpoints will always get compromised…”. This could be clarified. There will always be a certain percentage compromised.

Thumbs up.

  *   Section 13.3: A lot of the countermeasures read like CIS Controls. Could get some love for CIS as a reference even Benchmarks. Really like the idea of referencing CIS Controls and NIST 800-53 controls.

[Danny]: Sounds good to me.

  *   Section 14: Not sure how Privacy Considerations will be received, but, it is the sane to me.

[Danny]: Great.

  *   All: Various editorial changes (add/remove words, commas, etc.)

[Danny]: Addressed.
Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, August 23, 2018 11:25 AM
To: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] Review on draft-ietf-sacm-ecp-02

All:

Kind regards,

Adam

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Wed, 5 Sep 2018 22:38:24 -0500

Thanks, Danny. I snipped a bunch of the original content to save space. See inline.

> On Sep 5, 2018, at 3:53 PM, Haynes Jr., Dan <[email-masked]> wrote:
> 

At first blush this seems helpful. What if the attributes of interest change over time? Not sure they will, or even should. But, the more likely scenario is when a new attribute is introduced. At that point, how do we tell the endpoint we're interested in monitoring that new attribute?

> [Danny]: Section 6.2 contains normative references to NETCONF/RESTCONF. Are you looking for something more?

Sorry. This is my oversight, I think. Seems sane.

> [Danny]: I think I am confused. Doesn't the API already support managing the policy  in section 6.3 (i.e., establish and update the policy)?

I'm probably the one who is confused. :-) The way I read that section is that it addresses two means of interaction: 1) administrative interface, 2) API. I took the first three bullets as applicable to the administrative interface, and the solitary bullet as applicable to the API. If all of the bullets are applied to each, then I think the section could be rearranged to combine the two bulleted lists and state something to the effect that the list applies to both the administrative interface and the API.

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Thu, 6 Sep 2018 17:04:56 +0000

Hi Adam,

Even more comments inline :).

Thanks,

Danny

From: Adam Montville <[email-masked]>
Sent: Wednesday, September 05, 2018 11:38 PM
To: Haynes Jr., Dan <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [sacm] Review on draft-ietf-sacm-ecp-02

On Sep 5, 2018, at 3:53 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

"An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components necessary to interact with the posture manager. Examples of such identifiers include MAC addresses, serial numbers, hardware certificates compliant with [IEEE-802-1ar], and the identities of hardware cryptographic modules among others. Furthermore, in some cases, an endpoint may need to be provisioned with instantiations of data models if the posture collection engine is expecting posture information in that format. Once provisioning is complete, the endpoint is deployed on the network."

[Danny]: I think those are both possible situations that we want to account for. If there is a Posture Collector on the endpoint that can collect the attributes, it just needs to be configured via the Administrative Interface or API. If there isn’t a Posture Collector on the endpoint that can collect the attributes, a new Posture Collector needs to be installed on the endpoint and then configured by the Administrative Interface or API. We can add some text to this section stating that components and data models may need to be added or updated over time to fulfill the collection needs of the enterprise. Maybe something like the following.

"An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components and data models necessary to interact with the posture manager. Examples of such identifiers include MAC addresses, serial numbers, hardware certificates compliant with [IEEE-802-1ar], and the identities of hardware cryptographic modules among others. Once provisioning is complete, the endpoint is deployed on the network. Over time, components and data models may need to be added to the endpoint or updated to support the collection needs of an enterprise."

Seems that way.

[Danny]: Sorry my bad. I read it wrong. I don’t see anything wrong with the interface and API supporting the same capabilities especially since it isn’t defined yet :). I will update the text to make them both support the same capabilities.

---

From: Adam Montville <[email-masked]>
Date: Thu, 6 Sep 2018 12:07:55 -0500

Thanks, Danny. Looks like it's about buttoned up in terms of my comments?

> On Sep 6, 2018, at 12:04 PM, Haynes Jr., Dan <[email-masked]> wrote:
> 
> Hi Adam,
>  
> From: Adam Montville <[email-masked] <mailto:[email-masked]>> 
> To: Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> On Sep 5, 2018, at 3:53 PM, Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Thu, 6 Sep 2018 17:32:34 +0000

Correct. I will make these changes and post an updated draft tomorrow afternoon.

Thanks,

Danny

Sent: Thursday, September 06, 2018 1:08 PM

On Sep 6, 2018, at 12:04 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

Thanks,

Danny

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 05, 2018 11:38 PM
To: Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Review on draft-ietf-sacm-ecp-02

Seems that way.

---

From: Adam Montville <[email-masked]>
Date: Thu, 6 Sep 2018 12:33:30 -0500

Sweet! Looking forward to it.

> On Sep 6, 2018, at 12:32 PM, Haynes Jr., Dan <[email-masked]> wrote:
> 
> On Sep 6, 2018, at 12:04 PM, Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Adam,
>