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

[Ruben Oliva <[e-mail]>]

Charles and team:
 
I have been following the progress of SACM since around 2012 and like what I see, but I am still too used the way NIST/SCAP works.

Somehow I thought that NIST (via the NVLAP labs) would include SWID as another SCAP specification.
 
>From what I can tell, there is no SCAP product that uses SWID (https://nvd.nist.gov/scap/validated-tools).
As it is now, there is no incentive of any kind to embrace SWID for users of SCAP products,
even though NIST appears to endorse it (IR 8060 and IR 8085).
 
 
So my question is.
 
Will SWID be included in any future NVLAP testing and be advertised as an NIST-validated SCAP tool?
 
 
 
David Oliva
 
 
-----Original Message-----
From: Schmidt, Charles M. <[e-mail]>
To: Adam Montville <[e-mail]>; Karen O'Donoghue <[e-mail]>; sacm <[e-mail]>
Sent: Thu, Aug 3, 2017 11:42 am
Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

Hi Adam,

A few inline comments added to those made by Andreas. (And thanks to Andreas for his inputs.)

> Should we be referencing the NIST interagency report related to SWID or the
> ISO standard directly? The NIST document is more readily accessible, and if
> they have parity, then we might gain points for referencing the freely
> available resource.

The NIST and ISO documents are not equivalent. The NIST document describes best practices for using and creating SWID tags, and someone could use that and the freely available SWID tag XML schema to create compliant tags. However, the ISO document remains the authoritative source for SWID tag compliance. As such, I feel most references should be made to the (authoritative) ISO specification.

That said, it probably makes sense to add an informational reference to the NIST specification for the reasons you mention.

> Is there a reason to mention TCG + NEA in the introduction? If we're looking
> at NEA, then let's just use NEA references and not the TCG ones for, at least,
> the sake of consistency.

I think there are a few reasons to at least mention the relationship to TCG's TNC.
1) It emphasizes that there is alignment (rather than bifurcation) in these standards.
2) It sends a reasonable call out to the TCG board, who agreed to support transfer of this specification to the IETF.

That said, I can agree that Table 1 (which identifies equivalent components in the two architectures) might be more than is necessary. If we drop Table 1 but retain the final paragraph of section 1.1 ("This document is based on standards published by the Trusted Computing Group's Trusted Network Communications (TNC) workgroup. The TNC and NEA architectures are interoperable and many components are equivalent.") would this address your concern?

> Propose modified definition for SW-PC: A Posture Collector (PC) that collects
> endpoint software inventory information and that conforms to this
> specification.
> 
> Propose modified definition for SW-PV: A Posture Validator (PV) that
> interprets SW Attributes sent by SW-PCs and that conforms to this
> specification.

I like the rewording.

> Propose modified definition for SW Attribute: A PA-TNC attribute that
> conveys software inventory information. (NOTE: We should ensure that PA-
> TNC is the NEA-specific term.)

In retrospect, I'm not sure I like this or what currently exists. There are PA-TNC attributes that convey software information, but are not "SW attributes". Moreover, (for reasons you noted) the requests don't convey software information, but need to be considered SW attributes for the sake of this document. That term needs to refer specifically to the attributes that are defined in this specification. I propose:

SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 [RFC5792]) extension as defined in this specification.

> Propose renaming "SW Attribute" to "SWIMA Attribute", which seems more
> accurate. Take a look a the "SW Attribute" subtypes listed in section 5.2 to
> understand my motivation. Assuming "SW" expands to "software" (which is a
> reasonable presumption), then SW Request is not a SW Attribute. A SW
> Attribute might be a configuration item that software contains, but not a SW
> Request. The SW Request attribute is used to request software inventory
> related information from an endpoint, and is thus more appropriately an
> attribute associated with SWIMA than with "software". If this is acceptable,
> then we should update the term in section 10.1.
>
> Then, we may want to consider expanding "SW" to "SWIMA" wherever
> appropriate (i.e. SW Request could become SWIMA Request), which is longer
> to type but also inarguably more clear.

Stephen's comments notwithstanding, I'm of two minds here. On the one hand, SW Attribute (and SW-PC and SW-PV) are primarily characterized by their conformance to the SWIMA specification, rather than just being software related. There are other NEA components that deal with software but are not part of SWIMA and therefore would not be SW-PCs or SW Attributes according to our definitions, which I agree might be confusing. In that regard, SWIMA-PC and SWIMA Attribute better capture the key characteristic of these entities.

On the other hand, a "Software Inventory Message and Attributes Attribute" seems a bit redundant. 

Overall, I think I might be more inclined to go along with your suggestion and change SW Attribute to SWIMA Attribute (and SW-PC to SWIMA-PC, etc.) because it will better emphasize the key characteristic of these entities - that they are conformant to the SWIMA specification. (Really looking forward to a few hundred search and replace actions here....)

> On Page 15 the draft states "All SW-PCs MUST at least be able to generate
> Software Identifiers for the data model types specified in Section 6 of this
> document." Section 6 describes data models for SWID 2009 and SWID 2015,
> but nothing else. Is this really what we desire? What about Linux distribution
> package managers? 

Adding on to Stephen's comments, I'll note that we intend SWIMA to be extensible. If someone wished to report RPM records or other types of packages, they are welcome to do so. The just need to define an authoritative way of deriving a Software Identifier from the record. However, I don't think we want to *require* support for such packages in all SW-PCs.

> What about discovered software outside typical
> installation patterns? 

As Andreas notes, such software can still be represented using SWID tags. They could also be represented using other record formats, as I note above.

> And, does it make sense, in a brokered architecture like
> NEA, to require redundant capabilities in the anticipated myriad collectors?

Not sure how this is "redundant". The group agreed that 2009 SWID tags should be supported for legacy reasons, while 2015 tags should be supported for future compliance. In general, SWIMA has virtually no control over the nature of the records on the endpoint - they might be SWID 2009, SWID 2015, something completely different, or a combination thereof. SWIMA is concerned with collection and conveyance of available information. Normalization of that information into one preferred record format is beyond the scope of SWIMA. (Deliberately so, since our early conversations on SWIMA involved a lot of holy wars about preferred record formats, none of which appear to "dominate" are target environment today.) Maybe SACM will eventually get behind a single format, and when they do SWIMA will be ready and able to convey it. Until then, SWIMA's goal is to support collection and conveyance of whatever software records might be available.

> Are the subscription semantics of this draft intended to be extrapolated to
> other types of information collection going over PT-TLS in the future? This
> wasn't clear to me when reading the draft, but the IANA table additions
> (section 10.2) relating to subscriptions appear to have names generic enough
> to be reused. If that's the intent, then maybe we can figure out an easy way
> to clarify this in the draft, so that subsequent collection drafts are easier to
> create.

I was not intending to create a generic subscription mechanism for PA-TNC. (Subscriptions would be at the application layer, rather than transport layer, which is what PT-TLS is.) I'm not sure a generic subscription mechanism for PA-TNC is really feasible since different types of information will have different triggers and different transport constraints.

With regard to the generic names of the attributes: on a technical level, there will be no ambiguity. The attributes defined in this specification (with the exception of PA-TNC Error) are all part of the SWIMA PA Subtype. (Basically, this serves as a namespace for all the attributes defined in this specification.) Some other PA-TNC extension might conceivably define their own "Subscription Status Request" attribute, but it would have a different PA Subtype, so there would never be any confusion as to meaning. True - a human might get confused; however, I think this is mitigated by the fact that the attribute names really only are used within the context of a specific PA TNC extension (e.g., within the SWIMA specification). Thus I don't think there will be many practical opportunities for people to get confused. As such, I'd prefer to keep the names as they are rather than to make them even longer by prepending SWIMA or some other specification-specific label.

Please let me know if you have any questions or comments.

Charles

> On Fri, Jul 28, 2017 at 10:41 AM Karen O'Donoghue <[e-mail]
> <mailto:[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] <mailto:[e-mail]>
> 	https://www.ietf.org/mailman/listinfo/sacm
> 

_______________________________________________
sacm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sacm