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

[Benjamin Kaduk <[e-mail]>]

On Sat, Feb 24, 2018 at 06:00:12AM +0000, Schmidt, Charles M. wrote:
> Hello,
> 
> Thanks a bunch for the comments. I agree and have implemented most of the changes. I have a few questions/responses:
> 
> > 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.  
> 
> I think SWIMA has a much broader use, including gathering information from endpoints where users control what software is added. That said, in re-reading the introduction I agree that it doesn't adequately convey that SWIMA standardizes transport but not detection. I'll update accordingly.

I guess there is some scope for its use on endpoints where users
can affect the installed software, yes.  Thanks for taking another
look at the actual wording.

> > 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.
> 
> NEA is designed to support an extensible list of PT (transport) protocols. Currently, the only NEA transport protocols defined are PT-TLS and PT-EAP, both of which provide confidentiality. I cannot think of why, but it might be the case that sometime in the future someone might create a PT protocol that does not provide confidentiality. If someone did this, I am not sure I would want to automatically preclude SWIMA from using it. In short, my preference would be to note this issue, but not dictate a specific response. Please let me know if you still feel that stronger requirements for confidentiality are necessary.

This seems pretty speculative to me, but not quite to the point that
I would ballot DISCUSS for it (if I could ballot, which I can't
yet).  If such a hypothetical future transport was standards-track,
it could (procedurally, at least) update this document to relax the
condition, anyway, so my personal inclination is to require
confidentiality at present and revisit later if needed.

> > 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?)
> 
> Could you expand on this? At the moment I feel the MUSTs are all necessary. In the case of "MUST meet all listed requirements", this is because a partially compliant source would not provide the consistent view that SWIMA needs. For example, if one source didn't allow event detection, that would mean that events could not reliably be used to update inventory information, violating a SWIMA-PV's assumptions. 

Probably I should treat this as a learning experience with my
practice ballot, having put some not-really-actionable comment in my
review.  Looking through the document again, maybe things like:

   With regard to alterations to a record, SWIMA-PCs MUST detect any
   alterations to the contents of a record.

could be problematic if the record format changes to add more fields
and the SWIMA-PC doesn't know to track the new fields (pretty
speculative, admittedly; I don't know how plausible either of those
are)

There's also the prohibition against coverage gaps, which I can
definitely understand wanting, but seems prone to Murphy's law.


> I'm not sure what you mean with regard to your concern about preferring "probable locations" to a lack of location, or how that relates to DELETE+CREATE events. Could you clarify?

It looks like this text was removed in the -03, but the idea was
that when first reporting an event, the SWIMA-PC would use a
"probable locator" as indicated by the -02.  What should the
SWIMA-PC do if it later discovers that this locator was erroneous
and now posesses a true locator for that software?  There is a MUST
level requirement to not change the reported locator for a given
installation of the software (IIRC), but it's known to be wrong.
Deleting this text seems to resolve the question in favor of "use a
zero-length locator if you're not sure", which is consistent at
least.  (I'm still not sure if it's worth doing a DELETE and
CREATEing a new entry if the actual software location is later
discovered, though.)

> > 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.
> 
> I am confused by this comment. The requirement to retain deleted records is different from the requirement to track alterations. The former is provided so that SWIMA-PVs are able to get additional data about a product that has been deleted, in the form of the deleted software's information record. Alteration, creation, and deletion are for tracking changes to software state. This needs to provide a complete history so that old state information can be updated to reflect new state. In this, alteration and delete+create are, in fact, of equal value. Am I misunderstanding your comment?

It is more likely that the misunderstanding was mine.  In that,
since the SWIMA-PC needs to be able to provide event history
including alteration events, the SWIMA-PV could request all the
relevant alteration events and track the state of that software
through the history that's retained.  My original comment would only
be valid if the alteration records did not contain a record of what
actually changed.

> > 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.
> 
> I would definitely be open to other formats as long as they are not too esoteric. RFC 3339 was just what the TNC uses in their protocols. I'm always for saving some bytes. Do you have a recommendation? 

I'm failing to find a good (i.e., IETF) citation, but my personal
recommendation is to have a 64-bit integer that counts time since
the epoch in units of 100 nanoseconds.  This is used in
http://afs3-stds.central.org/docs/draft-wilkinson-afs3-rxgk-11.html
and I'm pretty sure also some IETF work, even if I can't find it
right now.

> Beyond these questions, I agree with your comments and have updated the draft accordingly.
> 
> Thanks again for the input.

You're welcome!  I looked through the diff between -02 and -03, and
it looked good -- thanks for all the fixes!

-Benjamin

> Charles
> 
> > -----Original Message-----
> > From: Benjamin Kaduk [mailto:[e-mail]]
> > Sent: Wednesday, February 21, 2018 4:59 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-sacm-
> > nea-swima-patnc-02: (with COMMENT)
> > 
> > 
> > [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?
> > 
> > 
>