[sacm] review of draft-ietf-sacm-ecp

[Kathleen Moriarty <[e-mail]>]

Hello!

I reviewed
https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/?include_text=1 and
have a few comments and questions below.  Thanks for your work on this
draft!  In addition to my review comments, I am curious on adoption as I'd
like to see if this has gained traction and if not, help figure out how we
(the working group participants) can help with that.

Abstract:
After reading the full document, the following does not seem to be the case
in terms of how we use the word "extension" in the IETF.
"This document is an extension of the Trusted Computing

   Group's Endpoint Compliance Profile Version 1.0 specification [ECP].

This document uses other IETF protocols and formats, referencing them
appropriately and doesn't extend those either.

I think the best approach may be to drop that sentence as the context is
covered prior to it.

Introduction:

Was this text meant for the WG development process or for -bis updates?
The described additions could be done with new RFCs that update or extend
this without doing a -bis as well.  Just mentioning so authors are aware of
all options:

Future revisions of this
   document may include support for the collection of posture
   information from other endpoint types as well as a standardized
   interface for storing and querying data in repositories among other
   capabilities.


Section 4.1
If certificates are the only method of authentication, per the first
sentence in this section, why is certificate authentication a SHOULD?  I
would expect a MUST for authentication and a RECOMMENDED for the preferred
method or a MUST for the only method.

The target endpoint SHOULD authenticate to the posture manager using
   a machine certificate during the establishment of the outer tunnel
   achieved with the posture transport protocol defined in [RFC6876].

In the same section, do you mean authenticator or identity?

  In the future, the identity could be a hardware certificate compliant
   with [IEEE-802-1ar]; ideally, this identifier SHOULD be associated
   with the identity of a hardware cryptographic module, in accordance
   with [IEEE-802-1ar], if present on the endpoint.

Ah, the last sentence says a password is possible, so other methods can be
supported.  Cleaning up the text a bit would be helpful.

Section 4.5 heading, did SWIMA get autocorrected to SWAM?  Or did I miss a
few reviews (which is possible)?

Section 5:

Is NETCONF/RESTCONF the only supported protocol interfaces?  This section
reads as if that is the case.  Would DMTF's CIM be supported with the
appropriate interface (SNIA, Windows, etc.) or other implemented
configuration assessment combination? Or has YANG development gone far
enough that this is not necessary?

Thanks again for your work on this document!  It looks very good and will
be helpful.  I think it can also serve as a nice example of how to detail
endpoint security requirements in protocol documents (see
SAAG/SecDispatch/SMART discussion on threat models and a possible RFC3552
revision).



-- 

Best regards,
Kathleen