Re: [Rats] Vetting claim definitions

[Laurence Lundblade <[e-mail]>]

This exchange was really helpful for me.

So an EAT / CWT / JWT remain as a signed self-secured message that can be moved in lots of different ways. That can include the RPC mechanisms defined using YANG that seem to be the main means of moving management data in/out of routers. I hope we get to writing a little bit of YANG to define that. As with CWT and JWT the means of moving the messages around include HTTP headers, extension points in other protocols and so on. Seems like draft-birkholz-reference-ra-interaction-model holds for most of them.

Additionally, we always consider YANG-defined objects when we defined EAT / CWT / JWT claims.

I’m going back to working on the EAT draft now.

LL


> On Jun 11, 2019, at 2:03 PM, Eric Voit (evoit) <[e-mail]> wrote:
> 
> Hi Laurence,
>  
> From: Laurence Lundblade, June 11, 2019 11:21 AM
> 
> Hi Eric,
>  
> What I’m trying to figure out here is where there can be real practical interoperability with extant YANG-defined objects and how we go about it as I assume this is your current objection to adoption.
>  
> <eric> I certainly intended no argument against adoption.  I did vote in favor of adoption.  It was just that I want to see this topic addressed as part of the draft's progression.  I think the vote summary from Kathleen covers my desire just fine.
> 
> On Jun 10, 2019, at 2:23 PM, Eric Voit (evoit) <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Laurence,
>  
> It is true that the YANG of draft-birkholz-rats-basic-yang-module is currently TPM2 specific.  But over the past month we have been having discussions on how to augment into this model case statements and a tree structure which allows exposure of information from alternative hardware types such as the TPM1.2.  
>  
> Per your note below, I am guessing that draft-birkholz-rats-basic-yang-module could provide a query/response interface to access EAT information.  The Network Element's YANG model theoretically could allow access based on whatever choice of protocols the Network Element supports (e.g., NETCONF/XML. RESTCONF/JSON, CoMI/CBOR).  But the choice and protocols of used to access EAT objects over a YANG interface is something each platform would need to define.   The baseline choice for Interoperability here is tbd.
>  
> You mentioned a YANG interface. Seems like a point where there might be interoperability. Is this an interface on the router that is used to collect the claims data before signing? Or is it an interface on the back end / server / relying party that is involved in validating the data? Or maybe it is the rpc interaction defined in draft-birkholz-rats-basic-yang-module? I’m not sure what the intended endpoints of that RPC are. Router and Relying Party? 
>  
> <eric>  It is the RPC mechanism.  The RPC mechanisms allow a relying party to fetch internal datastore objects within the Router.   
>  
> One vendor specific example of a domain relevant YANG model is here:
> https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/16101/Cisco-IOS-XE-boot-integrity-oper.yang <https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/16101/Cisco-IOS-XE-boot-integrity-oper.yang>
> This model allows information from within a cryptoprocessor to be inspected by both the router and the relying party *after* it has been signed by the one of the router's cryptoprocessors.
>  
> Note: this model is just one of almost 400 YANG models supported on that type of device:
> https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/16101 <https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/16101>
> Looking at this second link, you can get an idea of the level of investment placed into YANG by Router vendors attempting to unify the exposure of information.
>  
>  
> Now that we are generally agreeing that an EAT is a CWT or JWT, the interaction model between device and relying party is inherited from them. Mostly we’re defining the format of a signed message and leaving the transport of the message open-ended so it can be embedded in HTTP headers, protocol extensions and such. If YANG is used to define interaction on routers, then some YANG RPC could be used (if that is what YANG RPC is) to define transport of CWTs (if CWTs are used on routers). There’s also draft-birkholz-reference-ra-interaction-model.
>  
> <eric> I have been seeing EAT as a useful way to define what comes out of cryptoprocessor hardware which might be located on a router.  For relying parties outside the router, the EAT raw payload might be fetched through RPC.  Or perhaps some or all of the corresponding YANG objects might be fetched.  Additionally, specific objects could be referenced so that logic on the router might be applied based on the value of that object.   A good example we have tested here is when we send a notification message to a relying party only when a specific PCR has changed.  This level of granularity means the relying party doesn't have to continuously poll for the router to see if the PCR has changed. 
>  
>  
> Whether it is even meaningful/relevant to support such YANG-EAT interoperability is something I don't know yet.  For me to consider EAT for implementation would mean EAT has been adopted within routers/switches.   As this is possible, I feel there is little for the WG to lose if we try to select/define some common objects which span our different domains.
>  
>  
> Here’s comments on a pass through draft-birkholz-rats-basic-yang-module
>  
> grouping nonce {... Seems essentially compatible with nonce / cti / jai in CWT / JWT
> grouping pcr-selection {...   TPM-specific so we probably go with the YANG definition
> grouping pcr-selector {...   TPM-specific so we probably go with the YANG definition
> grouping signature-scheme {… EAT will use COSE for this
> grouping attestation-key-identifier {… EAT will use COSE for this
> grouping tpm-name {… TPM-specific so we probably go with the YANG definition
> grouping compute-node {… I think this one needs work to figure out what it is and if EAT’s UEID is similar
> grouping node-uptime {… Seems simple to make exactly the same for EAT
> grouping log-identifier {… and grouping boot-event-log {… and other log stuff… Maybe TPM specific; maybe needs work to understand
> grouping ima-event {… and related. We do want some IMA claims in CWT format. Maybe they are part of EAT. Maybe they are separate. Maybe they use the YANG definition. 
>  
> <eric> This is a nice start on the type of analysis I am hoping to see.   I think as we work this through, we can save mapping cycles for future developers.  
>  
> Please understand that in no way do I claim that YANG is perfect.  And YANG models can take years to complete.   But on the plus side for YANG, I am sure it is possible to construct YANG models so that new hardware types can be inserted.  If you want a preview of the types of structure which might be used for this type of extensibility, check out at how draft-ietf-netconf-yang-push augments new case types into a the YANG model described within draft-ietf-netconf-subscribed-notifications.
>  
> YANG not perfect?? Huh? What?  :-)
>  
> I wish some YANG experts would chime in more here. I’m trying to learn on the fly and really should be updating the EAT draft instead.
>  
> <eric>  I encourage other YANG viewers out there to chime in as well.
>  
> Eric
>  
> LL
>  
> 
> 
>  
> Eric
>  
> From: Laurence Lundblade, June 10, 2019 2:57 PM
> 
> 
> Hi Eric,
>  
> So I think we have some agreement on general principles for how to structure the documents this work group produces so we can have both flexibility in the definition of new claims and well-defined concise sets claims for particular use cases. 
>  
> In particular I appreciate the confirmation of this from Mike Jones. Hopefully lack of objection implies a lot of agreement. 
>  
>  
> Eric, I think you are now digging into the next level of detail on how to deal with TPM-based implementations and claims specified in YANG and how that will interoperate with CWT/COSE and JWT/JOSE based tokens.
>  
> I don’t really understand YANG and how to fully read draft-birkholz-rats-basic-yang-module yet. Working on it (but I should be working on the new EAT draft…)
>  
> draft-birkholz-rats-basic-yang-module REQUIRES a TPM to implement it. That implies to me that neither CWT/COSE and JWT/JOSE signed container formats can be used because I don’t think TPM’s can produce either format. Pretty sure we agree that EAT will always be CWT/COSE or JWT/JOSE. 
>  
> (It is also odd to me that an IETF standard would require particular HW. It should just be about bits on the wire. EAT will have some means to indicate the security of the HW and SW that produced a given token, but will not require any particular security from the HW or SW)
>  
> But let’s assume that a relying party (I think you call this the Network Element) can unpack and verify signature that in the format of CWT and JWT and the TPM-style sig that I think is implied by draft-birkholz-rats-basic-yang-module. The result will be a set of claims in some syntax. It will be CBOR or JSON in the case of CWT or JWT. 
>  
> What will it be for draft-birkholz-rats-basic-yang-module??? YANG-described stuff an be lots of different syntaxes by my understanding. How many of them will a relying party be expected to support so there is interop?
>  
> I’m going to stop here for the answer to that question.
>  
> LL