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

Thank you for the review, Roman.

SACM,
Roman's comments are. . . extensive. And they reflect an issue that this
draft has had for a long time now-- no one seems to know what the EPCP is.
And, if our AD, who has been involved in this draft for years now, has
conflicting ideas about what the draft is, I have real doubt about getting
it through IETF review.

We submitted EPCP four years ago. The reason we submitted it was to begin a
conversation we needed to have in order to support NIST's transition to
SCAP version 2. The SCAP v2 work groups are pursuing a similar, but not
identical, path towards standardizing endpoint data collection. What was
relevant four years ago isn't relevant today.

I humbly suggest that we stop work on this document. I would love to hear
comments from the group on that course of action.

Thanks,
Jess

On Fri, Sep 4, 2020 at 11:28 AM Roman Danyliw <rdd@cert.org> wrote:

> 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
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>