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

[Adam Montville <[e-mail]>]

Thanks to both of you for your responses...  I have my own inline. Please
note that I'm heading out on vacation for two weeks, so my response time
may lag a bit, but I will be checking in from time to time.



On Thu, Aug 3, 2017 at 10:42 AM Schmidt, Charles M. <[e-mail]>
wrote:

> 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?
>
>
[AWM] This was less of a 'concern' than an observation (i.e. not a
strenuous objection). If folks feel the table is worthwhile, then by all
means keep it. If we can safely drop it (i.e. remove it without losing the
point of what we really want to convey), then do that in the name of better
communication.


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

[AWM] This seems acceptable, given that we need to work with terms defined
elsewhere. Thanks for considering.


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

[AWM] Yes, it's a lot of search and replace, but in the end I really think
this will help future understandability and I appreciate the effort. And,
thankfully, most folks are likely to simply pronounce the acronym "SWIMA"
rather than spell it out (because it is, technically, redundant).


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


[AWM] I was looking at this a bit differently, I think. If there is a
collector capable of expressing RPM packages, as an example, and they want
to extend this to shuttle that information over PT-TLS, then would they
need to also collect 2009 and 2015 SWIDs? It seems contrary to the point of
having posture brokers. Maybe I'm missing something.


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

[AWM] Do we need to mention how? If so, is this the right place to do that?


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

[AWM] Maybe I should ask this way. Is the expectation that RPM package
management collectors, for example, would require a separate specification
for shuttling over PT-TLS, or that they would extend this draft? If a
separate specification, then I retract my comments, because then SWID data
models aren't necessary. If an extension of this draft, then my comment
remains.


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

[AWM] Thanks for your reasoning :-)


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