Subject: Re: [sacm] [draft-ietf-sacm-architecture] Section 3.1.3 - Controller - Registration/Discovery (#29)

From: llorenzin <[email-masked]>
Date: Wed, 30 Sep 2015 12:02:19 -0700

Lisa - seems odd to say an internal collector would have a function of discovering the endpoint it's running on
Nancy - wasn't thinking of registration / discovery of target endpoints, but of SACM components
Jess - would an internal collector be able to discover itself?
Henk - internal collector is SACM component, on fringes of SACM domain, on target endpoints that are the assessing component at the same time
Nancy - what does internal collector mean?
Henk - SACM component is part of SACM domain, runs on endpoints that are typically not target endpoints
target endpoints are endpoints of interest, to be assessed
Outside SACM domain is rest of the world visible to SACM domain
Fringe use case - line blurs because endpoint is target endpoint and also SACM component - "internal" collector resides on it
Lisa - I didn't think having an internal collector made a target endpoint a SACM component
Think the SACM component is the provider that rolls up the collection results
Nancy - that was my thought as well
Henk - target endpoint becomes a SACM component because it has building blocks running on it - SACM functions, registrative broker and publishers
Lisa - don't think every target endpoint is a SACM component - only if it's also a provider
Henk - only if it has an internal collector on it
Jess - distinction between an internal collector and a provider - why?
Lisa - internal collector doesn't necessarily publish into SACM ecosystem
if it doesn't publish, it's not a SACM component
Jess - NEA world, collector provides information to a server, which is part of the control plane
Lisa - NEA server is the provider, NEA client is just software on endpoint
Henk - semantically, if a piece of software on an endpoint is speaking SACM - can discover guidance or register to a broker - this can be the case, should be highlighted - it's a SACM component
if just produces information and transports it to the first SACM component, then this is remote collection
typical collection that over the network is assessing the endpoint
maybe have a trusted, registered, attested component on the target endpoint - could trust it
Lisa - that's not what an external collector is either
In the NEA example the NEA client is just software on the endpoint
it's not a SACM component - doesn't publish into the provider/consumer ecosystem, doesn't use a SACM transport
NEA server is the provider, so it aggregates the information from the internal collectors on target endpoints and uses the SACM transport to provide that information 
Jess - wasn't aware this group had defined a transport
Nancy - XMPP-Grid is a proposed transport 
Jess - what about IF-T TLS?
Henk - transport here is overloaded
Lisa - we decided not to specify the transport between the target endpoint and the SACM component
SACM transport is transport between SACM components
other transport between endpoint and SACM component
Jess - NEA client publishing data about itself, is that a SACM component?
Lisa - if it's publishing directly, yes
Nancy - think you're mixing implementation details
if you made the NEA client become a SACM provider, adhered to the data model, then yes
Lisa - endpoint can be a SACM component but doesn't have to be
Henk - we don't define how you get information from the target endpoint
Just says the SACM component uses any means to get information from the target endpoint
Think this is restricting the scope of the SACM domain, important choice, should be highlighted to the email list
Understand the argument - don't see why you can't allow a SACM component to reside on a target endpoint
Lisa - not saying that - like difference between TNC client and IMC - IMC is like internal collector, TNC client is like SACM component
Josh - have a simple drawing?
Lisa - would be good to have a drawing showing relationships between functions and components
Josh - basic entity / relationship map

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-architecture/issues/29#issuecomment-144508059

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 Sep 2015 21:29:09 -0700

Lisa,

I am having a hard time understanding why you do not believe that an internal collector is not functionally a provider and thus a SACM component.

Looking at the text in section 3.1.1 of the architecture.  An internal collector would – provide information, is a posture collector, could do so either spontaneously or in response to a consumer request.  These are all attributes of a provider.

In addition, the many of the requirements laid out in the requirements document are going to apply to any conversation between the internal collector on a device and the consumer that it transmits the data to.  This will include: 1) identifying that it is the correct consumer, 2) protecting the data via encryption, 3) do either full or incremental updates of information.

With respect to the details about NEA, I was unfortunately in the middle of doing paperwork for people when the presentation was done at the interim, but I believe that there are two possible ways to look at how the NEA components would be described in the SACM architecture.  It depends in part on how much work we want to do in terms of forcing NEA to look “correct”. 

The first is as was discussed in the meeting:  The entire NEA system becomes and external collector that acts as a provider to the SACM system.  The second view is:  The NEA endpoint is a SACM internal collector acting as a provider, the NEA server is a consumer in terms of receiving data from the internal collector (and from the SACM system in terms of getting guidance) and then as a provider after modifying/augmenting the data to a SACM data store (or other consumer).

The advantages of the first view, is that SACM does not need to do an evaluation of the PT-TLS connector and any protocols between the PT Client and the PT Server, it can focus only on the conversations between the SACM provider in the server endpoint to other SACM consumers.

The advantage of the second view, is that SACM would get to do an analysis of the PT-TLS connector and protocols to determine if they meet the minimum requirements for a SACM transport and SACM data model operations and see what, if any, changes are needed to address the security and privacy requirements that have been defined by SACM.

Jim

From: llorenzin [mailto:[email-masked]] 
Sent: Wednesday, September 30, 2015 12:02 PM
To: sacmwg/draft-ietf-sacm-architecture <[email-masked]>
Cc: Jim Schaad <[email-masked]>
Subject: Re: [draft-ietf-sacm-architecture] Section 3.1.3 - Controller - Registration/Discovery (#29)

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-architecture/issues/29#issuecomment-144508059> .