[sacm] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-sacm-nea-swima-patnc-02: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

[incoming AD getting practice with document review; please treat as
No Objection with COMMENT]

The Introduction comes off as very strongly supporting this
technology and implying that it's useful in all scenarios, but my
understanding is that the benefits and applicable scenarios are more
limited.  (Section 2 and the rest of the document seem more akin to
what I would expect, which is good.)  My understanding is that the
primary benefit of this work is in managed environments where there
is an expectation that only a central authority within a given trust
domain will be installing/updating software, and so this mechanism
can be used to audit for policy compliance, in terms of things like
whether updates are taken in a timely fashion, and blocking
certain types of "role-based" access where the presence of certain
software indicates a certain role.  There are of course other
situations where it could be useful, and I'm probably missing some
of them, but the limitations called out in (e.g.) Section 7.1 do
seem to give the guidance that this mechanism should not be relied
upon directly as a security measure with any great deal of weight.
So, perhaps the Introduction could say things like "useful to
understand and maintain the security state of a managed network",
"Some sites have a need for a standardized method for exchanging
software inventory data", etc.


I'll also second Eric's concerns about the privacy considerations,
with a callout for the error descriptions as well -- there's a
history of cleartext error strings on the wire leading to attacks
(albeit usually against cryptography and not a higher-level
protocol).


Section 2.3

      Efficiency is also important when one considers that some network
      endpoints are small and low powered, some networks are low
      bandwidth and/or high latency, and some transport protocols (such
      as PT-EAP, Posture Transport (PT) Protocol for Extensible
      Authentication Protocol (EAP) Tunnel Methods [RFC7171]) or their
      underlying carrier protocol might allow only one packet in flight
      at a time or only one roundtrip.

I think I'm a little confused at how this protocol could be useful at all
with only one roundtrip -- or does roundtrip just mean one
request/response exchange, which could involve lots of packets and
potentially take longer to deliver than the path RTT?  (The latter
could maybe make sense in an EAP scheme where you need to verify the
client environment before allowing access, though see above
disclaimer about this not seeming like a strong security mechanism.)

Also Section 2.3

Can we REQUIRE the underlying transport to provide confidentiality,
or is there some historical baggage that requires us to allow the
possibility of cleartext transport?  To be clear, my preference
is in general for in-protocol message protection, but I recognize
that there are scenarios where that doesn't always work well or is
redundant.


I'm a little concerned that there are some broad MUST-level
requirements that seem hard to know if they can actually be
implemented reliably, like only using a data source in the posture
collector if it is known that it can meet all the listed
requirements both now and in the future, or the requirements for
consistency across time about how various information is handled.
This makes updating the PC software pretty risky.  Another example
is saying that "Even a probable location for a software product is
preferable to using a zero-length locator." so that once we pick one
we can't change what is reported.  (I guess we're supposed to
DELETE+CREATE in this scenario?)


In Section 3.6

It seems a little odd to me that we need to keep last state prior to
deletion even around, but we don't need to be able to provide the
full alteration history -- that makes an alteration event seem like
a weaker piece of data than delete+create would be, whereas intution
might think that they should have the same information content.

Section 5.6

   Request IDs can be randomly generated or sequential,
   as long as values are not repeated per the rules in this paragraph.
   SWIMA-PCs are not required to check for duplicate Request IDs.

The birthday bound for a 32-bit number is not a super-great margin
of comfort for a random selection, though I guess the consequences
of a collision are not catastrophic.


It makes me a little sad to see an ASCII time representation used when more
space-efficient options are available and we've already got binary
integers going on the wire.  Seconds since the epoch might even be
enough for this work, or for more precision 100s of nanoseconds
since the epoch is also seeing some notable use.


Editorial nits:


There's a typo in the abstract (for "Trusted").

As a general note, "Software Inventory Message and Attributes for
PA-TNC" is written out in full many times in the document (including
in tables); does it make sense to abbreviate it more often or just
refer to "this document" or "this specification" or similar?

Section 1.3, "Endpoint's Software Inventory Evidence Collection":

   [...], information generated to report output from
   software discovery tools, and [...]

Maybe this makes more sense with s/to/from/?  The current text
leaves me pretty confused (so maybe my suggestion is bunk).


Section 3.2

   Do not confuse the "data model" described here with the SWIMA
   messages and attributes used to convey information between SWIMA-PVs
   and PCs.  The SWIMA specification dictates the structure of its
   messages and attributes.  Some attributes, however, have specific
   fields used to convey inventory records, and those fields support an
   extensible list of data models for their values.  By contrast, a data
   model refers only to the structure used to organize software
   inventory record data.

We probably should disambiguate all occurrences of "data model" in this
paragraph, just to be clear.


Section 3.4.1

       Instead,
       to reliably distinguish between multiple instances of a single
       software product, one needs to make use of Record Identifiers,
       described in the following section.

actually it's section 3.4.3 now, not directly following.


Section 3.4.2

   Clearly identifying the type of
   data model from with the Software Identifier was derived thus
   provides useful context for that value.

"from which"


Table 7 should disambiguate the initial Status Flags field, as the table
currently has two mentions of "Flags" that mean different things.


Section 5.15

   When sending to a giving SWIMA-PV, the SWIMA-PC MUST use the
   recipient SWIMA-PVs Source Identifier associations.

s/giving/given/
Also, maybe mention what scope of private agreement is needed on the
interpretation of the metadata, which is basically opaque as far as SWIMA is
concerned.  That is, is this something agreed upon just between a
specific PC
and PV, or expected to be agreed upon in a broader group (e.g.,
organization)


Section 5.16.1 et seq

Should we say something about how the length of the variable-length
description field is know from the length of the PA-TNC attribute?