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

["Schmidt, Charles M." <[e-mail]>]

Hi Nancy,

Thanks a bunch for the comments. Responses inline:

> My general read of this was that it would be a SWIDs mapping to either a
> particular data model to adhere to SACM and/or that it would use the NEA
> data model and transfer using PA-TNC and PB-TNC.  Is that correct?  I do not
> get that impression from Section 3, so am somewhat confused.

A few points: SWIMA is not SWID-specific. (The first drafts were, but it has since changed to support an extensible list of software inventory records, of which SWIDs are one possible record type.) 

Also, NEA does not have a single data model. Instead, the PA protocol is a "lightweight wrapper" for a set of attributes to be exchanged. These attributes are intended to be extensible to allow a growing set of bindings to be defined, each of which define their own conditions for Collectors and Validators, and each of which support their own network attributes and data model. 

So what you describe is not, in fact, the goal of SWIMA. SWIMA defines a NEA PA extension that defines new attributes and Collector/Validator behaviors to manage the collection and delivery of software inventory information.
 
> Here are some comments thus far:
> 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.

> -	As there are no references to the TNC standards (and those have
> been absorbed in NEA),
> I suggest to remove the last paragraph and Table 1 of Section 1.1

I agree the table is unnecessary. I do believe it is appropriate to retain the final paragraph to recognize that SWIMA came from TCG work and that this derivation is not a bifurcation.

> 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?

> Section 2, specifically 2.1.1 and 2.1.2 If the definition is to define a set of PA-
> TNC attributes; they are meant to be carried thru the NEA model; as such the
> recipient MUST be a NEA Server or at minimum a Posture Validator as that is
> the component that can accept NEA’s Posture Attributes.  I’m not sure these
> 2 sections are needed as they have to map to the NEA architecture which is
> described in 2.1.3

2.1.1 and 2.1.2 are intended to outline the specific purpose of the extension of the PA-TNC specification that creates SWIMA. In other words, they identify why SWIMA was created. The three use cases identified in PA TNC are: 
- Initial Client-Triggered Assessment - Client sends information when requesting to join a network
- Server-Initiated Assessment with Remediation - Verifier requests information from the client.
- Client-Triggered Reassessment - Client detects a situation where it needs to push updated information to the server.

All of these represent cases under which PA-TNC can operate. SWIMA supports these cases as well. They don't talk about the same thing as 2.1.1 or 2.1.2, though. 2.1.1 and 2.1.2 identify the uses of software inventory information supported by SWIMA; the PA-TNC use cases identify the cases under which information might be exchanged in general. These are non-overlapping and complementary.

> 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.

> Section 2.3: There must be normative language to make these requirements.

These are not requirements to implementers. These are design requirements for the specification itself. This is why these are not normative.

> 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?

> Section 2.5: What does it mean to “provide reliable delivery”?  Does this
> imply TCP vs UDP?

This is intended to mean that, if one party sends a message, the other party will either receive it or the sender will know it was not received. I'll add a clarification to that effect since, upon a quick search, it looks like there is no formal definition of the term. 

It does not require any particular way of accomplishing reliable delivery (e.g., TCP) - just that reliable delivery is required.

> Section 3.2 The beginning of the draft and title infers that this draft is a
> mapping for NEA, which does define its own data model…so how can these
> map to “an open set of data models”?

NEA does not define a single data model. It defines a framework which can be used to support an extensible list of attributes, each of which can support their own data model.

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.

> Editorial
> 
> Section: Introduction
> Awkward sentence: “When reported endpoint
>    software installation inventory lists, shortened to "software
>    inventories" for the remainder of this document, contain patch level
>    data for identified software, further comparison to vulnerability or
>    threat alerts can be used to determine an endpoint's exposure to
>    attack. “
> 
> If I understand the intent, I suggest: “Endpoint software installation
> inventory lists (hereinafter “software inventories”)
> can further be used to determine an endpoint’s
> exposure to attack based on comparison to vulnerability or threat alerts
> against
> identified software’s patch level data.”

Yeah - my sentence is overly convoluted. Your suggestion is a big improvement. Thank you.

> Section 1.3 “Software Identifier” has a first reference to SWIMA that should
> be referenced first;
> e.e. Software Inventory Message Attributes (SWIMA).

Per Adam's suggestion, I'll be using "SWIMA" to label a lot more things. I'll add a definition of this term to the introduction so we are covered for the document.

> More to come soon,
> 	Nancy

Great! Thanks a bunch for the feedback.

Charles

> On 7/28/17, 7:40 AM, "sacm on behalf of Karen O'Donoghue" <sacm-
> [e-mail] on behalf of [e-mail]> wrote:
> 
>     Folks,
> 
>     This begins a 3 week working group last call (WGLC) for the following
> document:
> 
>     Software Inventory Message and Attributes (SWIMA) for PA-TNC
>     https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/
> 
>     We have chosen to do a 3 week WGLC to account for post IETF recovery
> and August vacations.
> 
>     Please review the referenced document and send any comments to the
> mailing list including your assessment of whether this document is mature
> enough to proceed to the IESG. Please note that these messages of support
> for progression to the mailing list will be used to determine WG consensus to
> proceed.
> 
>     Please send all comments in by Friday 18 August 2017.
> 
>     Thank you!
>     Karen and Adam
> 
> 
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm