Re: [Rats] Call for adoption (after draft rename) for Yang module draft

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

Hi Jürgen,
Hi Henk,

What routers need is exactly what you said.  
 - currently: the retrieval of TPM originated/signed quotes.   
 - in the future: the retrieval EAT Tokens

Knowing when to retrieve these items is a function of the value of specific claims inside those structures.  For example, I might want to use RFC-8641 to make a YANG Subscription to a router so that I will be pushed the latest TPM quote when a specific PCR changes.  For this to work in the router world, we must have the structures of Quotes/Tokens exposed by a YANG model.

Eric

> Hi Jürgen,
> 
> I think this is very useful input.
> 
> On the list, Laurence and I already started to discuss Claims for "YANG
> modeled data" and Claims for "TPM modled data" (referred to as tpm tokens
> recently).
> 
> The remaining questions are about: What do you think is the upcoming/TBD
> impact on the current YANG module for challenge-response RATS?
> 
> Leveraging YANG modeled data comes up again and again. Maybe there is
> good approach here.
> 
> The TPM Interface based YANG Module does not simply convey native TPM
> structure, but decomposes them down the values that are useful and
> common on the management plane because the building blocks themselves
> have well defined semantics (always ensuring canonical re-composition).
> 
> Viele Grüße,
> 
> Henk
> 
> On 14.11.19 15:06, Schönwälder, Jürgen wrote:
> > On Wed, Nov 13, 2019 at 10:07:02AM -0800, Laurence Lundblade wrote:
> >>
> >> I see EAT as applicable to all these worlds, where the YANG module is just
> for the smallish router world. So I mostly agree with Dave about proportions,
> however this is the IETF where YANG modules are created.  (Maybe I should
> go join the W3C world and work on attestations APIs for browsers after RATS
> is done).
> >>
> >
> > If EAT is the common format for "token", then it does not make sense
> > to me to define a YANG version of it. It may make sense to carry EAT
> > token over protocols such as NETCONF or RESTCONF and to have a YANG
> > module defining this may make sense for the networking device world.
> > This is then a definition of an interaction protocol, but not the
> > token format itself.
> >
> > If EAT is the common format for "token", then it may make sense to be
> > able to include "claims" that are YANG defined data. That may be an
> > extension of the core EAT definition (but EAT would have to allow for
> > such an extension to work). There is a lot of formally defined data in
> > YANG modules that would be convenient to reuse as claims in a
> > networking world.
> >
> > /js
> >
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats