Subject: [sacm] Draft-ietf-sacm-ecp

From: Chris Inacio <[email-masked]>
Date: Thu, 22 Mar 2018 01:12:46 +0000

So there are obviously follow-on documents to this document and work that is intended to be brought to the IETF.  Is that correct?

1: "Standadrid collection improves network security by confirming that endpoints are known and

   authrosized, and are compliant with network policy.”  Fix spelling:  Standard and authorized.

1: "Administrators will query the repository to determine the posture status of an endpoint.”  Maybe administrators can - otherwise we could just say administrators will secure their networks and ensure they have no vulnerable apps installed and be done, right?  :)

1.1: “The value of continuous endpoint posture assessment is well

   established.” Can we cite this statement?

1.1: "respectively, of the CIS "20 Critical” please expand Center for Internet Security (CIS) on its first use.

1.1: "By sharing posture informatino with sensors on the network, ECP aids in the

   detection of attacks on endpoints and drives follow-up actions.”  Spelling for information and I find this statement p

1.3: "Posture information must be sent over mature, standardized protocols

   to ensure the confidentiality and authenticity of this data while in
   transit.”  An implication of this sentence is that TLS 1.3 is not / will not be secure.  Are we really wanting to say that?

1.3: "The IETF NEA WG has designed an architecture to support endpoint

   posture assessment.  Figure 1 illustrates the architectural
   components used in the Endpoint Compliance Profile:”

I can’t find mention of a repository in RFC6876 or RFC5209; I can’t find the diagram either, but I’m mostly okay with not finding the diagram.

1.3: Can we please use the same terminology from NEA “Posture Transport Client” instead of remaining things, e.g. “Comms Client”.

3.1: "The Endpoint Compliance Profile 1.0 describes how IETF and TNC data

   modles and protocols make”. Models maybe?

3.2: "Uses of this data are innumerable--

   vulnerability management, asset management, software asset
   management, and configuration management solutions, analytics tools,…” remove the errant “and” in the middle of the sentence.

3.2: I feel like there is some real meat missing here.  Is there more to come?

4.1: "endpoint posture information s and to make it available to other

   authorized parties.” - random “s”.

4.2.1: "A network-connected endpoint sends posture information using standard

   schemas an protocols.” “an" should be “and”.

4.2.1: "4.  The SWID Posture Collector on the endpoint collects from the SWID

       tag directory on the endpoint.  This data is sent via the NEAC
       and PTC to the server.”   - this assumes a fat client, right.  “Sent via the NEAC and PTC”, would rewording that to “sent via the NEAC over PTC” maybe?

4.2.1: "5.  Once the posture information is received by the PTS, it is

       forwarded to the SWID Posture Validator via the NEAS.  The SWID
       Posture Validator also forwards the posture information to the
       repository.  The posture information is stored along with past
       posture information collected about the endpoint.”   - This is really confusing, not the least of which because none of the names match the names in the diagram.

4.2.2: "Because the endpoint posture information was sent in a standards-

   based schema (ISO/IEC 19770-2:2009) over secure, standardized
   protocols, and the SWID tags are stored in a centralized repository
   linked to unique endpoint identifiers, authorized parties are able to
   access the posture information.” - this just seems like a complete non-sequitur.

4.2.2: "It should be noted that the neither the Endpoint Compliance Profile

   nor the protocols, interfaces, and data models that it references
   provide solutions to the server capabilities listed above.  However,
   these capabilities are useful and solutions for them should be
   pursued in the future.” - doesn’t this make section 3.3 a lot easier to write?

4.2.2.1: These seem out of scope for the document.  It seems like these are either UI requirements; otherwise not sure how this fits.

4.2.3: Why “Non-Supported” instead of “Unsupported”?

4.2.3: Pub/Sub: Can this be reworded to read more easily?

4.2.4: “Easy to use:”  - I don’t think the IETF wants to get into the user interface standards / recommendations business.  Also, I think this might be a great place where the market can reward a good UI vs. a bad UI especially with consideration of functionality vs. ease of use.

4.2.5: “Certificate provisioning” - this seems to say, enterprises will use certificates to secure an endpoint identity and communications, unless they don’t.  ????

<stopped reading at section 8>