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

["Smith, Ned" <[e-mail]>]

@Eric Voit (evoit) Is this suggesting that RATS architecture should define a token-like DM structure that is a *request* "token" having only tags identifying interesting claims while a *response* "token" would have claims with data values populated?

On 11/14/19, 8:02 AM, "Eric Voit (evoit)" <[e-mail]> wrote:

    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