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

From: Andreas Steffen <[email-masked]>
Date: Tue, 1 Aug 2017 14:59:53 +0200

Hi Adam,

see my inline comments

On 31.07.2017 21:51, Adam Montville wrote:
> 
> 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. 
>
A SW Request can very well be a SW Attribute. Have look at RFC5792
PA-TNC were the standard Attribute Request Attribute is defined

  https://tools.ietf.org/html/rfc5792#section-4.2.1

which can be used by a Posture Validator to request any number of
PA-TNC attributes from a Posture Collector.

> 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.
>
SWIMA is the acronym for *Software Inventory Message and Attributes",
i.e the I-D document is about Software Inventory Attributes being
transported in PA-TNC messages of PA Subtype "SW Attributes".

Since a Posture Validator can request either a SW [Identifier] Inventory
Attribute or a SW [Identifier] Events Attribute, SW Request is a
very good description for the request.

> 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? What about discovered
> software outside typical installation patterns? And, does it make sense,
> in a brokered architecture like NEA, to require redundant capabilities
> in the anticipated myriad collectors?>
Before the advent of SWIMA, simple software inventory information
(Package Name/Package Version Number) available from a Linux Package
Manager had to be sent in a standard Installed Packages Attribute
accompanied by a standard Product Version Attribute (giving information
about the underlying Operating System), both attributes defined in
RFC5792 PA-TNC. Thus a minimalistic SWID 2015 tag of the form

  <SoftwareIdentity name="tar"
    tagId="Ubuntu_16.04-x86_64-tar-1.28-2.1ubuntu0.1"
    version="1.28-2.1ubuntu0.1" versionScheme="alphanumeric">
    <Entity name="strongSwan Project" regid="strongswan.org"
      role="tagCreator"/>
  </SoftwareIdentity>

carries about the same information and the software release can be
uniquely referenced by a Software Identifier of the form

  strongswan.org__Ubuntu_16.04-x86_64-tar-1.28-2.1ubuntu0.1

Hopefully some time in the not too distant future Ubuntu in the
role of a distributor would then release signed reference SWID 2015
tags e.g. with a Software Identifier of the form

  ubuntu.com__16.04-amd64-tar-1.28-2.1ubuntu0.1

retrievable from the page manager.

I think for most use cases the SWID 2015 Data Model can be used. I'm
not sure about the relevance of the SWID 2009 Data Model because only
about a dozen of tags seem to exist in the wild.

The extensibility of the Data Model via the PEN/Type mechanism is
very important. I think there are shortly going to be SWID 2015
variants, e.g using a JSON or CBOR encoding of the SW record.

Hope this helps

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: Adam Montville <[email-masked]>
Date: Wed, 02 Aug 2017 10:18:14 +0000

Thanks! This does help, yes.

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 3 Aug 2017 15:42:14 +0000

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.

> 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.
>
> 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 <[email-masked]
> <mailto:[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
> 
> 	_______________________________________________
> 	sacm mailing list
> 	[email-masked] <mailto:[email-masked]>
> 	https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 3 Aug 2017 18:14:30 +0200

Hello Charles,
hello group,

from the list of topics discussed, l an cherry-picking just one implicit 
topic: the Registry for Software Data Models and CoSWID. I bring this up 
based on this hand-selected quote:

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

We already had an MTI discussion and I certainly do not want to rekindle 
that one. SWIMA has a "flexible data representation mechanism" and 
CoSWIDs are also defined in the SACM WG - so my question is: what would 
the group like to do here?

- Reference CoSWID directly in the SWIMA document in 10.4. Registry for 
Software Data Models, which would increase visibility, I think, or

- Include a corresponding IANA request for the Registry for Software 
Data Models in the CoSWID document?

My personal preference is to include them in SWIMA now, as CoSWID are 
always inter-operable with the existing two entries and including the 
registration in SWIMA will expedite the next actions for CoSWID.

I think Charles brought that exact question up once already, but there 
was neither push-back nor support (aka indifference). In respect to 
Charles question a few months ago: Including CoSWID in the registration 
list would have my support.

Viele Grüße,

Henk

On 08/03/2017 05:42 PM, Schmidt, Charles M. wrote:
> [email-masked]

---

From: Ruben Oliva <[email-masked]>
Date: Thu, 3 Aug 2017 22:59:54 -0400

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. <[email-masked]>
To: Adam Montville <[email-masked]>; Karen O'Donoghue <[email-masked]>; sacm <[email-masked]>
Sent: Thu, Aug 3, 2017 11:42 am
Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

Hi Adam,

I like the rewording.

Charles

---

From: Adam Montville <[email-masked]>
Date: Fri, 04 Aug 2017 11:07:02 +0000

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. <[email-masked]>
wrote:

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

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

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

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

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

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

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

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 4 Aug 2017 14:09:55 +0000

Hi Adam,

Sounds like we are mostly aligned. I've trimmed the points where it looks like we are on the same page and responded inline to the others.

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

<CMS>
I think that this stems from confusion about what "MTI" means for records in SWIMA. SWIMA never requires that any given type of record be collected from an endpoint. An endpoint might have hundreds of SWID tags on it, but a compliant SWIMA specification might never touch them and instead choose to gather some other indicator of software installation. (For example, a SWIMA implementation might feel that RPM records are likely to be more complete and accurate than any SWID tags that might get installed across the endpoint.) The SWIMA specification is explicit that it only requires collection to be done in an internally consistent manner (i.e., it cannot use one source in one report and ignore that source in a subsequent report) but it never requires the use of any specific source of information. In short, a SWIMA implementation can make use of whatever information is available in whatever way it chooses, provided that it uses those sources consistently.

All the MTI requirement means is that every compliant SWIMA-PC MUST know how to take any 2009 or 2015 SWID tag it does collect (*if* it collects any at all) and deterministically derive a standard Software Identifier from that record. The issue this tries to address is that we would need a one-to-one mapping between information records describing software and the Software Identifier that is the shorthand for the described software. Unfortunately, there are lots of ways to do such a mapping, so there could be variation across implementations as to how a given piece of software is represented by a Software Identifier. By making 2009 and 2015 SWID tags MTI, all we are doing is ensuring that every SWIMA implementation will have the same one-to-one mapping between a given tag and its Software Identifier. This means that, at least for SWID tags, two collectors (from different vendors) will use the same Software Identifier for the same SWID tag, and thus those Identifiers can be directly compared.

This might get at your "redundancy" comment too - if MTI meant "required collection", then yes, requiring both types of tags be collected could be redundant. However, that is not the requirement. All the MTI statement requires is that SWIMA implementations are universally consistent in their mapping of 2009 and 2015 SWID tags to Software Identifiers. I don't think that is redundant - it is just better covering the bases.

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

<CMS>
If you are talking about "how to convert to a SWID tag", I think that is beyond the scope of SWIMA. (Maybe if SACM decides someday to endorse SWID tags as the official record format for software information, that might be reasonable, but for now I think it would be premature.)

If you are talking about how to represent records other than SWID tags within SWIMA messages, I'm not sure that is necessary because the specification itself is completely generic. We just talk about records and Software Identifiers.  

> 	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.
> ready and able to convey it. Until then, SWIMA's goal is to support collection
> and conveyance of whatever software records might be available.
> 
> 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.

<CMS>
See my earlier comment about redundancy - if this is related to concerns about require collection of records, SWIMA never imposes such a requirement. 

To answer your question, no - ideally we would hope that those collectors would not use a separate PA-TNC binding. In fact, no extension of this draft is necessary for RPM package manifests to be used directly in SWIMA. Any representation of installed software can be directly conveyed by SWIMA. Of course, if that representation hasn't been standardized in the IANA table, then two different vendors might identify that data model differently and use a different algorithm to derive Software Identifiers from those records, making direct comparison between their findings more challenging, but at least within that vendor's product space there would be no problem. (The advantage of the IANA table entries, is that the data model type identifier of the record will be the same across all implementations and the algorithm to derive the Software Identifier will be the same, allowing any such records to be directly compared across vendor boundaries.) 

So, in the current draft, any vendor could declare that an RPM manifest entry was a utilized Data Model Type, create a way to create a Software Identifier from each manifest entry, and start sending those to a consumer via SWIMA with no extensions necessary. Of course, vendor 2 might do the same thing, but would use a different type identifier and Software Identifier algorithm. In either case, however, the information is collected and delivered.

Does this address your questions?

Thanks,
Charles

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 4 Aug 2017 14:25:07 +0000

+1 

I think it would be great if SWIMA named an IETF record format (CoSWID) in addition to the current ISO record format (SWID).

For those who didn't dig all the way into my response to Adam, all the IANA entry does is ensure that all SWIMA implementations 1) use the same data model identifier for that format and 2) have the same algorithm to derive a Software Identifier from record instances.

I think it is reasonable and appropriate to ensure these are both the case for IETF's home-grown software information description structure.

Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Henk Birkholz
> Sent: Thursday, August 03, 2017 11:15 AM
> To: [email-masked]
> > 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.
> 
> > 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
> > That said, it probably makes sense to add an informational reference to the
> NIST specification for the reasons you mention.
> >
> > 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?
> >
> > 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
> 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.
> >
> Attributes according to our definitions, which I agree might be confusing. In
> that regard, SWIMA-PC and SWIMA Attribute better capture the key
> 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....)
> >
> (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.
> >
> 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.
> >

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 4 Aug 2017 14:41:52 +0000

David,

At NIST we are adding SWID Tags as an SCAP specification in SCAP 1.3 which will be released soon. We also have a some SCAP 1.2 validated products that support SWID tags today.

AT NIST, we support the use of SWID tags to address a number of security automation use cases. We hope that the SWID-related standards created in the IETF and other standards organizations will provide a basis for further adoption of SWID tags in open source and commercially available tools. In the USG, we are constantly faced with identifying what software is in use across agencies. Despite investments in software asset management (SAM) and other software inventory solutions, we are unable to automatically and quickly gather information about how much of a given software product is installed across the USG. Software vulnerabilities like Heartbleed pointed out how challenging of a problem this is. The cause of this problem is twofold: 1) SAM products use different mechanisms to determine the software inventory of devices, and 2) different SAM, vulnerability, and patch management products identify software in inconsistent ways. If SWID tags are adopted by the majority of major software vendors (20-30 companies), this problem will largely be solved. IMHO, as a file that can be generated automatically during software builds and packaged with software, SWID tags are a small cost relative to the significant management costs that vendors and end-users face when dealing with licensing, patching, and otherwise managing deployed software. SWID tags are a win-win; they help vendors ensure that customers use licensed products and help customers manage the software they acquire.

At NIST we are starting work on an SCAP 2.0. Our current use-case focus is around better support for vulnerability assessment, and we plan to iterate around different use cases in subsequent releases. We want to use standards like SWID tags, SWIMA and ROLIE which can provide for the collection and exchange of SWID tag data as part of a larger SCAP architecture. The work in MILE and SACM is important and can fill software identification and inventory gaps that exist in SCAP 1.x.

Regards,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Ruben Oliva
Sent: Thursday, August 03, 2017 11:00 PM
To: [email-masked]; [email-masked]; Karen O'donoghue <[email-masked]>; [email-masked]; Waltermire, David A. (Fed) <[email-masked]>
Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

Charles and team:

So my question is.

David Oliva

-----Original Message-----
From: Schmidt, Charles M. <[email-masked]<mailto:[email-masked]>>
To: Adam Montville <[email-masked]<mailto:[email-masked]>>; Karen O'Donoghue <[email-masked]<mailto:[email-masked]>>; sacm <[email-masked]<mailto:[email-masked]>>
Sent: Thu, Aug 3, 2017 11:42 am
Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

Hi Adam,

I like the rewording.

Charles

> On Fri, Jul 28, 2017 at 10:41 AM Karen O'Donoghue <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]?>> > wrote:
>
>
> Folks,
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]?>>

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Fri, 04 Aug 2017 16:15:05 +0000

I think I'm all set, Charles, thanks for your patience. :-)

On Fri, Aug 4, 2017 at 9:10 AM Schmidt, Charles M. <[email-masked]>
wrote:

> Hi Adam,
>
> Sounds like we are mostly aligned. I've trimmed the points where it looks
> like we are on the same page and responded inline to the others.
>
> >       > Software Identifiers for the data model types specified in
> Section 6
> > of this
> all
> collector
> I think that this stems from confusion about what "MTI" means for records
> in SWIMA. SWIMA never requires that any given type of record be collected
> from an endpoint. An endpoint might have hundreds of SWID tags on it, but a
> compliant SWIMA specification might never touch them and instead choose to
> gather some other indicator of software installation. (For example, a SWIMA
> implementation might feel that RPM records are likely to be more complete
> and accurate than any SWID tags that might get installed across the
> endpoint.) The SWIMA specification is explicit that it only requires
> collection to be done in an internally consistent manner (i.e., it cannot
> use one source in one report and ignore that source in a subsequent report)
> but it never requires the use of any specific source of information. In
> short, a SWIMA implementation can make use of whatever information is
> available in whatever way it chooses, provided that it uses those sources
> consistently.
>
> All the MTI requirement means is that every compliant SWIMA-PC MUST know
> how to take any 2009 or 2015 SWID tag it does collect (*if* it collects any
> at all) and deterministically derive a standard Software Identifier from
> that record. The issue this tries to address is that we would need a
> one-to-one mapping between information records describing software and the
> Software Identifier that is the shorthand for the described software.
> Unfortunately, there are lots of ways to do such a mapping, so there could
> be variation across implementations as to how a given piece of software is
> represented by a Software Identifier. By making 2009 and 2015 SWID tags
> MTI, all we are doing is ensuring that every SWIMA implementation will have
> the same one-to-one mapping between a given tag and its Software
> Identifier. This means that, at least for SWID tags, two collectors (from
> different vendors) will use the same Software Identifier for the same SWID
> tag, and thus those Identifiers can be directly compared.
>
> This might get at your "redundancy" comment too - if MTI meant "required
> collection", then yes, requiring both types of tags be collected could be
> redundant. However, that is not the requirement. All the MTI statement
> requires is that SWIMA implementations are universally consistent in their
> mapping of 2009 and 2015 SWID tags to Software Identifiers. I don't think
> that is redundant - it is just better covering the bases.
>
> If you are talking about "how to convert to a SWID tag", I think that is
> beyond the scope of SWIMA. (Maybe if SACM decides someday to endorse SWID
> tags as the official record format for software information, that might be
> reasonable, but for now I think it would be premature.)
>
> If you are talking about how to represent records other than SWID tags
> within SWIMA messages, I'm not sure that is necessary because the
> specification itself is completely generic. We just talk about records and
> Software Identifiers.
>
> collection
> separate
> See my earlier comment about redundancy - if this is related to concerns
> about require collection of records, SWIMA never imposes such a requirement.
>
> To answer your question, no - ideally we would hope that those collectors
> would not use a separate PA-TNC binding. In fact, no extension of this
> draft is necessary for RPM package manifests to be used directly in SWIMA.
> Any representation of installed software can be directly conveyed by SWIMA.
> Of course, if that representation hasn't been standardized in the IANA
> table, then two different vendors might identify that data model
> differently and use a different algorithm to derive Software Identifiers
> from those records, making direct comparison between their findings more
> challenging, but at least within that vendor's product space there would be
> no problem. (The advantage of the IANA table entries, is that the data
> model type identifier of the record will be the same across all
> implementations and the algorithm to derive the Software Identifier will be
> the same, allowing any such records to be directly compared across vendor
> boundaries.)
>
> So, in the current draft, any vendor could declare that an RPM manifest
> entry was a utilized Data Model Type, create a way to create a Software
> Identifier from each manifest entry, and start sending those to a consumer
> via SWIMA with no extensions necessary. Of course, vendor 2 might do the
> same thing, but would use a different type identifier and Software
> Identifier algorithm. In either case, however, the information is collected
> and delivered.
>