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

[Andreas Steffen <[e-mail]>]

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                         [e-mail]
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]==