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

["Schmidt, Charles M." <[e-mail]>]

Hi Benjamin,

Thanks for following up. It looks like we are mostly on the same page. I have a few additional responses:

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

Thinking about this a bit more, I agree. I have made two changes to the section. First, I made it clear that the section is not about "things that are not required", but about requirements that are beyond the scope of SWIMA to meet. (Hopefully that will clarify things a bit better.) I also rephrased the section:

   There are certain capabilities that users of the SWIMA specification
   might require but which are beyond the scope of SWIMA itself and need
   to be addressed by other standards.  This list is not exhaustive.

   End to End Confidentiality:  The SWIMA specification does not define
      a mechanism for confidentiality, nor is confidentiality
      automatically provided by using the PA-TNC interface.  In the NEA
      architecture, confidentiality is generally provided by the
      underlying transport protocols, such as the PT Binding to TLS
      [RFC6876] or PT-EAP Posture Transport for Tunneled EAP Methods
      [RFC7171] - see Section 7 for more information on related
      standards.  The information conveyed by SWIMA is often sensitive
      in nature for both security (Section 8) and privacy (Section 9)
      reasons.  Those who implement SWIMA need to ensure that
      appropriate NEA transport mechanisms are employed to meet
      confidentiality requirements.

Does this better address your concerns?

--

> > > I'm a little concerned that there are some broad MUST-level
> > > requirements 
<SNIP>
> >
> > Could you expand on this? 
<SNIP>
>
> 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)

I'm not too worried about this because change detection can be extremely coarse. (I.e., it can be based on the record's "Modification timestamp" if it is a file, or based on comparing hashes of the record.) The structure of the record should be irrelevant for that level of change detection.

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

I agree this is a bigger lift, but, again, I'm not worried. It just means the SWIMA-PC needs to keep track of the records in the Evidence Collection. If it stops and restarts monitoring, it just needs to see how the Evidence Collection changes. As noted above, MODIFICATION detection can be very coarse. If it cannot figure out the delta, it just needs to change the Epoch to indicate a discontinuity and continue from there. (Noted in 3.7.1 Event Identifiers.) So, again, while this is a challenge, I think it remains reasonable.

--

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

I think I understand your concern: You were noting that, in the case of a DELETE action, the SWIMA-PV can request the historical record to see what used to be there. However, in the case of a MODIFY event, the SWIMA-PV has no way to collect the previous iteration of the record, and thus cannot compare to determine what changed. Thus, if there was a DELETE+CREATE event, one could take the old and new records (assuming one was able to line them up) and compare, but would not be able to perform such a comparison under a MODIFICATION. Is this your concern?

If so, then I do agree that there is a difference between what one can tell about the two event sequences. However, from a practical standpoint, I am not concerned about this. We do make it explicit in the specification that the old attribute cannot be collected via SWIMA, so this shouldn't be a surprise. I cannot think of any use cases where knowing the preceding state of the record is necessary - most of the uses of SWIMA I can imagine just need a way to capture the current state. If you can think of a reason that a consumer might need to know what changed in the record let me know, but I feel that simply knowing there is a revised record is sufficient for virtually all SWIMA uses.

--

Regarding the timestamp, I did some searching but I was also unable to find a standard expressed time in a more concise format. The Wilkinson draft you found didn't have a lot of detail. At this stage, I'm inclined to leave things be rather than create something unique to SWIMA (or adopt something esoteric enough that I might as well be doing so).

---

Thanks again for the clarifications. I hope that the new draft (-04) better addresses your concerns.

Thanks,
Charles




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