Re: [Rats] Last Call: <draft-ietf-rats-yang-tpm-charra-12.txt> (A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs) to Proposed Standard

[tom petch <[e-mail]>]

On 11/02/2022 11:51, tom petch wrote:
> On 11/02/2022 10:37, tom petch wrote:
>
> Eric

Eric

Me again.

Looking at -18:
- the changes from my comment about YANG import needing a Normative 
Reference hasn't quite had the effect I intended.  Yes, as per RFC8407, 
the Normative Reference is there but the YANG 'reference 'statement is not
e.g. from tcpm-yang-tcp
      import ietf-inet-types {
        prefix "inet";
        reference
          "RFC 6991: Common YANG Data Types.";
      }
      import ietf-netconf-acm {
        prefix nacm;
        reference
          "RFC 8341: Network Configuration Access Control Model";
      }
Where the reference is to an I-D, the usual practice is still to include 
a reference e.g.
      import ietf-tcp-common {
        prefix "tcpcmn";
        reference
          "I-D.ietf-netconf-tcp-client-server: YANG Groupings for TCP
           Clients and TCP Servers.";

Also I see 'Ref AAAA Appendix B' with no note as to what AAAA is or will 
be; perhaps an RFC Editor note would clarify

Tom Petch

> And following up on my other comments
>
>     <CODE BEGINS> file "[e-mail]"
> interesting date
>
> YANG 'import' must have a YANG 'reference' clause
> e.g.
>     import ietf-inet-types {
>       prefix inet;
>       reference "RFC6991: Common YANG Data Types";
>
>
> TLP in the YANG modules is out of date.
>
> Copyright references 2021
>
>  >>        "Defines a specific instance of an event log entry
>  >>         and corresponding to the information used to
>  >>         extended the PCR";
>
> / and corresponding to the information used to
> extended the PCR/ corresponding to the information used to extend the PCR/
> perhaps
>
> My thinking on NACM was that the statement would actually appear in the
> YANG as you can see in draft-ietf-tcpm-yang-tcp
>
> Tom Petch
>
>
>> On 28/01/2022 20:56, Eric Voit (evoit) wrote:
>>> Hi Tom,
>>> Hi Henk,
>>>
>>> Tom: from your other thread, the requested references from the YANG
>>> model
>>> have been updated throughout the document as requested.   We will post
>>> a new
>>> version as soon as the other topics below are covered to your
>>> satisfaction.
>>>
>>> Henk: there is one change I hope you can help with.  Search on **Henk.
>>>
>>>> From: tom petch, January 19, 2022 6:24 AM
>>>>
>>>> These comments are separate from my previous comments on references
>>>> in the
>>>> YANG modules.  That said,
>>>>
>>>> 'import' in YANG module must have a YANG reference clause which must
>>>> be a
>>>> Normative Reference in the I-D Reference.
>>>
>>> This has been updated as part of references fix from your other
>>> email.  And
>>> new text inserted prior to each YANG model describes the embedded
>>> references
>>> from the draft's Normative list.
>>>
>>>> ietf-hardware must has a prefix of 'hw' as per RFC8348  throughout
>>>> the I-D
>>>
>>> Change made.
>>>
>>>> /http:datatracker/https:/datatracker/
>>>> in both modules
>>>
>>> Change made.
>>>
>>>>          reference
>>>>            "draft-ietf-rats-yang-tpm-charra";
>>>> perhaps
>>>>          reference
>>>>            "RFC XXXX: A YANG Data Model for Challenge-Response-based
>>>> Remote
>>>> Attestation Procedures using TPMs";
>>>
>>> Change made.
>>>
>>>>        identity attested_event_log_type {
>>>>          description
>>>>            "Base identity allowing categorization of the reasons why
>>>> and
>>> /and/an/ ?
>>>
>>> Change made.
>>>
>>>>          leaf TPMS_QUOTE_INFO {
>>>> most YANG identifiers have been changed to lower case; should this
>>>> one be?
>>>
>>> Multiple review discussions have driven this to be upper case because
>>> there
>>> is a 1:1 correspondence with an identical object defined by TCG.
>>>
>>>>        grouping boot-event-log {
>>>> could do with more explanation and/or references for this.
>>>
>>> I made the group description:
>>>        "Defines a specific instance of an event log entry
>>>         and corresponding to the information used to
>>>         extended the PCR";
>>>
>>> e.g. are there
>>>> semantics for the uint32 event-type?
>>>
>>> ** Henk, can you improve this ietf-tpm-remote-attestation.yang leaf
>>> description with a reference:
>>>
>>>      leaf event-type {
>>>          type uint32;
>>>          description
>>>            "log event type";
>>>      }
>>>
>>>> Security Considerations mention the use of NACM; should the RPC have a
>>>> default deny-all?
>>>
>>> Added "with a default setting of deny-all".
>>>
>>>>              leaf physical-index {
>>>> should this reference the YANG RFC8348 rather than the SMI equivalent?
>>>
>>> It could.  The initial requirement was driven by someone who wanted to
>>> allow
>>> operations to make an easy mapping to corresponding Entity MIB data they
>>> currently used.  In the end the populated info will be the same.
>>>
>>>>              leaf manufacturer {
>>>> these are often modelled as Privat Enterprise Numbers as registered
>>>> with
>>> IANA -
>>>> see e.g. draft-ietf-dots-telemetry
>>>
>>> This could be done.  Nobody in the WG suggested a purpose for
>>> leveraging a
>>> mechanized list of values here.  I expect the major use would be for
>>> manual
>>> debugging / manual checking if something went wrong.  Certainly a formal
>>> list could be maintained.  It just didn't seem important yet.
>>>
>>>>          reference
>>>>            "RFC XXXX: tbd";
>>>> as above
>>>
>>> Updated.
>>>
>>>>        identity tpm20 {
>>>>          if-feature "tpm12";
>>>> looks odd - if correct then worth an explanatory note
>>>
>>> Fixed.
>>>
>>> Eric
>>>
>>>> Tom Petch
>>>>
>>>> On 14/01/2022 16:16, The IESG wrote:
>>>>>
>>>>> The IESG has received a request from the Remote ATtestation ProcedureS
>>>>> WG
>>>>> (rats) to consider the following document: - 'A YANG Data Model for
>>>>> Challenge-Response-based Remote Attestation
>>>>>      Procedures using TPMs'
>>>>>     <draft-ietf-rats-yang-tpm-charra-12.txt> as Proposed Standard
>>>>>
>>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>>> final comments on this action. Please send substantive comments to the
>>>>> [e-mail] mailing lists by 2022-01-28. Exceptionally,
>>>>> comments may be sent to [e-mail] instead. In either case, please
>>>>> retain the beginning of the Subject line to allow automated sorting.
>>>>>
>>>>> Abstract
>>>>>
>>>>>
>>>>>      This document defines YANG RPCs and a small number of
>>>>> configuration
>>>>>      nodes required to retrieve attestation evidence about integrity
>>>>>      measurements from a device, following the operational context
>>> defined
>>>>>      in TPM-based Network Device Remote Integrity Verification.
>>>>>      Complementary measurement logs are also provided by the YANG
>>>>> RPCs,
>>>>>      originating from one or more roots of trust for measurement
>>>>> (RTMs).
>>>>>      The module defined requires at least one TPM 1.2 or TPM 2.0 as
>>>>> well
>>>>>      as a corresponding TPM Software Stack (TSS), included in the
>>>>> device
>>>>>      components of the composite device the YANG server is running on.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The file can be obtained via
>>>>> https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/
>>>>>
>>>>>
>>>>>
>>>>> No IPR declarations have been submitted directly on this I-D.
>>>>>
>>>>>
>>>>> The document contains these normative downward references.
>>>>> See RFC 3967 for additional information:
>>>>>       draft-ietf-rats-tpm-based-network-device-attest: TPM-based
>>>>> Network
>>>> Device Remote Integrity Verification (None - Internet Engineering Task
>>> Force
>>>> (IETF))
>>>>>       draft-ietf-rats-architecture: Remote Attestation Procedures
>>>>> Architecture (None - Internet Engineering Task Force (IETF))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IETF-Announce mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>> .
>>>>>