Subject: [sacm] Initial comments on ECP draft

From: Adam Montville <[email-masked]>
Date: Fri, 04 Aug 2017 11:23:36 +0000

Now that the ECP draft has been marked as adopted, I'd like to make some
comments.

The draft seems primarily concerned with endpoint software inventory rather
than collection of generic attribute state. The abstract doesn't limit the
draft to software inventory, but other (obvious) statements in the draft
certainly do. To me, this draft needs to more clearly articulate how other
categories of endpoint state can be collected (doesn't SWIMA handle the
software attributes a bit anyway)?

For example, see the first bullet in 4.2.3. (non use cases). It seems that,
given we have the SWIMA draft, that we should evolve ECP to be about the
framework for collection - we should entertain collection of other types of
posture information in this draft.

Additionally, the last bullet in 4.2.3 talks about a pub/sub repository
interface. I would like the group (perhaps as part of our IETF 100
hackathon efforts) to consider how XMPP grid may support this notion.

Please change the reference to SANS "20 Critical Security Controls" to the
current CIS Controls.

Finally, 5.2 mentions: "Any PC used in an Endpoint Compliance Profile
solution MUST be conformant with [IF-IMC]; an Internet-Draft, under
development, that is a subset of the TCG TNC Integrity Measurement
Collector interface [IF-IMC] and will be submitted in the near future."
Which Internet-Draft is being referenced? If not yet available, I'd like to
see this sooner rather than later, because it's going to be hard to fully
evaluate ECP otherwise. Also, does the same apply for IF-IMV?

Kind regards,

Adam

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Fri, 11 Aug 2017 13:38:27 -0400

Adam,

Thanks for your comments. I agree, the draft would do well to be
up-leveled. We can drop the SWIMA requirement, and maybe describe it as an
example of an implementation of a collector. What do you think?

We might do well to genericize the collection capability over all, really.
NEA is a good mechanism to collect event-driven data from a client or a
server, but there are others (for example, yang push).

Regarding the pub/sub repository interface, I agree. It would be a great
opportunity at IETF 100.

I will definitely update the Controls reference. Thanks for catching that.

We put IF-IMC and IF-IMV on hold during the SWIMA work. We could revive
that effort, but I would like to be sure there is interest from the group
before doing so. IF-IMC and IF-IMV improve coordination of communication
between collectors and client, and between verifiers and servers,
respectively. They have been implemented in strongSwan, so were likely a
part of the hackathon effort at IETF 99. Andreas, am I correct there?

Thanks,
Jess

On Fri, Aug 4, 2017 at 7:23 AM, Adam Montville <[email-masked]>
wrote:

> The draft seems primarily concerned with endpoint software inventory
> rather than collection of generic attribute state. The abstract doesn't
> limit the draft to software inventory, but other (obvious) statements in
> the draft certainly do. To me, this draft needs to more clearly articulate
> how other categories of endpoint state can be collected (doesn't SWIMA
> handle the software attributes a bit anyway)?
>
> For example, see the first bullet in 4.2.3. (non use cases). It seems
> that, given we have the SWIMA draft, that we should evolve ECP to be about
> the framework for collection - we should entertain collection of other
> types of posture information in this draft.
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: Andreas Steffen <[email-masked]>
Date: Fri, 11 Aug 2017 20:37:30 +0200

Hi Jess,

of course the IF-IMC and IF-IMV interfaces were used to exchange
SWIMA messages between the SWIMA collector and the PB-TNC client
as well as between SWIMA verifier and the PB-TNC server.

Regards

Andreas

On 11.08.2017 19:38, Jessica Fitzgerald-McKay wrote:
> that effort, but I would like to be sure there is interest from the
> group before doing so. IF-IMC and IF-IMV improve coordination of
> communication between collectors and client, and between verifiers and
> servers, respectively. They have been implemented in strongSwan, so were
> likely a part of the hackathon effort at IETF 99. Andreas, am I correct
> there?

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

---

From: Adam Montville <[email-masked]>
Date: Wed, 23 Aug 2017 13:38:25 +0000

I think all of this is on the table if we up-level the draft. Other
comments inline.

> example of an implementation of a collector. What do you think?

[AWM] I like it, what do others think is reasonable?

> server, but there are others (for example, yang push).

[AWM] Making the generic collection framework explicit is important, and we
should design toward accepting other forms of collection now and in the
future.

> Regarding the pub/sub repository interface, I agree. It would be a great

[AWM] I've had very little response to my calls to get an IETF 100
hackathon effort under way - hoping that it's summer vacation (I know I
fell into that bucket)

> I will definitely update the Controls reference. Thanks for catching that.

[AWM] Any time.

> part of the hackathon effort at IETF 99. Andreas, am I correct there?

[AWM] I think this may be answered as we look to up-level ECP?

>
> Thanks,
> Jess
>
> On Fri, Aug 4, 2017 at 7:23 AM, Adam Montville <[email-masked]
> > wrote:
>
>> Please change the reference to SANS "20 Critical Security Controls" to
>> the current CIS Controls.
>>