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

Thanks for the review, Kathleen.

Response in line denoted by [jmf].

On Thu, Jul 18, 2019 at 10:14 AM Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

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

[jmf] okay, we will drop the sentence.

>
> 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.
>
>
> [jmf] This text refers to future work group revisions of this document.
Therefore, I will leave this text as is.

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].
>
> [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,

> 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.
>
> [jmf] I think I mean authenticator. I will make that change.

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

[jmf] will do.

>
> Section 4.5 heading, did SWIMA get autocorrected to SWAM?  Or did I miss a
> 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.

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

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

>
> 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).
>
> [jmf] Thank you!

Jess

>
>
> --
>
> Best regards,
> Kathleen
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>