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

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

From: Laurence Lundblade, November 15, 2019 3:47 PM
To: Henk Birkholz <[e-mail]>



 

I want to do it like the current EAT document (current draft’s labeling of info and data model aside)

1.	Normative definitional text per claim
2.	CDDL per claim
3.	Largely mechanical rules to go from CDDL to CBOR & JSON.

 

The subtleties of info vs data model escape me (and don’t seem that critical to me for the work at hand). The main thing I care about is that we one main definition of a claim that is not replicated and it can mechanically to go CBOR, JSON and maybe other serializations.

 

You can tell me how to label 1, 2, and 3 however you want and I’ll probably just use that in the EAT doc.

 

 

Also, by this I meant

 

I’d also like EAT to only use CDDL for the data model and nothing else

 

no YANG for the primal definition of claims and no YANG in the EAT document (see my other recent email with the X.509 analogy for suggestion on how to integrate with YANG expression of claims).

 

This is fine with me.  Let's expose EAT claims within YANG objects when somebody needs this.

 

Eric

 

 

LL

 

 

 





On Nov 15, 2019, at 11:30 AM, Henk Birkholz <[e-mail] <mailto:[e-mail]> > wrote:

 

Hi Laurence,

I would like to highlight this quote:




I’d also like EAT to only use CDDL for the data model and nothing else


This is a significant change of turn. I would like to get more background about why you are not intending to use CDDL as an information model anymore and also why you think using CDDL as a data model specification is helpful to define Claims.

I can see the point that CDDL was not done when CWT was done. And I think that would be a good argument.

Alas, I am more at a loss now how we intend to deal with the IM aspect in RATS now. The thing we tried to propose initially was an English description. That did not find consensus and CDDL seemed to be the new approach. What are we doing now, if you are proposing to down-level CDDL to data model again, creates a vacuum. Are we going back to English text es we initially proposed? In retrospect, why are you dropping the approach your were advocating for quite some time?

My concern is that this accumulation of changes in a lot of places has the exact opposite effect of expedition - which was the primary incentive for the initial proposal, I think?

Having said that, cddl is literally a data definition language. I just think it is hard to argue why we are changing horses do close to the finish line. I do not object on a technical level, I just want to highlight that is a significant change of direction.

Viele Grüße,

Henk


On 15.11.19 20:13, Laurence Lundblade wrote:



Here’s a try at an analogy of EAT Tokens with X.509 Certificates.
For both the core of the definition is of the signed serialized data format. A set of fields / claims is defined in the core standard. That core standard is solely focused on the definition of those fields / claims and shouldn't get intertwined with other protocol definitions.
However, other protocols may decide to have fields that are the same as, maybe even defined in terms of the fields  / claims in the token / certificate. Those definitions are probably normative references to the fields / claims in the core token / certificate standard. TLS makes normative references to PKIX this way in section 4.2.5. I think this is perfectly reasonable things to do.
So, I have no trouble with some EAT claims being used in YANG designs, but I’d like it to be by reference to EAT. I’d also like EAT to only use CDDL for the data model and nothing else.
I think trying for a single information model that is common to EAT and YANG designs is too big, too much intertwining and is scary. It will lead to schedule interlocks between the documents.
Another reason is that I view router / YANG use of attestation as only one (well-represented) use case for EAT. YANG-based use cases shouldn’t be central to EAT's design. If we were to intertwine with YANG, maybe we should intertwine with JavaScript and a bunch of IoT protocols too.
LL



On Nov 14, 2019, at 12:42 PM, Eric Voit (evoit) <[e-mail] <mailto:[e-mail]> > wrote:

My belief is that a Relying Party will rarely want the full universe of signed claims coming from some Attester's chip.   We need ways to pre-filter the results.  How would we do this without a model?

To fill this need, I always hoped that EAT claims could become leafs of some future YANG data model.  This would allow GET and SUBSCRIBE requests to be made to an Attester.  What would be returned to the Relying Party would be the signed results of interest from some chip within the Attester.

I have no position on whether the WG wants to integrate GET and SUBSCRIBE requests so that they can provision claims are ultimately placed within the EAT token.

Eric




@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] <mailto:[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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/rats

 


_______________________________________________
RATS mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/rats