Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 7 Sep 2017 20:35:03 +0000

Hi Nancy,

Thanks again for the feedback. Sorry this response is so delayed. My responses are inline (with points of consensus removed for brevity).

> [NCW]  What wasn’t clear is that I think the draft is defining new “message
> types” as PA-TNC extensions to enable the request/response for sw
> inventory information….but I had to read well down into section 5 to grok it.
> May be useful to actually state that in the Introduction too.

<CMS>
What you say here is an accurate characterization. I'll add a sentence early on to that effect.

>     > If indeed the draft is about extending the PA-TNC model to include
>     > SWIDs…This can limit the scalability and deployment use cases; per
> section
>     > 2.1.3 of RFC 7632, as it states there is desire to “collect a set of attribute
>     > values related to one or more endpoints”.
> 
>     I'm confused by what you mean here. SWIMA is not intended it single-
> handedly fulfill this requirement. It does, however, move towards fulfillment
> of this requirement by enabling appropriate collection of software inventory
> information. Thus there is no limiting of the SACM use cases.
> [NCW] As this is PA-TNC and based on NEA, the intent of NEA was to only
> have the “target endpoint” do such reporting.  That is, Section 5.1.1 of RFC
> 5209 leads me to believe that the reporting is to be of “that” specific
> endpoint device (e.g. to what SACM refers to as the “target” endpoint).  So,
> my point was that in SACM, we’d like to have collectors that may have
> repositories of sw inventories of more than 1 target endpoint.

<CMS>
If I am understanding you, you are talking about a situation where Endpoint A has already collected inventories from several other endpoints, and now a verifier wants to contact Endpoint A and gather the information it collected. Correct?

SWIMA is not designed to handle this situation. There is nothing in SWIMA attributes to explicitly associate a software inventory with a particular endpoint, which would be necessary if you were reporting a collection of previously gathered information. Instead, collected information is implicitly associated with the endpoint from which that information is gathered through the PT-TLS and PB-TNC layers. 

The bottom line is that Endpoint A might use SWIMA to collect the inventory information from other endpoints, but you would need to use a different protocol to query a repository of already collected information. I agree that such a protocol is needed for SACM, but SWIMA does not try to meet that particular need.

>     > Section 1.1
>     > “The attributes defined in this document are used to
>     >    communicate software inventory evidence, collected from a range of
>     >    possible sources, from the posture collector on the endpoint to the
>     >    posture validator on a NEA Server using the PA-TNC interface, as
>     >    shown in Figure 1 below.”
>     > -	“Posture collector on the endpoint”,
>     > why does the collector need to be on an endpoint?
> 
>     The NEA specification (RFC 5209) states that Posture Collectors are on NEA
> Clients, which is a type of endpoint. Is there anything that is not an endpoint
> on which you think there should be a posture collector?
> [NCW] Per my previous comment, there are repositories that can keep
> inventory of more than 1 target endpoint.

<CMS>
Agreed, but querying existing repository for previously collected information is outside the scope of SWIMA.

>     > Section 2.2: is this section necessary?  There are many more use cases
> not
>     > supported, so would opt to remove this section.
> 
>     I believe this is helpful because these address likely areas of confusion.
> Yes, this is not an exhaustive list of unsupported use cases. However, a
> reasonable reader might initially assume that SWIMA includes guidance for
> converting software inventory into a single data model (for example). This
> section would make it clear that conversion of information is outside the
> scope of SWIMA.
> [NCW] While I can see them as use cases, it is meant to be for SACM….I am
> not sure why such elaboration is needed and question why these are not
> brought back to map how this draft helps address the SACM adopted use
> case (e.g.RFC7632).  Which I know it does….but again, I question why it is
> standalone vs. its relevance to other SACM documents (e.g. the Use case,
> terminology and requirements).

<CMS>
This may be a philosophical difference here and I'd be interested in others' opinions as well. Briefly, I believe it makes sense to make specifications as stand-alone as possible. In particular, if a "component specification" that serves a role in a larger architecture is independently useful outside that architecture, my opinion is that the component specification should make little or no reference to the larger architecture. I say this in the name of reducing unnecessary complexity in the spec, and avoiding incorrect assumptions that the component specification is only useful if you build the larger architecture, thus reducing adoption.

The SACM architecture is not necessary for successful adoption and use of SWIMA. (I.e., a basic NEA implementation could use SWIMA effectively without having ever heard of SACM.) Implementers interested in SWIMA don't need to know about SACM, so discussion of SACM is unnecessary from that perspective. Moreover, we absolutely want to avoid any implication that use of SWIMA hinges on adoption of the wider SACM architecture; SACM is just one of many ways in which SWIMA could be used. Based on this perspective, I'm inclined to not to hook in SACM references.

>     > Also, it would be best suited to have this section also set in the context of
> the
>     > SACM requirements and reference the requirements enumerated in the
>     > soon to be published https://datatracker.ietf.org/doc/draft-ietf-sacm-
>     > requirements/ draft
> 
>     I'll have to think about that, but my gut response is that the SWIMA
> requirements and the SACM requirements are not the same thing. SWIMA
> certainly must conform to SACM requirements, but it does not need to
> completely fulfill them - SWIMA is one part of a larger solution. The SWIMA
> requirements, in turn, are intended to focus just on SWIMA itself, and thus
> go beyond SCAP requirements. Even when they align (e.g., requirement for
> interoperability) they are not talking about the same thing. SWIMA
> interoperability just means that the protocols allow SWIMA-PV and SWIMA-
> PCs from different vendors to talk to each other, not that the information
> collected by SWIMA be useable across the entire SACM architecture. The
> bottom line is that, despite the common use of the term "requirements", my
> initial feeling is that these are not alike enough for a mapping to be usefully
> instructive. Do you have specific mappings that you feel would be
> appropriate?
> [NCW] This draft is about defining 2 new message types within NEA, what I
> read in this section are general implementation and considerations about
> NEA that imho do fall as being relevant to the sacm-requirements draft.

<CMS>
See comment above. While I agree that SWIMA is relevant to SACM requirements, I don't believe it is beneficial to call that out in the spec. SWIMA is relevant to lots of requirements, not just SACM ones.

>     In 3.2, the term "data model" refers not to the attributes, but to the way
> that a software inventory record is expressed. I should probably clarify that.
> "Open" set is probably the wrong word; I should probably say "Extensible"
> set. This reflects that SWIMA can convey records using any inventory record
> structure and imposes no limits on those structures.
> [NCW] Perhaps this section could be moved to “after” the explanation of the
> PA-TNC messages.  I get it now, but consistency to the use of the terms
> message and record should be made (or clarified).

<CMS>
I think it would be problematic to move the discussion of data models so late, but I'll add clarification to explicitly disambiguate messages, records, and data models.

> [NCW] and here are a few more comments:
> Section 1 state: “This specification is designed to only report software that is
>    installed on an endpoint.”
>   Suggest to: “a target endpoint”  (same for the following sentence)

<CMS>
Agreed. There are lots of places where this switch would be helpful so I'll do a global search and make the changes.

> Section 3.3 or somewhere in Section 3: it would be good to actually see the
> flow within the NEA architecture and encapsulations

<CMS>
I previously included a diagram showing the PA-TNC attribute encapsulations within PA-Messages and PB messages. However, it was decided that this was redundant with the PA-TNC specification and wasn't necessary information for SWIMA implementers. As such, it was removed. 

> Section 3.3 “SW-PVs MUST discard without error any SW Response attributes
> that
>    they receive for which they do not know the SW Request parameters
>    that led to this SW Response.”
> - Why is this a MUST?  This can be done by policy as an implementation can
> choose to discard or send an error if the entire response if it only gets
> attributes it doesn’t understand.

<CMS> 
The reason the SW-PV MUST discard the data is that without knowledge of the request parameters the response recipient cannot know if the request was targeted or complete. Without this knowledge, they cannot accurately use the response to update their understanding of the endpoint software inventory. Note that we do not require the SW-PV in question to have sent that SW Request; just that it "knows" the request parameters. This leaves open other channels for conveying the information. 
The reason the SW-PV MUST discard *without error* is that, in a multi-component scenario, there might be multiple SW-PVs on the verifier endpoint and a response might be meant for one but not the other. (We suggest, but do not require, exclusive delivery to avoid this situation.) If the unintended recipient responds to the situation with an error then the response sender might get confused as to whether their response was accurately received. This could be especially problematic during subscriptions, where it is important for the PV and PC to have synchronized state. 
The bottom line is that, while this is an edge case, prohibiting error messages and requiring discarding of the data ensures that both parties have an accurate understanding of the state of the system.

> - What about a SW-PC getting a request it can not honor (e.g. it doesn’t
> understand any of the attributes or due to its own policy)?

<CMS>
Section 3.9 (Error Handling) covers this. Specifically, if the Request is bad it is to use standard PA-TNC error codes. If the request is good but cannot process the request for some reason (such as policy) then it sends on the SWIMA error codes. (In the case of policy, it would probably be the generic SW_ERROR, since we do not define a dedicated error for policy violations.)

> - Are these messages to be protected?  It seems that unless there is a guard
> against replays and request matching, it could be an attack vector?

<CMS>
The SWIMA specification does not explicitly deal with this. There is the observation that stored information should be protected (7.2) and general PA-TNC security threats (7.6) would cover the threat vectors you describe and are dealt with in PA-TNC. The use of PT-TLS as the transport layer for this protocol would provide confidentiality and integrity protection.

> Section 5.4
> - Why is there only a SW Request and not a SW [inventory] response?

<CMS>
Primarily to reduce the number of words in attribute names. Currently the 4 possible responses to a SW Request are Software Identifier Inventory, Software Identifier Events, Software Inventory, and Software Events (depending on what the request requests).  That said, the other attributes explicitly identify Request-Response pairs. I am not opposed to adding "Response" to the names of these attributes if you think it would help with clarity.

Please let me know if you have any questions or disagree with any of my assertions. Thanks again for the review and comments.

Charles