Re: [Rats] Vetting claim definitions

[Laurence Lundblade <[e-mail]>]

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) <[e-mail]> wrote:
> 
> 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,
>  
> 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) <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 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
> 
> 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Mike Jones
> Sent: Mittwoch, 5. Juni 2019 19:31
> To: Laurence Lundblade <[e-mail] <mailto:[e-mail]>>; Michael Richardson <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [Rats] Vetting claim definitions
>  
> 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
>    after a three-week review period on the [e-mail] <mailto:[e-mail]>
>    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 <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, June 5, 2019 8:46 AM
> To: Michael Richardson <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Mike Jones <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Rats] Vetting claim definitions
>  
> Below…
> + Mike Jones, co-author of CWT
>  
> 
> On Jun 5, 2019, at 6:05 AM, Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 
> Laurence Lundblade <[e-mail] <mailto:[e-mail]>> 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 :-)
>  
> 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
>  
> 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.
>  
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>