Subject: [sacm] Comments on draft-ietf-sacm-ecp

From: Adam Montville <[email-masked]>
Date: Mon, 2 Apr 2018 14:29:25 -0500

Hello ECP'ers (and SACM),

I'm still going through the 01 revision of the ECP draft, but am now really looking at some of the documents it points to. I have a few comments and clarifying questions, in no particular order (I do apologize for the shotgun approach here)...

This is a really verbose draft. I'd be happy to help trim it down. :-) 
I'm noting that Lisa Lorenzin is no longer with Pulse Secure - does her information need to be updated?
I'm not 100% clear on the scope of this draft. At one point, the draft seems relegated to what it calls the posture manager and the software executing on an endpoint, but at another point the draft talks about necessary repository functions. (See my final comment below.)
How related are IM-IMC and/or IM-IVC to IF-MAP? I don't think very related, but this is outside my area of knowledge. I ask because at one point Lisa warned the working group about some IF-MAP-related pitfalls to avoid.
I would consider removing section 8 (though retaining section 9 might be helpful from a scoping perspective)
I would move section 10 way up front.
Note that these examples are relying on SWID collectors which aren't really what the examples are intended to convey.
For example, 10.1 claims "posture assessment" but shows only SWIMA, which may be part of posture collection, but is not wholly posture collection.
I would like to see how the authors feel ECP maps to RFC8248 (similar to the attempt we made in the mandm draft [2])
Not being as familiar with NEA as I perhaps should be, I'm interested to know whether NEA prescribes an event-driven approach to monitoring or if that is an ECP agumentation (see 10.1.1)
Wherever the draft says something like "SWIMA Posture Collection", I would say "SWIMA inventory collection" or something similar to that. Posture has s specific definition per our terminology draft [3], and the information enabled by use of SWIMA is part of, but is not in total, posture information.
Do the authors (or does anyone) have any notion of what a repository would look like?
I would like to see some expository text helping a reader understand how various collectors (not just a SWIMA collector) could be created and deployed potentially from multiple parties on a single endpoint.
Do the authors anticipate the administrative interface/API to be fully specified elsewhere? I think the same goes for the repository. And the evaluator at at least one point in the draft.
I'm not sure what SACM SWAM means in the title of 7.1.6
There's a lot of talk about policy content, but no real details - is the expectation that these will be handled in separate drafts?

If entering these into Trac or GitHub as issues makes more sense, let me know. 

I think the ECP draft is less about compliance and more about collection, and it's specifically about agent-based (or in-built) collection capabilities based on NEA and extensions thereto - in other words, ECP begins to specify a collection infrastructure for agent-based collection (sorry if I'm slow). In this way, the draft adds value to SACM, and leaves room for alternative approaches that may not be agent-based. If a tight scope statement could be created along these lines, I think that would go a long way toward clarifying the draft. 

Thoughts?

Kind regards,

Adam

[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/>
[2] https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/ <https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/>
[3] https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Tue, 3 Apr 2018 18:28:54 +0000

Hi Adam,

Comments inline below.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 02, 2018 3:29 PM
To: [email-masked]
Cc: <[email-masked]> <[email-masked]>
Subject: Comments on draft-ietf-sacm-ecp

  *   This is a really verbose draft. I'd be happy to help trim it down. :-)
[danny] Sounds good to me :). Feel free to propose changes.

  *   I'm noting that Lisa Lorenzin is no longer with Pulse Secure - does her information need to be updated?
[danny] It probably should be, but, I don't have her latest information. Does anyone have it?

  *   I'm not 100% clear on the scope of this draft. At one point, the draft seems relegated to what it calls the posture manager and the software executing on an endpoint, but at another point the draft talks about necessary repository functions. (See my final comment below.)
[danny] Yes, you are correct. We have been slowly iterating the draft to get it away from as solution for connected and compliant use cases to a common framework for the collection of endpoint information (needed for asset management, hardware/software inventory, configuration, vulnerability) and the communication of that information to a centralized server. Your comment about being one way to collect information is also correct. We updated it from being entirely NEA/TNC focused to be open and support other protocols like NETMOD.

  *   How related are IM-IMC and/or IM-IVC to IF-MAP? I don't think very related, but this is outside my area of knowledge. I ask because at one point Lisa warned the working group about some IF-MAP-related pitfalls to avoid.
[danny] They are not related. IF-IMC and IF-IMV are interfaces between Posture Collectors and the Posture Broker Client and Posture Validators and the Posture Broker Server respectively. This provides a common interface by which Posture Collectors and Posture Validators can developed and easily deployed into the system. IF-MAP is just an interface between TNC components and the metadata access point (MAP) server which stores network and endpoint information. Unfortunately, I am not familiar with the IF-MAP-related pitfalls to avoid. Can someone with more TCG experience elaborate on the pitfall associated with IF-MAP?

  *   I would consider removing section 8 (though retaining section 9 might be helpful from a scoping perspective)
[danny] I think both could be good from a scoping perspective. Perhaps, we should move these to an appendix?

  *   I would move section 10 way up front.

     *   Note that these examples are relying on SWID collectors which aren't really what the examples are intended to convey.
     *   For example, 10.1 claims "posture assessment" but shows only SWIMA, which may be part of posture collection, but is not wholly posture collection.
[danny] I don't have an objection to that. What do others think about this?

  *   I would like to see how the authors feel ECP maps to RFC8248 (similar to the attempt we made in the mandm draft [2])
[danny] It doesn't directly map to RFC8248, but, it talks about how ECP aligns with SACM (https://tools.ietf.org/html/draft-haynes-sacm-ecp-recommendations-00). Does this help?

  *   Not being as familiar with NEA as I perhaps should be, I'm interested to know whether NEA prescribes an event-driven approach to monitoring or if that is an ECP agumentation (see 10.1.1)

[danny] Events are prescribed in the extensions to NEA. For example, in SWIMA, it states:

                  All SWIMA-PCs MUST be able to be able to detect changes to the Software Inventory Evidence Collection.  Specifically, SWIMA-PCs MUST be able to detect:

o   The creation of records

o   The deletion of records

o   The alteration of records

  *   Wherever the draft says something like "SWIMA Posture Collection", I would say "SWIMA inventory collection" or something similar to that. Posture has s specific definition per our terminology draft [3], and the information enabled by use of SWIMA is part of, but is not in total, posture information.
[danny] Can you clarify? Looking at the definition for posture in GitHub, it says: "...the configuration and state information that is collected from a target endpoint in the form of endpoint attributes (e.g. software/hardware inventory, configuration settings, dynamically assigned addresses). This information may constitute one or more posture attributes.". It seems like what SWIMA collects is posture to me?

  *   Do the authors (or does anyone) have any notion of what a repository would look like?
[danny] No, it's to be defined at a later time :). For now, I think we have to let implementers define their own repository and interfaces to the repository. After we get these major components standardized, we can try and tackle that problem.

  *   I would like to see some expository text helping a reader understand how various collectors (not just a SWIMA collector) could be created and deployed potentially from multiple parties on a single endpoint.
[danny] The IF-IMC/IF-IMV interfaces provide this functionality. If all PCs/PVs and all PCMs/PCEs implement these interfaces they should be able to deploy PCs/PVs from multiple parties on a single endpoint.

  *   Do the authors anticipate the administrative interface/API to be fully specified elsewhere? I think the same goes for the repository. And the evaluator at at least one point in the draft.
[danny] Yes, IF-IMC/IF-IMV are TCG specifications and we are proposing that we just reference them directly rather than trying to submit them to SACM. At some point, we will need interfaces/APIs for the repository and evaluator, but, those are both things we need to tackle later on.

  *   I'm not sure what SACM SWAM means in the title of 7.1.6
[danny]  SWAM is supposed to be "Software Asset Management". ACTION: Just expand SWAM in the document since it is only used in two places.

  *   There's a lot of talk about policy content, but no real details - is the expectation that these will be handled in separate drafts?
[danny] Yes, as of right now, policy is not defined anywhere. It is something that can be defined in separate drafts at a later time.
If entering these into Trac or GitHub as issues makes more sense, let me know.

[danny] Let's keep going on the list and see what concrete actions come out of this thread. If we have a bunch, we can go ahead and add them. For now, I just want to keep the discussion in one place (easier for management - I think :)).

[danny] Do you want to take a pass at that statement :)? Also, where are you thinking it would go? In the introduction?

Thoughts?

Kind regards,

Adam

[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/
[2] https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/
[3] https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 08:40:48 -0500

> On Apr 3, 2018, at 1:28 PM, Haynes Jr., Dan <[email-masked]> wrote:
> 
> Hi Adam,
>  
> Comments inline below.
>  
> Thanks,
> 
> Danny
>  
> From: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>] 
> To: [email-masked] <mailto:[email-masked]>
> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>

I'll do that. I assume on-list. Though, this seems like a spot where using git would be helpful (just saying).

> [danny] It probably should be, but, I don’t have her latest information. Does anyone have it?

I believe she's with zScaler now, but I haven't any contact information.
> [danny] They are not related. IF-IMC and IF-IMV are interfaces between Posture Collectors and the Posture Broker Client and Posture Validators and the Posture Broker Server respectively. This provi…

If unrelated, then no need to spend time on it.
> [danny] I think both could be good from a scoping perspective. Perhaps, we should move these to an appendix?

Yes, an appendix would be great - may help keep the main points of the draft focused.
> [danny] I don’t have an objection to that. What do others think about this?
> [danny] It doesn’t directly map to RFC8248, but, it talks about how ECP aligns with SACM (https://tools.ietf.org/html/draft-haynes-sacm-ecp-recommendations-00 <https://tools.ietf.org/html/draft-haynes-sacm-ecp-recommendations-00>). Does this help?

Am I the only one that finds this to be odd? I would like to think that, because ECP is essentially proposing at least a part of our intended architecture, some of the requirements would apply...

> o   The alteration of records

Great, thanks. I wonder if there's a way to mention more about where collector behaviors are expected to be defined.
> [danny] Can you clarify? Looking at the definition for posture in GitHub, it says: “…the configuration and state information that is collected from a target endpoint in the form of endpoint attributes (e.g. software/hardware inventory, configuration settings, dynamically assigned addresses). This information may constitute one or more posture attributes.”. It seems like what SWIMA collects is posture to me?

Sure. The context I have is that we, long ago, talked about the posture of an endpoint being the collection of software load, configuration state, vulnerability state (or something similar to that). Software load is a part of that. If I read the definition very literally, it reads "configuration and state information" rather than "configuration or state information" or "configuration and/or state information". The singular examples in the definition notwithstanding, when I read the phrase "SWIMA Posture Collection" I feel like SWIMA should be capable of collecting all possible posture information.

I'm interested in what others think as well. Also, the only reason I'm commenting is for others' benefit - I understand what the draft means, but a first-time reader may not.

> [danny] No, it’s to be defined at a later time :). For now, I think we have to let implementers define their own repository and interfaces to the repository. After we get these major components standardized, we can try and tackle that problem. 

This is why I don't feel like the repository is in scope.
> [danny] The IF-IMC/IF-IMV interfaces provide this functionality. If all PCs/PVs and all PCMs/PCEs implement these interfaces they should be able to deploy PCs/PVs from multiple parties on a single…

Great! The draft should, IMO, mention that. It may also benefit from mentioning this in terms of just how different the implementations from different parties can be. Can one, for example be C++ compiled to native machine language and another be some Groovy running in a JVM?
> [danny] Yes, IF-IMC/IF-IMV are TCG specifications and we are proposing that we just reference them directly rather than trying to submit them to SACM. At some point, we will need interfaces/APIs fo…

I agree that the TCG specifications can be handled in this manner. What about the administrative interface? Is that defined in the TCG specs? If not, this is another reason I have trouble with scope on this draft.
> [danny]  SWAM is supposed to be “Software Asset Management”. ACTION: Just expand SWAM in the document since it is only used in two places.

:-) Got it. I didn't pick up on that before.
> [danny] Yes, as of right now, policy is not defined anywhere. It is something that can be defined in separate drafts at a later time.

Thanks.

>  
> [danny] Let’s keep going on the list and see what concrete actions come out of this thread. If we have a bunch, we can go ahead and add them. For now, I just want to keep the discussion in one place (easier for management – I think :)). 

No problem.

> [danny] Do you want to take a pass at that statement :)? Also, where are you thinking it would go? In the introduction?

:-) Dude. (Yeah, I'll give it a shot.) The big important question: Do I get authorship benes? ;-)

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Wed, 4 Apr 2018 14:49:42 +0000

More comments inline below.

Thanks,

Danny

On Apr 3, 2018, at 1:28 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

Comments inline below.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 02, 2018 3:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Comments on draft-ietf-sacm-ecp

[danny] Great, that would be awesome!

[danny] Ok, thanks for the lead.

[danny] How do others feel about moving the use cases to an appendix?

  *   I would like to see how the authors feel ECP maps to RFC8248 (similar to the attempt we made in the mandm draft [2])
[danny] It doesn’t directly map to RFC8248, but, it talks about how ECP aligns with SACM (https://tools.ietf.org/html/draft-haynes-sacm-ecp-recommendations-00). Does this help?

[danny] Hmmm, maybe my comment didn’t come out right. I was just saying that draft-haynes-sacm-ecp-recommendations didn’t directly map ECP to requirements. Not that ECP, as a solution, didn’t map to SACM requirements.

[danny] ACTION: Since this is NEA specific, see if there is somewhere in the NEA ECP Implementation section to add a note about events being defined in extension specifications.

[danny] I guess I didn’t read that “and” so literally in the terminology :). And yes, through extensions, ECP (not SWIMA) is capable of collecting all possible posture information. SWIMA just focuses on software inventory information.

[danny] In that case, what do others think about this?

[danny] Can we bring it into scope later? Is its presence in the draft negatively impacting the work? I guess I don’t understand why it can’t be in the document until we get to it because it helps show the end goal. Am I missing something :)? What do others think?

[danny] ACTION: Add text in the document explaining that IF-IMC/IF-IMV interfaces allow PCs/PVs from multiple parties to be deployed on a single endpoint.

[danny] No, I don’t believe the administrative interface is defined in a TCG specification. Chris had a similar comment on this. We could either remove mention of the administrative interface or simply leave it for vendors to implement with some basic requirements for the capabilities we expect in such an interface as this is an area vendors could significantly differentiate their products.

Thanks.

No problem.

[danny] Not sure, I have no idea what the requirements are for that :).

Thoughts?

Kind regards,

Adam

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 09:58:39 -0500

> On Apr 4, 2018, at 9:49 AM, Haynes Jr., Dan <[email-masked]> wrote:
> 

Ah, ok. Then my original comment would really be a suggestion to make the link as explicit as possible by including that mapping.

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 10:01:03 -0500

> [danny] In that case, what do others think about this?

Yes, please opine. In the interest of clarity and thrash-avoidance, I would prefer that we use posture to reference complete posture rather than part of posture, otherwise we'll always be needing to qualify which parts of posture we really mean or leaving it up to context, which is sometimes fine but sometimes not.

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 10:02:21 -0500

> [danny] Not sure, I have no idea what the requirements are for that :).

Of course, I was (mostly) joking.

---

From: Adam Montville <[email-masked]>
Date: Tue, 24 Apr 2018 14:38:28 -0500

Danny,

Just an FYI that this stuff hasn't fallen off my radar. I have a bunch of paring down suggestions - I just need to translate them to an e-mail so they can be digested.

Adam

> On Apr 4, 2018, at 10:02 AM, Adam Montville <[email-masked]> wrote:
> 
> 
> 
>> On Apr 4, 2018, at 9:49 AM, Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>> wrote:
>>