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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 7 Aug 2017 04:54:17 +0000

Hi,

Not being familiar with SWIDs and trying to get thru this draft,  I will provide initial comments though I’m still only on Section 3.

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.

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

-	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

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?  

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

Section 2.2: is this section necessary?  There are many more use cases not supported, so would opt to remove this section.

Section 2.3: There must be normative language to make these requirements.  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

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

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

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

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

More to come soon,
	Nancy

On 7/28/17, 7:40 AM, "sacm on behalf of Karen O'Donoghue" <[email-masked] on behalf of [email-masked]> 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

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 7 Aug 2017 16:59:36 +0000

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

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

> 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

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.

> identified software’s patch level data.”

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

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

> 	Nancy

Great! Thanks a bunch for the feedback.

Charles

> On 7/28/17, 7:40 AM, "sacm on behalf of Karen O'Donoghue" <sacm-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Folks,
> 
>     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.
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Andreas Steffen <[email-masked]>
Date: Mon, 7 Aug 2017 21:43:19 +0200

Hi Charles,

I fully agree with your statements and explanations.

Kind regards

Andreas

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

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 14 Aug 2017 20:48:34 +0000

Hi Charles,

Apologies as I ran out of time, so didn’t get to fully read the spec, but below are my responses and a couple more comments.

Please see below:

On 8/7/17, 9:59 AM, "sacm on behalf of Schmidt, Charles M." <[email-masked] on behalf of [email-masked]> wrote:

    Hi Nancy,

    
    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.) 
[NCW] Got it, that helps.

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

    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. 

[NCW] That’s fine.

    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.

    

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

    
    
    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.

    
    It does not require any particular way of accomplishing reliable delivery (e.g., TCP) - just that reliable delivery is required.
[NCW]  A clarification will be good.

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

    
    
[NCW] Sounds good.
    
    > 	Nancy
[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)

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

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

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

    Charles