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

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Jul 2019 10:14:00 -0400

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

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 25 Jul 2019 10:57:47 -0400

Thanks for the review, Kathleen.

Response in line denoted by [jmf].

On Thu, Jul 18, 2019 at 10:14 AM Kathleen Moriarty <
[email-masked]> wrote:

> 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.

[jmf] okay, we will drop the sentence.

> [jmf] This text refers to future work group revisions of this document.
Therefore, I will leave this text as is.

Section 4.1
> [jmf] I think the confusion here is actually in the first sentence of
section 4.1. It currently reads

An endpoint is provisioned with a machine certificate that will serve
   as its unique identifier on the network as well as the components

   necessary to interact with the posture manager.

But, of course, that is not always true. An endpoint SHOULD be provisioned
with a certification, which then SHOULD be used to authenticate to the
posture manager. I will change the text in the first section of 4.1, and
leave the rest of the text as is,

> [jmf] I think I mean authenticator. I will make that change.

> supported.  Cleaning up the text a bit would be helpful.

[jmf] will do.

> few reviews (which is possible)?

[jmf] No, we mean Software Asset Management [SWAM]. SWIMA is used to
implement the SWAM use case. I will expand the SWAM acronym and clarify the
text here.

> enough that this is not necessary?

[jmf] Other interfaces could be supported, but are not described here. I
will clarify the text to say so.

> [jmf] Thank you!

Jess

>
>
> --
>
> Best regards,
> Kathleen
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>