Subject: [sacm] AD review of draft-ietf-sacm-epcp-01

From: Roman Danyliw <[email-masked]>
Date: Fri, 4 Sep 2020 15:28:26 +0000

Hi!

I conducted my AD review of draft-ietf-sacm-epcp-01.

My most significant concerns are:

** I made a mistake.  After this more detailed review, I have to change my earlier guidance and recommend that this document should be published as informational.  My apologizes for not reading it carefully enough when we chatted about this topic several (?) months ago.  As specified here, this text is not able to be implemented interoperably and appears to be more at the abstract level.

** I read Section 2's scoping statement: 

The EPCP describes how IETF, TCG, and ISO/IEC data models, protocols,
   and interfaces can be used to support the posture assessment of
   endpoints on a network.  This profile does not generate new data
   models, protocols, or interfaces; rather, it offers requirements for
   a full end-to-end solution for posture assessment

However, I'm a little confused on what the EPCP really is.  The document appears to define a reference architecture whose components are described in varying levels of details; and then two sections which describe loose requirements for NEA/TCG and NETCONF technologies relative to this reference architecture.  Is that right?

-- where does the architecture come from -- is it a novel contribution of this document?  Is this the "SACM architecture"?

-- With regards to NEA/TCG/NETCONF, what is the novel content being described here?  Figure 1 of RFC5209 also defines a reference architecture for doing posture assessment using different words which seems to identically overlap with the exact scope of the box labeled being the EPCP in Figure 1.  NEA was explicitly designed to do posture assessment.  Is the novelty combining NEA + the TCG interfaces + SWID as a payload?  Per the NETCONF language, what's described is the generic NETCONF architecture and one required YANG module (and all others in YANG or XML also supported).  Is the novelty the assignment of posture assessment roles to NETCONF architecture?

-- I'm confused on what is the actual "profile".  For me, a profile describes a subset/configuration/extensions of how a given technology should be used.  I'd like to confirm that that we are using the word the same -- is the reference architecture described in Section 2 a profile? I read the document as describing a NEA/TNC profile and NETCONF profile for the architecture depicted in Figure 1, but I'm not sure if that's correct.

-- I'm also a little confused by the mixing of specific normative language relative concrete protocols/specs (e.g., Section 3.3.1) and what appear to be loose system properties (e.g., Section 3.5.4) that exceed the scope of the named technologies being profiled.  My concern is that if normative language is used, sufficient detail needs to be provided to the implementers to understand it.

-- If there are components of this architecture not specified in the document, are there more profiles coming?

** Noted in detail below, I had trouble following what was in-and-out of scope for EPCP.

My detailed feedback is as follows:

** Idnits produced the following output that requires action/discussion:

   Miscellaneous warnings:
----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).

[snip]

  Checking references for intended status: Proposed Standard
  --------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: draft-he-mile-xmpp-grid has been published as RFC
     8600

  == Outdated reference: draft-ietf-netconf-restconf-notif has been published
     as RFC 8650

  == Outdated reference: A later version (-15) exists of
     draft-ietf-sacm-coswid-12

  == Outdated reference: A later version (-16) exists of
     draft-ietf-sacm-terminology-05

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-sacm-terminology (ref. 'I-D.ietf-sacm-terminology')

** Section 1.  Per "Thus, eliminating the need for multiple collection tools on an endpoint collecting the same data for difference purpose", I didn't follow how this goal was being realized.  Is it that the information is centralized whereby allowing different components to query the single centralized server instead of each getting it themselves from the end points?

** Section 1.  I think this section might benefit from an up-front applicability statement - what kind of end points? Is this scoped to use cases where the collector + endpoints are in the same policy domain as would be found in an enterprise network (e.g., per Section 3.2 of RFC5209)?

** Section 1.  Per "Future revisions of this document may include support for the collection of posture information from other endpoint types ...", no issues about talking about the future.  However, it isn't clear in the text what endpoints are in and out of scope.

** Section 1 and Section 5.  Per "Additional information about this future work ...", I'm not sure what the next steps would be for this.  It seems improbable that SACM would pursue this.

** Section 1.2.  Relying on draft-ietf-sacm-terminology as a normative reference is a little problematic - it is informational (making it a downref), has expired and appears unlikely to be published.  Do you really need to use it?

** Section 2.  Per "... as well as a fresh perspective on how existing standards can be leveraged against vulnerabilities.", this puzzled me a bit because NEA was already being used to scan for vulnerabilities.  What's the new perspective?

** Section 2.  What is the difference between the numbered list here and the bulleted list in Section 1?

** Section 2.  Per "Furthermore, the EPCP aims to support data storage and data sharing capabilities ...", these capabilities are explicitly noted as being out of scope of the EPCP in Figure 1.

** Section 2.1.1.  Per "An endpoint is defined in [RFC6876].", I could not find a definition.  What section is that in?

** Section 2.1.1.1.  Please use a difference expression than "... can be sanity checked ..."

** Section 2.1.2.  Why is there a distinction between a "Posture Manager" and "Posture Collection Manager", but not a "Posture Validator" (present in the NEA architecture)?  

** Section 2.1.5.  Per "The orchestrator provides a publish/subscribe interface for the repository so that infrastructure endpoints ...", this description confuses me since per Figure 1, the orchestrator has no connection to the data store.

** Section 2.1.6.  What is this API practically?  The rest of the document makes no detailed reference to it.  Since the Posture Manager, in scope for the EPCP, needs to respond (host a server component?) to these requests, how does one do that with NEA? NETCONF?

** Sections 2.1.4 and 2.1.5.  Per Figure 1, the Orchestrator and Evaluation seem to have a publish/subscribe or query/response channel to the Posture Manager.  How does one do that with NEA?  NETCONF?

** Section 2.1.5 and 2.1.6.  Both of these sections mention "infrastructure endpoint".  What are these?  How do they differ from "target endpoints"?  Is there role swapping?

** Section 2.1.6.  If the API is intended to query the repository and manage the endpoints, then why do the orchestrator and evaluator have their own APIs labeled "query/response" and "publish/subscribe" in Figure 1?  Why can't they just use this API?

** Section 2.2.  Per "The following sections describe the transactions associated with the EPCP components and may be provided by an implementation", is there a minimum subset which MUST be implemented to conform to this profile?  It isn't clear to me what the "requirements" are here.

** Section 2.2.5.  Per "The repository could be co-located with the posture- manager ...", what does this possibility mean for the scope of the EPCP reference architecture.  My read of Figure 1 and the Section 2.1.  has the repository as being out of scope.

** Section 2.2.6.  Is it accurate that standards-based data model are used in both profiles?  The NEA profile points to SWID, but in the NETCONF only says "YANG"

** Section 3.  Section 4 (NETCONF) seems to scope the profile to "network device endpoints".  Is this profile scoped to endpoints capable of support SWID (or something else)?  Would it be expected to run the Section 3 and 4 profiles in parallel?

** Section 3.  Is the behavior described in the first paragraph if this section specific to EPCP, or generic to NEA/TCG?  I ask because it read like a simplified version of Section 5.1 of RFC5209.  What is unique to EPCP here rather than being the generic NEA behavior?

** Section 3.  Section 3.  Editorially, please use the same words in the text as in the diagram so it's easier to follow:
s/posture broker client/posture broker client (PB client)/
s/posture transport client/posture transfer client (PT client)/
s/posture transport server/posture transfer server (PT server)/
s/posture manager/posture collection manager/
Consider also adding arrows to indicate the flow described in this text to Figure 2.
IF-IMC, IF-IMV, PT-TLS, PA-TNC, PB-TNC were depicted in Figure 2, but not explained in this text.

** Section 3.1.  As the name "PT-TLS" is used in subsequent text, for clarify, please s/posture transport protocol defined in [RFC6876]/posture transport protocol defined in PT-TLS [RFC6876]/.  Also as a style nit, this section refers to [RFC6876] (i.e., reference by the RFC number), but Section 3.2 refers to "PT-TLS" (i.e., reference by the protocol acronym).  For easier reading, I'd recommend consistency.

** Section 3.1, 3.2.3. and 3.3.3.  Per the TLS guidance in RFC6876, is there new guidance to provide relative TLS 1.3 and not using TLS 1.0 and 1.1?

** Section 3.1. Per "[IF-IMV] specifies how to pull an endpoint identifier out of a machine certificate", what is that identifier used for?

** Section 3.1.  Per "... using a combination of the machine account and password ... not recommended", why not the normative NOT RECOMMENDED?

** Section 3.1.  Per "The enterprise SHOULD establish a certificate root authority; install its root certificate ...", do you literally mean a PKI of depth 1 (CA-to-end certificate) vs. CA-to-intermediary-to-end-certificate?  I thought it was more common practice to hold the root in reserve and issue from intermediaries.

** Section 3.2.  If possible, can the relevant section from RFC5793 be cited.

** Section 3.2.  Missing word.  "1.  ... with the posture manager if the posture <here> makes a request ..."

** Section 3.2.  These requirements are being framed in a way I don't follow:
"An endpoint ... will be able to ... 2. Notify the posture collector if no PT-TLS session with the posture manager can be created".  Section 2.1.1.1 said that the posture collection engine is responsible for the "client portion of the encryption handshake", so why does it tell the endpoint anything?  Likewise, it's part of the endpoint.  

** Section 3.2.  Per "   4.  receive information from the posture collectors, forward this information to the posture manager via the posture collection engine.", I don't follow.  How is the end point supposed to received information from the posture collector?  The posture collector is ON the endpoint?

** Sections 3.2.3 and 3.3.3.  Can the relevant sections of [RFC6876] and [Server-Discovery] please be cited.

** Sections 3.4 and 4.5.  What does it mean for the "EPCP requires a simple interface for the repository"?  

** Section 3.4.  This section seems to discuss that requirements for PA-TNC and its link to the repository isn't clear.

** Section 3.5.*.  Is the SWIMA extension (Section 3.5.*) a mandatory addition to the 3.1 - 3.4 part of the profile?

** Section 3.5.1.  Per "The following requirements assume that the platform ... supports the use of [SWID]", what exactly are those platform requirements?  Is there a pointer into the SWID or COSWID references that describe that?

** Section 3.5.2.  Is there a normative requirement to support both SWID or CoSWID?

** Section 3.5.2.  Per "The tags SHOULD be provided by the software vendor; they MAY also be generated ..."
-- if not all of these options, how would one get  SWID?  I ask because the combination of this SHOULD + MAY still leaves the possibility for other options
-- Does the SWID spec providing any guidance on the origin of the tags?  That is, is this guidance in addition to or more narrow than SWID in anyway?

** Sections 3.5.3.* These section are named "SWID *" per the components in Figure 2.  Are these the same as those mentioned in Section 3.*

** Section 3.5.4.  This section seems to place normative requirements on the Repository which I thought was outside of the EPCP scope boundary.  Additionally, these requirements seem quite similar to the role of the API (described in Section 2.1.6)?  Furthermore, is this query response mechanism different than the "query/response" between the "repository and evaluator" in Figure 2?

** Section 3.5.4.  Nit on section naming.  All of the other 3.5.* items are "SWID *".

** Section 4.  I don't understand what unique contribution this section is making - that is, what is actually being profiled.  Beyond requiring support for the RFC7317 YANG module, the described behavior appears to be standard NETCONF with the overlay of the "posture *" labels onto the NETCONF client and server

** Section 4.5.  It seems odd to me to discuss the repository here since it was declared outside of the EPCP in Figure 1.

** Section 5.  Given the state of the WG, I'm not sure I see value in this enumeration in an archival series.

** Section 8.1.1.  Is the "Putting bad information in SWID directory" only limited to NEA systems (i.e., Section 3 in the profile vs. Section 4, since Section 4 doesn't use SWID)?

** Section 8.1.1.  Per "Putting bad information the SWID directory", recommend not ascribing motives to the endpoint users.  It would be cleaner simply to acknowledge that they may tamper with the information.

** Section 8.1.1.  Per "identity spoofing", why allow MAC addresses to identify endpoints?  Section 3.1. identifies a wealth of options (machines certs, username-password, hardware certificates).  Section 4 uses standard NETCONF approaches.  Why not be more strict given that this a green field architecture (i.e., there are no deployments of this profile?)

** Section 8.1.3.  Additional text describing what makes a posture manager trust vs. untrusted would be helpful.

** Section 8.1.4.  The profile appeared to place no security requirements on the repository or the communication between the repo and the posture manager.  I don't disagree with the materials, but it seems this creates a confusing scope.

** Section 8.1.4.  Per the "Putting bad information into the trusted repository" and the text, "An authorized repository client such as a server", what server is that per the reference architecture in Figure 1?  It isn't clear from the architecture which components have write access.

** Section 8.1.4.  Per "Misconfiguration of a trusted repository", wouldn't unintentional exposure of the data in the repo also help an attacker with targeting?

** Section 8.1.4.  As with untrusted posture manager, the mechanism for clients knowing how to refuse to connect is not clear.

** Section 8.2.1.  Could a precise pointer be made for the "current NEA specification"

** Section 8.2.1.  Per "Future versions of the EPCP may want to discuss in greater detail ...", the long term value of this material in an archival document isn't clear

** Section 8.2.2.  Can you clarify in the case of traffic analysis and DoS who the attacker is and where this endpoint is located in the network.

** Section 8.2.3.  Is a target of a "permanent read-only audit log" realistic?

** Section 8.2.4.  Per "The firewall on the repository should only allow access to the posture manager and to any endpoint authorized for administration", this guidance doesn't seem consistent with Figure 2 which appears to provide access to the Evaluator through a "request/response" API.

** References.  Per [Server-Discovery], I quick searching didn't find any reference to this "DRAFT" document.  Is it the same as https://trustedcomputinggroup.org/wp-content/uploads/TCG-Trusted-Network-Communications-Server-Discovery-and-Validation-Version-1.0-Revision-25-1.pdf from 2017?

** Section A1.  Per "run on all types of endpoints ...", to be clear neither does EPCP.

** Section A.1.  Per "require vetted ... protocols ... [with] cryptographic soundness", I am surprised to hear that commercial offerings are not using standardized transport security.  Or, is this not what this bullet is intended to call out.

** Section A.4.  It isn't clear from the EPCP which standardized data models are used.

** Section A.6.  It isn't clear how the EPCP is exposing information with a standardized API.

** Section B.1.1.  Per "What SWID tags were reporting", seems only to apply to the NEA solution, not NETCONF.

** Section B.1.2.  Where is this API specified?

** Section B1.2.3.  I'm not sure if I caught that unique ID are assigned to each endpoint anywhere in the profile.  Where is that said?  Per the NEA/TCG, is it "An endpoint identifier SHOULD be created in conformance with [IF-IMV] from a machine certificate sent via [RFC6876].", but this is not a MUST.  There is not such guidance in the NETCONF text.

** Section B.1.3.  What is "rich application data"?  This is the first characterization of the data as such?

** Section B.1.4.  The reference architecture in Figure 2 and both the NEA and NETCONF profile make no mention of a "repository API".

** Section B.2.  The statement "gather non-standardized types of posture information" seems inconsistent with "Datastores MAY support other models standardized or proprietary as deemed appropriate by the endpoint vendor" in Section 4.3.1.

Regards,
Roman