Subject: Re: [Rats] do not address yang warnings by making nodes writable

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Mar 2021 12:11:44 +0100

Eric,

I think you want to configure that "this config applies to TPMs
version X", i.e., you configure the version that needs to match the
TPMs version so that your config can apply, you are of course not
configuring the TPM's version (that would require a TPM configuration
model but as you write, for many TPMs this will be by design not
configurable).

For network interfaces, we do the same: You write down the
configuration of a network interface and we expect that the
configuration only gets applied if a matching network interface is
actually present. (This is basically where the difference between
intended configuration and applied configuration comes into play.)

/js

On Fri, Feb 19, 2021 at 04:35:32PM +0000, Eric Voit (evoit) wrote:
> Hi Juergen, 
> 
> > From: Juergen Schoenwaelder, February 19, 2021 11:01 AM
> > 
> > I do not know what the purpose of the MUST statements is since I did not
> dig
> > deeper but it could be that config is only applied to TPMs where the
> configured
> > version matches the version of the TPM. This would then require to
> configure
> > the version, much like we allow to provision interface configs even if
> there is
> > (currently) no matching interfaces.
> >
> > It could also be that the WG does not want to allow something to be
> configured
> > for a TPM version that does (currently) not exist. Even in that case, you
> would
> > have to convey the TPM version as part of the config and then have logic
> > defined in description statements that such config snippets are to be
> rejected
> > (instead of being not applied).
> 
> This is closer to the purpose.  
> 
> The TPM is a hardware device* which will follow an API defined in another
> standards body.   The TPM has firmware which will not be configured through
> YANG model.  It is conceivable that new TPM firmware versions will be
> exposed, so ENUMs cannot be used.   It is this firmware version which will
> allow other relevant configuration operations to be applied.
> 
> So you cannot change the configuration datastore for this object (as it is
> read internally).   But you also can't make the object as "config false", as
> other configurable items depend on it.  If there is a proper way to document
> such a relationship, it would be great to update the model so that the
> relationship does not require the text currently in the description.   Any
> suggestions?
> 
> * There are also such things as Virtual TPMs.  This model is intending to
> frame YANG structures which can be reused should others want to build for
> these as well.   But that is out-of-scope here.
> 
> Thanks,
> Eric
> 
> > My point is that saying a leaf is rw config, it is expected to be used for
> > validation, but it is not expected to be there is not working.
> > 
> > Personally, I prefer config that can be provisioned but may not be applied
> if it
> > does not match the resources (currently) available.
> > Yes, this requires to check for possible differences between applied and
> > provisioned (aka running) config but the opposite gets you into situation
> where a
> > hardware component failures leads to an invalid config and you are either
> > bricked or in a mode hard to understand.
> > 
> > /js
> > 
> > On Fri, Feb 19, 2021 at 09:36:40AM -0500, Michael Richardson wrote:
> > >
> > > Juergen Schoenwaelder <[email-masked]> wrote:
> > >     > I doubt that this is a proper solution as you now have to
> configure the
> > >     > tpm-firmware-version. If you cannot configure this (as the
> description
> > >     > says), then the MUST may always be false, i.e, once you implement
> this,
> > >     > you will see that this does not work.
> > >
> > > I am not clueful about XPATH forcing "rw"... is there another solution?
> > >
> > > --
> > > Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting
> )
> > >            Sandelman Software Works Inc, Ottawa and Worldwide
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > RATS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rats

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 5 Mar 2021 15:42:54 +0000

Hi Juergen,

Where you say "this config applies to TPMs version X", we are accomplishing
a similar function via when statements,  E.g.:

        uses TPM12-hash-algo {
          when "tpm-firmware-version = 'taa:tpm12'";

It is possible to place what is currently within these 'when' statement to
instead be within the descriptions.  But using 'when' statements seemed a
more robust approach.

Based on our discussion, I can adjust that description of "leaf
tpm-firmware-version" to:     "Identifies the cryptoprocessor API set
supported.  This is automatically configured by the device and should not be
changed."   This will eliminate the earlier text about a YANG warning and
NMDA.  Is this a reasonable approach?

Thanks,
Eric

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: Friday, March 5, 2021 6:12 AM
> To: Eric Voit (evoit) <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; [email-masked]
> Subject: Re: [Rats] do not address yang warnings by making nodes writable
> 
> Eric,
> 
> I think you want to configure that "this config applies to TPMs version
X", i.e.,
> you configure the version that needs to match the TPMs version so that
your
> config can apply, you are of course not configuring the TPM's version
(that
> would require a TPM configuration model but as you write, for many TPMs
this
> will be by design not configurable).
> 
> For network interfaces, we do the same: You write down the configuration
of a
> network interface and we expect that the configuration only gets applied
if a
> matching network interface is actually present. (This is basically where
the
> difference between intended configuration and applied configuration comes
> into play.)
> 
> /js
> 
> > > have to convey the TPM version as part of the config and then have
> > > logic defined in description statements that such config snippets
> > > are to be
> > rejected
> > other configurable items depend on it.  If there is a proper way to
> > document such a relationship, it would be great to update the model so
that
> the
> > * There are also such things as Virtual TPMs.  This model is intending
> > to frame YANG structures which can be reused should others want to build
for
> > > My point is that saying a leaf is rw config, it is expected to be
> > > used for validation, but it is not expected to be there is not
working.
> > > Yes, this requires to check for possible differences between applied
> > > and provisioned (aka running) config but the opposite gets you into
> > > situation
> > where a
> > > hardware component failures leads to an invalid config and you are
> > > either bricked or in a mode hard to understand.
> > >
> > > /js
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Mar 2021 16:52:45 +0100

> instead be within the descriptions.  But using 'when' statements seemed a

Except you had a broken config true node.
 
> NMDA.  Is this a reasonable approach?

Overwriting YANG semantics is not what you want. Perhaps you actually
want to use a YANG feature to make parts of the model conditional to a
feature indicating different TPM versions. Of, you already have an
if-feature. It might well be that I do not understand what you are
trying to achieve.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 5 Mar 2021 16:23:27 +0000

Hi Juergen,

> > Where you say "this config applies to TPMs version X", we are
> > accomplishing a similar function via when statements,  E.g.:
> >
> >         uses TPM12-hash-algo {
> > It is possible to place what is currently within these 'when'
> > statement to instead be within the descriptions.  But using 'when'
> > statements seemed a more robust approach.
> 
> Overwriting YANG semantics is not what you want. Perhaps you actually want
to
> use a YANG feature to make parts of the model conditional to a feature
> indicating different TPM versions. Of, you already have an if-feature. It
might
> well be that I do not understand what you are trying to achieve.

Unfortunately using an if-feature does not provide sufficient granularity.
A device can concurrently support multiple TPMs, each potentially having
either TPM1.2 or TPM2 firmware.  The model is trying to ensure that a
specific instance of a TPM can only be configured to use a valid subset of
the allowable algorithms permitted by the type of firmware available.   

Eric

> > > version
> > > configuration
> > > difference between intended configuration and applied configuration
> > > comes into play.)
> > >
> > > /js
> > >
> > > > > have to convey the TPM version as part of the config and then
> > > > > have logic defined in description statements that such config
> > > > > snippets are to be
> > > > rejected
> > > > exposed, so ENUMs cannot be used.   It is this firmware version
which
> > will
> > > > So you cannot change the configuration datastore for this object
> > > > (as it
> > is
> > > > other configurable items depend on it.  If there is a proper way
> > > > to document such a relationship, it would be great to update the
> > > > model so
> > that
> > > the
> > > > * There are also such things as Virtual TPMs.  This model is
> > > > intending to frame YANG structures which can be reused should
> > > > others want to build
> > for
> > > > > My point is that saying a leaf is rw config, it is expected to
> > > > > be used for validation, but it is not expected to be there is
> > > > > not
> > working.
> > > > >
> > > > > Yes, this requires to check for possible differences between
> > > > > applied and provisioned (aka running) config but the opposite
> > > > > gets you into situation
> > > > where a
> > > > > hardware component failures leads to an invalid config and you
> > > > > are either bricked or in a mode hard to understand.
> > > > >
> > > > > /js
> > > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Mar 2021 17:58:59 +0100

> the allowable algorithms permitted by the type of firmware available.   

But then the config needs to say to which TPM and TPM type (version)
it applies. And in case there is a mismatch, the config does not get
applied or even rejected. From the interfaces YANG model:

         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "The type of the interface.

	      [...]

              If a client tries to set the type of an interface to a
              value that can never be used by the system, e.g., if the
              type is not supported or if the type does not match the
              name of the interface, the server MUST reject the request.
              A NETCONF server MUST reply with an rpc-error with the
              error-tag 'invalid-value' in this case.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

The point here is that the config explicitly says what is
required/expected and the server reacts to it. I configure

<tpms>
  <tpm-name>tpm42</tpm-name>
  <tpm-firmware-version>taa:tpm12</tpm-firmware-version>
  <TPM12-hash-algo>taa:TPM_ALG_SHA1</TPM12-hash-algo>
  <!-- -->
</tpms>

and this gets applied if there is a tpm42 which supports taa:tpm12.

/js

PS: The example writing also revealed that there is little consistency
    in the naming, sometimes you prefix leaf names, sometimes you
    don't, sometimes you use capital letters, sometimes you use
    underscores then again hyphens etc.

    If you prefix leaf names with the module prefix, you end up with
    tpm:tpm-name and now that I write this it seems odd to call the
    prefix tpm since this is not really about configuring TPMs but
    remote attestations using TPMs. (I would rather leave the tpm
    prefix to a YANG module dealing with TPMs in general. Well,
    perhaps there is the beginning of a generic TPM module hidden in
    here, but then it might be useful to actually factor this out.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 5 Mar 2021 18:30:10 +0000

> From: Juergen Schoenwaelder, March 5, 2021 11:59 AM
> 
> > > > supported.  This is automatically configured by the device and
> > > > should
> > not be
> > > > changed."   This will eliminate the earlier text about a YANG
warning
> > and
> > > use a YANG feature to make parts of the model conditional to a
> > > if-feature. It
> > A device can concurrently support multiple TPMs, each potentially
> > having either TPM1.2 or TPM2 firmware.  The model is trying to ensure
> > that a specific instance of a TPM can only be configured to use a valid
subset
> of
> But then the config needs to say to which TPM and TPM type (version) it
applies.
> And in case there is a mismatch, the config does not get applied or even
> rejected. 

I believe the current model accomplishes this, without the need for placing
the constraining information in the description.  More below.

> From the interfaces YANG model:
> 
>          leaf type {
>            type identityref {
>              base interface-type;
>            }
>            mandatory true;
>            description
required/expected and
> the server reacts to it. I configure
> 
> <tpms>

I agree there are lots of similarities to the interface model.  In the
interface model, you have:

     +--rw interfaces
        +--rw interface* [name]
           +--rw name                        string
           +--rw type                        identityref 

And in this model we have:

   +--rw tpms
      +--rw tpm* [tpm-name]
         +--rw tpm-name                        string
         +--rw tpm-firmware-version    identityref

In both cases above the device itself should recognize the hardware
instances and configure those objects appropriately.   Now looking at the
other object in the tree above "TPM12-hash-algo", i.e.,

   +--rw tpms
      +--rw tpm* [tpm-name]
        +--rw TPM12-hash-algo?        identityref

This object can only be provisioned if that identityref also exists in
container "attester-supported-algos".  This container identifies which TCG
algorithms are available for use the platform.  This allows container also
has the benefit of allowing an operator to limit algorithms available for
use by RPCs to just a  desired set from the universe of all allowed by the
firmware.  To see more, check the descriptions of:

   +--rw attester-supported-algos
      +--rw tpm12-hash*                 identityref {taa:TPM12}?
 
>     underscores then again hyphens etc.

There are two YANG models within the draft.   

"taa"  which contains a list of algorithm types maintained by the TCG.

"tpm" which allows RPCs to be made to TPMs

To my recollection, the prefixes are only used when referring to an outside
model except when there are xpath constraints involved.  I claim no special
expertise on XPATH, and would love to get help in this space in fact.  If
you know someone who could help with the XPATH in "leaf-list pcr-index",
that would be superb.

On the capitalization and underscoring, we always use lower case and dashes
except when the model explicitly names objects which are equivalent to
objects defined by the TCG.  By using the exact TCG syntax, there is less
chance of people thinking things are not equivalent.
 
>     here, but then it might be useful to actually factor this out.

TPMs themselves are not really configured, except when people are attempting
to do keystore stuff.  And much of that is contained in Kent's keystore
drafts over in the NETCONF WG.  I don't think there will be needed
standardization here for a while.

Thanks,
Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Mar 2021 12:50:23 +0100

On Fri, Mar 05, 2021 at 06:30:10PM +0000, Eric Voit (evoit) wrote:
> instances and configure those objects appropriately.

I do not think the interfaces model has a config true leaf saying:

            "Identifies the cryptoprocessor API set supported.  This
            cannot be configured.  However it is referenced via XPATH
            as part of configuration, so is shown as 'rw'
            to eliminate YANG warnings related NMDA.";

This is what got this discussion started.

> Now looking at the

My point is that TPM12-hash-algo is having

and hence tpm-firmware-version needs to be configured for this to
be meaningful.

/js

PS: I find the mixed capitalization and hyphen/underscore style
    confusing

    leaf TPM_QUOTE2 {
      type binary;
      description
	"Result of a TPM1.2 Quote2 operation. This includes PCRs,
        signatures, locality, the provided nonce and other data which
	can be further parsed to appraise the Attester.";
      reference
        "TPM1.2 commands rev116 July 2007, Section 16.5";
    }
    
    As far as I understand, TPM_QUOTE2 is the name of an operation
    and not the name of its result. So is this meant to be the
    serialization (network byte order?, alignment?) of the Outgoing
    Operands? Is the exact format of the binary blobs well defined?

    When I search for binary in the I-D, I hit quite a few leafs where
    the description does not tell me much what the binary format will
    be.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 8 Mar 2021 13:35:12 +0000

> From: Juergen Schoenwaelder, March 8, 2021 6:50 AM
> 
> > > > > > tpm-firmware-version" to:     "Identifies the cryptoprocessor
API
> > set
> > > > > feature indicating different TPM versions. Of, you already have
> > > > > an if-feature. It
> > > > might
> > > > having either TPM1.2 or TPM2 firmware.  The model is trying to
> > > > ensure that a specific instance of a TPM can only be configured to
> > > > use a valid
> > subset
> > > of
> > > it
> > > And in case there is a mismatch, the config does not get applied or
> > > even rejected.
> >
> > I believe the current model accomplishes this, without the need for
> > placing the constraining information in the description.  More below.
> >
> > container "attester-supported-algos".  This container identifies which
> > TCG algorithms are available for use the platform.  This allows
> > container also has the benefit of allowing an operator to limit
> > algorithms available for use by RPCs to just a  desired set from the
> > universe of all allowed by the firmware.  To see more, check the
descriptions
> of:
> and hence tpm-firmware-version needs to be configured for this to be
> meaningful.

Agree that it has to be configured.  This should be done by the server as it
recognizes the firmware during boot.  I have changed the description to:

"Identifies the cryptoprocessor API set supported.  This is automatically
configured by the device and should not be changed."   

>     the description does not tell me much what the binary format will

The binary format is described in the reference of many of those leaves.
For quotes coming from the TPM binary format is actually quite complex,
which is why it is best to refer to the TCG standards organization's
documents for this.  In several cases within the YANG file, this reference
is missing (e.g., the signature), I will put the references in now.

Eric