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

["Eric Voit (evoit)" <[e-mail]>]

> From: Juergen Schoenwaelder, March 5, 2021 11:59 AM
> 
> On Fri, Mar 05, 2021 at 04:23:27PM +0000, Eric Voit (evoit) wrote:
> > Hi Juergen,
> >
> > > On Fri, Mar 05, 2021 at 03:42:54PM +0000, Eric Voit (evoit) wrote:
> > > > 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.
> > >
> > > Except you had a broken config true node.
> > >
> > > > 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?
> > >
> > > 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.
> >
> 
> 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
>              "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.

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}?
 
> /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.

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

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

> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats