Subject: [Rats] Vetting claim definitions

From: Laurence Lundblade <[email-masked]>
Date: Tue, 4 Jun 2019 12:59:54 -0700

RFC 8126 <https://tools.ietf.org/html/rfc8126> gives guidelines for writing IANA considerations and is useful background here.

— Today CWT allocates about 512 slots for claims that are standards. These require a standards track RFC like the EAT draft might become. There can be other standards RFCs for attestation claims. They don’t all have to be defined in the one and only standard we are working on now. Seems that standardization is the path to really high quality claims that a lot of us want. 

— Today CWT allocates about 130,000 slots for specification-required. To get one of these slots also requires expert review and to publish a hopefully formal specification.

— Today CWT allocates millions of slots for expert review. No specification is required, but some information should be provided. 

JWT doesn’t seem to have this, which is maybe why it is messier. It kind of seems bad and wrong that it doesn’t to me.

COSE is like CWT for algorithms and headers and such. 

Anyone know if there are any YANG-based protocols that have IANA registries? Where are all the YANG data formats defined and registered that we are interested in making into attestation claims?

Seems to me the three tiers that CWT (and COSE) define are at least a very good start for our purposes. All the better claims are ones we run through a standards process. 

When we make them standard we’ll deal with how they line up with existing similar definitions in YANG, ASN.1, XML, JSON and such. Maybe the standard just says “use this YANG-defined format” in some particular way.

If we want something that is not as time-consuming and difficult as creating a standard, RFC 8126 defines a few more options between Standards Action and Specification Required. 

At any rate, we ought to be more familiar with 8126 and bring it in here more.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 4 Jun 2019 21:55:22 +0000

> From: Laurence Lundblade, June 4, 2019 4:00 PM
> 
> https://tools.ietf.org/html/rfc8126 gives guidelines for writing IANA
> considerations and is useful background here.
> 
> — Today CWT allocates about 512 slots for claims that are standards. These
> require a standards track RFC like the EAT draft might become. There can be
> other standards RFCs for attestation claims. They don’t all have to be defined in
> the one and only standard we are working on now. Seems that standardization is
> the path to really high quality claims that a lot of us want.

Yes, this is what we should concentrate on first.   I.e., Section 4.9 or RFC 8126.

> — Today CWT allocates about 130,000 slots for specification-required. To get
> one of these slots also requires expert review and to publish a hopefully formal
> specification.
> 
> — Today CWT allocates millions of slots for expert review. No specification is
> required, but some information should be provided.
> 
> JWT doesn’t seem to have this, which is maybe why it is messier. It kind of
> seems bad and wrong that it doesn’t to me.
> 
> Anyone know if there are any YANG-based protocols that have IANA registries?
> Where are all the YANG data formats defined and registered that we are
> interested in making into attestation claims?

There is an IANA registry for YANG models.
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

In the past I have looked through about a dozen of the hundred or so models here.   I suspect, some good starting places for people to look for objects/definitions which could be reused (or perhaps mapped) might be from:
https://www.iana.org/assignments/yang-parameters/[email-masked]
https://www.iana.org/assignments/yang-parameters/[email-masked] 
https://www.iana.org/assignments/yang-parameters/[email-masked]
https://www.iana.org/assignments/yang-parameters/[email-masked]
Note: the location model referenced in earlier threads is only a WG draft, which it is why it is not in the registry yet...
https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ 

As an FYI: beyond IANA, there was a search tool to find specific objects, but I am not sure it is being maintained
https://yangcatalog.org/yang-search/ 
And there are larger YANG repositories in other places (e.g., IEEE, OpenConfig, MEF) .  But as they are not IETF, likely we shouldn't worry about them.

> Seems to me the three tiers that CWT (and COSE) define are at least a very good
> start for our purposes. All the better claims are ones we run through a standards
> process.
>
> When we make them standard we’ll deal with how they line up with existing
> similar definitions in YANG, ASN.1, XML, JSON and such. Maybe the standard just
> says “use this YANG-defined format” in some particular way.

This makes sense.

Eric
 
> If we want something that is not as time-consuming and difficult as creating a
> standard, RFC 8126 defines a few more options between Standards Action and
> Specification Required.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Jun 2019 09:05:26 -0400

Laurence Lundblade <[email-masked]> wrote:
    > — Today CWT allocates millions of slots for expert review. No
    > specification is required, but some information should be provided.

    > JWT doesn’t seem to have this, which is maybe why it is messier. It
    > kind of seems bad and wrong that it doesn’t to me.

JWT doesn't have this because the claims are "unlimited" length strings, so
one can always make up a unique string in lieu of registration.
  org.island-resort.lgl.whateverstringyouwant

is probably completely yours :-)
Of course, if you want to interoperate you need to agree about how, so there
are some advantages of a forcing function that demands you write things down
first :-)

    > Anyone know if there are any YANG-based protocols that have IANA
    > registries? Where are all the YANG data formats defined and registered
    > that we are interested in making into attestation claims?

A number of YANG modules have imported IANA registries with mixed results,
and then wondered if they can be automatically extended when IANA extends
things.
Up until recently, YANG has been largely used to describe the management of
existing (non-YANG) protocols,  so I think that the issue you bring up
is something we have yet to properly tackle.

    > Seems to me the three tiers that CWT (and COSE) define are at least a
    > very good start for our purposes. All the better claims are ones we run
    > through a standards process.

I agree.

    > When we make them standard we’ll deal with how they line up with
    > existing similar definitions in YANG, ASN.1, XML, JSON and such. Maybe
    > the standard just says “use this YANG-defined format” in some
    > particular way.

YANG is to ASN.1 what CBOR is to DER.
So, it's important to remember that YANG doesn't define a format, but rather
an information model.

    > At any rate, we ought to be more familiar with 8126 and bring it in

It's definitely worth knowing well :-)
I seem to think that there was a Sunday EDU session about IANA
Considerations, but I can't trivially find a video. I did find:
                https://www.youtube.com/watch?v=D__mAX-2sXo
                https://youtu.be/Lk5j25nmZKY?t=223

but it isn't about IANA Considerations.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 5 Jun 2019 08:46:18 -0700

Below…
+ Mike Jones, co-author of CWT

> On Jun 5, 2019, at 6:05 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

Unlimited length string claim names are fully part of CWT. Also, COSE allows them for headers, algorithm names and such too. So from a syntax view CWT and COSE are the same as JWT in allowing long string names.

However, COSE and CWT are different in the management of the string name space:

Strings of length 1	Standards Action
Strings of length 2	Specification Required
Strings of length greater than 2	Expert Review

These, along with the integer names space rules, then imply:

Integer values less than -65536 are the only ones free for use with no review or processing by IANA and experts.

JWT also has this notion of Collision-Resistant Name based on OIDs or UUIDs, which is essentially some rules to make up names that don’t go into an IANA registry and are still unique and won’t collide.

JWT could have done what CWT does. Seems to me that CWT has taken a radically more managed approach to the super-open JWT approach. Maybe the CWT folks realized the JWT design was poor.

At any rate, there seems to be some consensus here that the CWT approach is what we want for attestation. It is also the more recent and thus maybe more advanced thinking.

I’m hoping we can find our way to just accept the CWT claim naming management scheme as is for attestation. If other CWT-based efforts did the same (draft-birkholz-core-coid) did the same then the world would be much simpler. 

However that still leaves open some issue with JWT namespace management. (We do want JSON based attestation to be JWT’s, right? Just the same as CBOR-based attestation are CWT’s).

LL

---

From: Mike Jones <[email-masked]>
Date: Wed, 5 Jun 2019 17:30:58 +0000

Actually, normal (non-collision-resistant) JWT claims *are* allocated on a specification required basis with expert review.  See this text at https://tools.ietf.org/html/rfc7519#section-10.1:

   Values are registered on a Specification Required [RFC5226<https://tools.ietf.org/html/rfc5226>] basis
   after a three-week review period on the [email-masked]
   mailing list, on the advice of one or more Designated Experts.
   However, to allow for the allocation of values prior to publication,
   the Designated Experts may approve registration once they are
   satisfied that such a specification will be published.

So a specification can easily register both JWT and CWT claims.

                                                       -- Mike

From: Laurence Lundblade <[email-masked]>
Sent: Wednesday, June 5, 2019 8:46 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; Mike Jones <[email-masked]>
Subject: Re: [Rats] Vetting claim definitions

Below…

On Jun 5, 2019, at 6:05 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 6 Jun 2019 12:02:04 -0700

So in conclusion, all claims for JWT are:

Specification Required

and CWT claims are in 4 categories:

Standards Action
Specification Required
Expert Review
Private Use

Rather than trying to further refine or control or restrict or manage what claims can be registered, I propose a different approach. We do the two following work:

1) Do the work here and up front to define lots of good claims in a standards-track RFCs. Maybe over time it is several RFCs. When we do this work we should consider previous work on JWT, CWT, YANG, ASN.1 and such claims and try to avoid duplication.

2) We create profiles that list recommended claims for different use cases (router, small IoT consumer IoT device, mobile phone…). Maybe some are standard track RFCs or maybe some are just informational. Also we know other organizations will do some of this work (GlobalPlatform, FIDO). 

So registration of new claims related to attestation is just the same as it is for CWT and JWT claims today.

LL

> On Jun 5, 2019, at 10:30 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> Actually, normal (non-collision-resistant) JWT claims *are* allocated on a specification required basis with expert review.  See this text at https://tools.ietf.org/html/rfc7519#section-10.1 <https://tools.ietf.org/html/rfc7519#section-10.1>:
>  
>    Values are registered on a Specification Required [RFC5226 <https://tools.ietf.org/html/rfc5226>] basis
> On Jun 5, 2019, at 6:05 AM, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 7 Jun 2019 11:28:46 +0000

FWIW: While the JWT registry looks more mixed in terms of claim types. This is, however, only a result of the widespread adoption.
There are no problems, as far as I know, with the diversity of the claims and that they are not all useful in every context. Different deployments use the claims they find useful.

I am wondering whether we are trying to fix a problem with the registry of claims that doesn’t occur in practice.

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Mike Jones
Sent: Mittwoch, 5. Juni 2019 19:31
To: Laurence Lundblade <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Vetting claim definitions

   after a three-week review period on the [email-masked]<mailto:[email-masked]>

                                                       -- Mike

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 5, 2019 8:46 AM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Vetting claim definitions

Below…

LL

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 7 Jun 2019 17:14:54 +0000

Hi Hannes,

If we were sure we could limit EAT claims to just a few things which come out of hardware, this wouldn't concern me as much as it does.  However the domain of attestable objects was left fairly open within the EAT draft.   And we need to determine what level of interoperability are we trying to shepherd via RATS.

In the end, RATS (and EAT) need to determine the level of interoperability desired for specific claims.   I don't claim deep familiarity with JWT.  But looking at RFC-7519, Section 4.1, I see that I would have questions as an implementer.  For example, the claims "iss", "sub", and "aud" look to have population/processing which is application specific.  Therefore with these claims, it is up to applications on either side of the JWT must come to an agreement on what the populated instances mean.  (I.e., not the WG.)

Common of object definitions/claims from internal hardware are important if the Network Element needs to act on specific values.  And as a vendor, I know that I do want to act on information coming out of hardware even if the information is being pushed to a remote validator (e.g., immediately push an EAT token downstream if a specific hash value changes).  As a result I want more explicit and stable claim definitions.

More highly specified claims of course exposes possible claim redundancy, foreign key relationships, and cross-mapping with downstream information models. I assert this is a good thing because we expose (and hopefully minimize) costs which are borne by downstream developers.

Eric

Hannes Tschofenig, June 7, 2019 7:29 AM

Ciao
Hannes

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Mike Jones
Sent: Mittwoch, 5. Juni 2019 19:31
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Vetting claim definitions

                                                       -- Mike

Below…

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Jun 2019 11:52:50 -0700

Hi Eric,

Feels like there’s opposing views:

1) Carsten, Kathleen, myself and maybe Henk and others want an EAT to be a CWT/JWT.This really does make the claim set open-ended. CWT is a bit more carefully managed than JWT, but we’ll still end up with a lot of claims registered. 

2) You want a very well-defined concise claim set, a controlled policy for allowing new claims and maximal interoperability.

I think both objectives are good and desirable.

I think the way to have both is to leave the CWT/JWT registration open as they are AND ALSO define a profile / subset in an IETF standard for your use case. This profile / subset can:

- Make clear normative references to extant claims that are considered well-enough formed and interoperable
- Define some new claims where none are extant
- Define a policy for adding new claims 
- Labelling to distinguish the profile from a general open-ended CWT/JWT

So one way forward is for this WG to adopt another document. Maybe call it “Router Attestation Profile”.  This would be in addition to EAT. It makes normative references to the EAT claims it likes.

Another way forward is for the EAT draft to change direction some and become the more tight and limited attestation definition. It would probably address more than just the router use case, but it would retain the main characteristics you want. If we do this, then we can expect other attestation use cases to write documents and maybe run them through this WG or maybe not.

LL

> On Jun 7, 2019, at 10:14 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Hannes,
>  
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Mike Jones
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; Michael Richardson <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
>    after a three-week review period on the [email-masked] <mailto:[email-masked]>
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> To: Michael Richardson <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Mike Jones <[email-masked] <mailto:[email-masked]>>

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Jun 2019 19:25:07 +0000

This is exactly the approach I’d advocate.  To be fully interoperable, both JWTs and CWTs by design require an application profile that defines the processing rules for each of the claims.  For instance, OpenID Connect defines something called an ID Token<https://openid.net/specs/openid-connect-core-1_0.html#IDToken>, which is a JWT with specific processing rules<https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation> for the claims.  For instance, it says how to use the “iss” (issuer) claim to retrieve public keys to validate the JWT signature.

For EATs, just like other applications of JWTs and CWTs, application profiles will be required to define the how to use the claims in the EAT.  This is as it should be.  If we also want to create such a profile (or multiple such profiles) in addition to the general EAT specification, we can do that.

                                                       -- Mike

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Friday, June 7, 2019 11:53 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Hannes Tschofenig <[email-masked]>; Mike Jones <Michael.Jones=[email-masked]>; [email-masked]
Subject: Re: [Rats] Vetting claim definitions

Hi Eric,

So one way forward is for this WG to adopt another document. Maybe call it “Router Attestation Profile”..  This would be in addition to EAT. It makes normative references to the EAT claims it likes.

LL

On Jun 7, 2019, at 10:14 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes,

Eric

Ciao
Hannes

Actually, normal (non-collision-resistant) JWT claims *are* allocated on a specification required basis with expert review.  See this text at https://tools.ietf.org/html/rfc7519#section-10.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7519%23section-10.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C698e0d0a833e41227e2908d6eb79825b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636955304457815708&sdata=U5SoqEEqak6b8XDbDwyzANNpMRZccH4wktDytsjbm5M%3D&reserved=0>:

   Values are registered on a Specification Required [RFC5226<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5226&data=02%7C01%7CMichael.Jones%40microsoft.com%7C698e0d0a833e41227e2908d6eb79825b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636955304457825910&sdata=sdIiV%2BjmTtmZtd%2BGFriMZ1%2Bx%2FtR8h%2FgQRYVjphT5%2FE4%3D&reserved=0>] basis

                                                       -- Mike

Below…

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 7 Jun 2019 20:31:02 +0000

Hi Laurence,

Effectively this “Router Attestation Profile” draft you are proposing would consist of well-defined claims which are also YANG objects.  And these YANG objects would augment the model definition within draft-birkholz-rats-basic-yang-module.

If you agree, this is exactly what I was hoping to hear.  Good things which can come from this approach:

  *   Network Elements would be capable of reading some subset of what is coming off of EAT capable hardware chips.
  *   Where brand new claims are being explored, a search of existing YANG objects could be done.  Adoption on YANG definitions where possible would minimize downstream mapping.

Eric

From: Laurence Lundblade, June 7, 2019 2:53 PM

Hi Eric,

LL

Hi Hannes,

Eric

Ciao
Hannes

                                                       -- Mike

Below…

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 10 Jun 2019 11:57:13 -0700

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

> On Jun 7, 2019, at 1:31 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Laurence,
>  
> Network Elements would be capable of reading some subset of what is coming off of EAT capable hardware chips.
> Where brand new claims are being explored, a search of existing YANG objects could be done.  Adoption on YANG definitions where possible would minimize downstream mapping.
>  
> Eric
>  
> On Jun 7, 2019, at 10:14 AM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Hannes,
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 10 Jun 2019 21:23:53 +0000

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.

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.

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.

Eric

From: Laurence Lundblade, June 10, 2019 2:57 PM

Hi Eric,

LL

On Jun 7, 2019, at 1:31 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Eric

LL

Hi Hannes,

Eric

Ciao
Hannes

                                                       -- Mike

Below…

LL

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

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 11 Jun 2019 08:21:13 -0700

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.

> On Jun 10, 2019, at 2:23 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Laurence,
>  

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? 

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.

> 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 rou…

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. 

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

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.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 11 Jun 2019 21:03:28 +0000

Hi Laurence,

From: Laurence Lundblade, June 11, 2019 11:21 AM

Hi Eric,

<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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

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

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

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

<eric>  I encourage other YANG viewers out there to chime in as well.

Eric

LL

Eric

Hi Eric,

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Jun 2019 10:18:10 -0700

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) <[email-masked]> wrote:
> 
> Hi Laurence,
>  
> On Jun 10, 2019, at 2:23 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Laurence,
>  
> 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>
> https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/16101 <https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/16101>