Subject: Re: [sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-02: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Mar 2018 21:19:17 -0600

> On Feb 24, 2018, at 1:01 AM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Hello,
> 
> Thanks a bunch for your feedback. In general I agree with your comments and made changes to address them. Some quick clarifications:
> 
>> §2.4: This seems to assume there is never a need to hide information from
>> intermediaries. Is that the intent? (Or maybe there aren't any
>> intermediaries?)
> 
> This is not the intent. NEA has multiple parts and the intent is to clarify that the SWIMA part isn't the part dealing with data confidentiality. The portion that handles confidentiality is the PT layer of the NEA architecture. (PT-TLS and PT-EAP) All I'm trying to do is emphasize that, if confidentiality is an issue, make sure your NEA architecture is set up to support that.

I think what is confusing me is the “title” of the non-requirement is “End to End confidentiality”. I admit to not knowing the sacm work well enought to know what the “ends” are, but am I correct to assume that PT-TLS, like most uses of TLS, is hop-by-hop? Does the data every cross more than one hop? Is the answer the dame for PT-EAP?

> 
>> §3.4.3,
>> -- first paragraph: What is the expected scope of uniqueness for record
>> identifiers? -- In the sentence "The Record Identifier SHOULD remain
>> unchanged
>> if that record is modified.", why is the SHOULD not a MUST? What would
>> happen
>> if the identifier did change?
> 
> It is SHOULD rather than MUST because, under some tracking conditions it might not be possible to distinguish between a record being modified and a record being deleted and a new record being created. Will add clarifying text to this effect. If the system thinks that a modification is actually a delete/create action, it would be treated as such with a new record identifier being assigned to the "created" record.
> 

Okay; I think the mentioned clarifying text would help.

>> §7.1: " Some tools might not be designed to update records in the Software
>> Inventory Evidence Collection in real time,..." Wasn't there a normative
>> requirement that they be capable of this?
> 
> A subtle difference: The SWIMA-PC MUST detect changes to the Software Inventory Evidence Collection in near real time, but the data sources might not update the Software Inventory Evidence Collection in real time. I reworded to clarify the difference between the SWIMA-PC reading the Evidence Collection and the tool updating the Evidence Collection.

Okay.

> 
>> §9: Nit: is there are reasons to violate the convention that IANA, security,
>> and privacy considerations are the last substantive sections in in the body of
>> an RFC?
> 
> I'm happy to reorder these - a quick random sample of RFCs seems to provide a number of different orderings. I just followed the PA-TNC spec, since I had that open most. Just let me know what the expected order is.

Typically they are the last three “substantive” sections in the main body of an RFC, not counting any appendices or “acknowledgements” type sections. I don’t think we are consistent in the order among those three.

Thanks!

Ben.

> 
> Thanks a bunch,
> Charles
> 
>> -----Original Message-----
>> From: Ben Campbell [mailto:[email-masked]]
>> Sent: Wednesday, February 21, 2018 9:10 PM
>> To: The IESG <[email-masked]>
>> Cc: [email-masked]; [email-masked]; Karen
>> O'Donoghue <[email-masked]>; [email-masked];
>> [email-masked]; [email-masked]
>> Subject: Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-02:
>> (with DISCUSS and COMMENT)
>> 
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-sacm-nea-swima-patnc-02: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> (This is related to one of Ekr's comments, but I don't think it's quite the
>> same.)
>> 
>> In the first paragraph of §7.2, the conclusions seem to be based on the
>> following sentence:
>> 
>> "This is generally not considered to be problematic, as
>>   those with access to the endpoint can usually learn of everything
>>   disclosed by that endpoint’s records simply by inspecting other parts
>>   of the endpoint."
>> 
>> This doesn’t seem like a reasonable assumption. Multiuser endpoints may
>> well
>> have access controls that prevent a given user from seeing all software
>> packages installed on the system. This leads to the conclusion that the
>> records
>> on the endpoint are not sensitive. I do not think this document should draw
>> that conclusion. Even if this were provably true for all existing systems, such
>> an assumption could be problematic for future systems.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Substantive Comments:
>> 
>> §2.4: This seems to assume there is never a need to hide information from
>> intermediaries. Is that the intent? (Or maybe there aren't any
>> intermediaries?)
>> 
>> §3.4.3,
>> -- first paragraph: What is the expected scope of uniqueness for record
>> identifiers? -- In the sentence "The Record Identifier SHOULD remain
>> unchanged
>> if that record is modified.", why is the SHOULD not a MUST? What would
>> happen
>> if the identifier did change?
>> 
>> §3.4.4:
>> 
>> -- "However, if that directory is shared by other software products, the
>> "location" SHOULD be the location of the primary executable
>>   associated with the software product."
>> I'm confused by the the condition, since sharing a directory with other
>> products doesn't seem to introduce the ambiguity that the rest of the
>> sentence
>> assumes. Perhaps this was meant to be about situations where a software
>> package
>> is installed across multiple directories?
>> 
>> -- "Even a probable location for a software product is preferable to using a
>> zero-length locator." This could use elaboration; do you expect the collector
>> to guess?
>> 
>> §7.1: " Some tools might not be designed to update records in the Software
>> Inventory Evidence Collection in real time,..." Wasn't there a normative
>> requirement that they be capable of this?
>> 
>> §8,
>> -- 2nd paragraph: It’s worth mentioning that in some contexts this sort of
>> information could expose the user to severe personal risk, including the risk
>> of death. -- Last paragraph: "For this reason, privacy safeguards might be
>> necessary for collected inventory information." Can this be stated more
>> strongly than "might be necessary"?
>> 
>> Editorial Comments and Nits:
>> 
>> §3.8.5, first paragraph: "As noted in Section 3.6 SWIMA-PCs MUST ..."
>> Please reserve 2119 keywords for the authoritative statement of a
>> requirement;
>> that is, please do not use them to refer to requirements defined elsewhere.
>> (Note that this pattern occurs multiple times in the draft.)
>> 
>> §9: Nit: is there are reasons to violate the convention that IANA, security,
>> and privacy considerations are the last substantive sections in in the body of
>> an RFC?
>> 
>> 
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 6 Mar 2018 01:11:59 +0000

Hi Ben,

Thank you for the follow-up. I made some additional modifications (-04 draft) that I hope address your remaining comments.

Regarding your nit, I moved the Relationship to Other Specifications before the Security Considerations. The last sections are now the three you note.

Regarding your comment on 2.4:

> > This is not the intent. NEA has multiple parts and the intent is to clarify that
> the SWIMA part isn't the part dealing with data confidentiality. The portion
> that handles confidentiality is the PT layer of the NEA architecture. (PT-TLS
> and PT-EAP) All I'm trying to do is emphasize that, if confidentiality is an issue,
> make sure your NEA architecture is set up to support that.
> 
> I think what is confusing me is the “title” of the non-requirement is “End to
> End confidentiality”. I admit to not knowing the sacm work well enought to
> know what the “ends” are, but am I correct to assume that PT-TLS, like most
> uses of TLS, is hop-by-hop? Does the data every cross more than one hop? Is
> the answer the dame for PT-EAP?

Re-reading this section, I agree that the section was confusing. I renamed the section to "Non-SWIMA Requirements" (and renamed the preceding section to "SWIMA Requirements"). Hopefully this clarifies that the specification is not talking about what is and is not required, but simply which requirements need to be addressed by SWIMA and which requirements need to be addressed by other standards.

I also changed the text as follows:

   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.

Hopefully that makes things clearer. To more directly answer your question, PT-TLS is just TLS with some minor added constraints to fit with the NEA architecture. Likewise, PT-EAP is basically just EAP. SWIMA should be agnostic as to whether or not there are hops in the transmission and delegate all responsibility for maintaining confidentiality across any hops to the PT protocol in question. Does this help?

Thanks again for the clarifications. Hopefully the new draft (-04) will address those remaining concerns.

Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Thursday, March 01, 2018 9:19 PM
> To: Schmidt, Charles M. <[email-masked]>
> Cc: [email-masked]; Karen O'Donoghue <[email-masked]>; The
> IESG <[email-masked]>; [email-masked]; draft-ietf-sacm-nea-swima-
> [email-masked]
> Subject: Re: [sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-
> patnc-02: (with DISCUSS and COMMENT)
> 
> 
> 
> > Thanks a bunch for your feedback. In general I agree with your comments
> and made changes to address them. Some quick clarifications:
> >
> > This is not the intent. NEA has multiple parts and the intent is to clarify that
> the SWIMA part isn't the part dealing with data confidentiality. The portion
> that handles confidentiality is the PT layer of the NEA architecture. (PT-TLS
> and PT-EAP) All I'm trying to do is emphasize that, if confidentiality is an issue,
> make sure your NEA architecture is set up to support that.
> 
> I think what is confusing me is the “title” of the non-requirement is “End to
> End confidentiality”. I admit to not knowing the sacm work well enought to
> know what the “ends” are, but am I correct to assume that PT-TLS, like most
> uses of TLS, is hop-by-hop? Does the data every cross more than one hop? Is
> the answer the dame for PT-EAP?
> 
> 
> 
> >
> >> §3.4.3,
> > It is SHOULD rather than MUST because, under some tracking conditions it
> might not be possible to distinguish between a record being modified and a
> record being deleted and a new record being created. Will add clarifying text
> to this effect. If the system thinks that a modification is actually a
> delete/create action, it would be treated as such with a new record identifier
> being assigned to the "created" record.
> >
> 
> > A subtle difference: The SWIMA-PC MUST detect changes to the Software
> Inventory Evidence Collection in near real time, but the data sources might
> not update the Software Inventory Evidence Collection in real time. I
> reworded to clarify the difference between the SWIMA-PC reading the
> Evidence Collection and the tool updating the Evidence Collection.
> 
> Okay.
> 
> >
> > I'm happy to reorder these - a quick random sample of RFCs seems to
> provide a number of different orderings. I just followed the PA-TNC spec,
> since I had that open most. Just let me know what the expected order is.
> 
> Typically they are the last three “substantive” sections in the main body of an
> RFC, not counting any appendices or “acknowledgements” type sections. I
> don’t think we are consistent in the order among those three.
> 
> Thanks!
> 
> Ben.
> 
> >
> > Thanks a bunch,
> > Charles
> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Mar 2018 15:50:16 -0500

Hi Charles,

Thanks for this update.  I believe Ben's last comment is addressed
with your text and it reads well to me.  Ben - are you good with this
text? I will assume so if I don't hear back soon.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Fri, 9 Mar 2018 16:21:43 -0600

Thanks for the response. I still have a point of confusion, inline. Also, keep in mind that I have cleared my DISCUSS; this is a non-blocking comment and you are welcome to handle it however you please.

Ben.

> On Mar 5, 2018, at 7:11 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Hi Ben,
> 

I’m still a bit confused; let me try to come at it from another angle:

The paragraph is labeled “End-to-End Confidentiality”.  The text delegates this to transport protocol, and gives PT-TLS and PT-EAP as examples. In the specific case of TLS: TLS does not normally offer “end-to-end” confidentiality, rather it’s hop-by-hop. If there are intermediaries, TLS does not prevent them from seeing the data.  Now, there are exceptions (e.g. HTTPS proxies). And of course, if there are no intermediaries, then hop-by-hop becomes a trivial case of end-to-end.

So I guess what I am asking is why TLS is listed as an example transport in a paragraph about end-to-end confidentiality? Perhaps the paragraph is just about confidentiality in general? Or there are other aspects of the architecture that make TLS effectively end-to-end?

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Sun, 11 Mar 2018 04:27:25 +0000

Hi Ben,

Thank you for the clarification. I'm following you now.

I agree that I misused "end-to-end" in the description of this requirement. "Confidentiality" would be a better section name. I'm sure the RFC editor will have some additional fixes for me to do, and I'll make the switch in the next draft.

Thanks,
Charles

> Sent: Friday, March 09, 2018 4:22 PM
> Cc: [email-masked]; [email-masked]; The
> IESG <[email-masked]>; Karen O'Donoghue <[email-masked]>;
> [email-masked]
> Thanks for the response. I still have a point of confusion, inline. Also, keep in
> mind that I have cleared my DISCUSS; this is a non-blocking comment and
> you are welcome to handle it however you please.
> 
> Ben.
> 
> > Thank you for the follow-up. I made some additional modifications (-04
> draft) that I hope address your remaining comments.
> >
> > Regarding your nit, I moved the Relationship to Other Specifications before
> the Security Considerations. The last sections are now the three you note.
> >
> > Re-reading this section, I agree that the section was confusing. I renamed
> the section to "Non-SWIMA Requirements" (and renamed the preceding
> section to "SWIMA Requirements"). Hopefully this clarifies that the
> specification is not talking about what is and is not required, but simply
> which requirements need to be addressed by SWIMA and which
> requirements need to be addressed by other standards.
> >
> > Hopefully that makes things clearer. To more directly answer your
> question, PT-TLS is just TLS with some minor added constraints to fit with the
> NEA architecture. Likewise, PT-EAP is basically just EAP. SWIMA should be
> agnostic as to whether or not there are hops in the transmission and
> delegate all responsibility for maintaining confidentiality across any hops to
> the PT protocol in question. Does this help?
> 
> The paragraph is labeled “End-to-End Confidentiality”.  The text delegates
> this to transport protocol, and gives PT-TLS and PT-EAP as examples. In the
> specific case of TLS: TLS does not normally offer “end-to-end” confidentiality,
> rather it’s hop-by-hop. If there are intermediaries, TLS does not prevent
> them from seeing the data.  Now, there are exceptions (e.g. HTTPS proxies).
> And of course, if there are no intermediaries, then hop-by-hop becomes a
> trivial case of end-to-end.
> 
> So I guess what I am asking is why TLS is listed as an example transport in a
> paragraph about end-to-end confidentiality? Perhaps the paragraph is just
> about confidentiality in general? Or there are other aspects of the
> architecture that make TLS effectively end-to-end?
> 
> 
> 
> >
> >>> On Feb 24, 2018, at 1:01 AM, Schmidt, Charles M.
> <[email-masked]>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>>> and privacy considerations are the last substantive sections in in the
> body
> >> of
> >>>> an RFC?
> >>>
> >>>> and privacy considerations are the last substantive sections in in the
> body
> >> of
> >>>> an RFC?
> >>>>
> >>>>
> >>>
> >

---

From: Ben Campbell <[email-masked]>
Date: Sat, 10 Mar 2018 23:49:57 -0600

Hi Charles,

That sounds like a perfectly good plan.

Thanks!

Ben.

> On Mar 10, 2018, at 10:27 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Hi Ben,
>