Re: [Rats] Call for Adoption: EAT draft

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

Hi Giri,

I like where this is going.  Are you willing to add text into this draft defining:
(a) some principles/guidance to CWT claims registry people on avoiding the mass registration of lightly-used or unused claims
(b) a requirement to map claims to existing YANG objects, if these YANG objects exist

Eric

From: Giridhar Mandyam, May 28, 2019 6:58 PM

> If the number of claims stays in the 10's, I think your proposal will work fine.   But what if the scale is more?
…
> So with the current open-ended scoping of the domain of possible claims, would it be possible for any of these thousands of YANG objects to  being asserted by a device as a claim?  And would we have a way of explicitly defining the relationship/mapping between that claim and a corresponding YANG object?

Is your assumption that there could be thousands of registered YANG claims that extend the CWT registry?  For a claim being proposed for the registry, expert review is supposed to take into account the corresponding claim specification (which should document the relationship/mapping between a claim and a YANG object).  Writing a specification that would pass expert review should (in theory) be a high enough barrier to prevent mass registration of lightly-used or unused claims.

For unregistered claims - we cannot really stop implementations in the wild from using them.  I am not sure we would want to stop use of unregistered claims anyways as it could allow for pre-registration validation of any proposed claims.

Granted – I am putting a lot of faith in expert review for the CWT claims registry.  But I know that some of the designated CWT claims registry expert reviewers are reading this list and are quite diligent in carrying out their responsibilities.

-Giri

From: Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 28, 2019 2:27 PM
To: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>; Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Rats] Call for Adoption: EAT draft


CAUTION: This email originated from outside of the organization.
Taking a look at the CWT Claims from:
https://www.iana.org/assignments/cwt/cwt.xhtml
there are less than 10 claim defined currently.  And some of these appear as if they are not specified to allow interoperation. E.g., from RFC7519 #4.1.3, the audience claim passes "values is generally application specific".

If the number of claims stays in the 10's, I think your proposal will work fine.   But what if the scale is more?

When I look at what is going on with YANG right now, I see many thousands of objects.  The administrative effort involved with understanding the semantic bindings between these objects consumes multiple Working Groups' time.

So with the current open-ended scoping of the domain of possible claims, would it be possible for any of these thousands of YANG objects to  being asserted by a device as a claim?  And would we have a way of explicitly defining the relationship/mapping between that claim and a corresponding YANG object?

I do like EAT.  I think it is useful.  I just want to avoid the creation/assignment of new, parallel universe of managed object definitions.  And I especially want to avoid undefined mappings between the two.  It would be great for the draft to explore how to minimize such complexities.

Eric


From: Giridhar Mandyam, May 28, 2019 4:37 PM
> There is a CWT claims registry, so if you want to be sure no one collides with your, register them. (Looks like EAT didn’t say this explicitly, but that is the intent. Anyone can add any claim. All claims are optional. This is just like CWT).


Clarification:  The EAT draft didn’t need to state the above, as EAT is making use of the existing CWT registry.  Each claim submitted to the CWT registry will undergo expert review – see https://tools.ietf.org/html/rfc8392#section-9.1.  The designated experts should verify that not only claim ID’s in a submitted registration are not overlapping with existing entries, but they should also determine “whether the proposed registration duplicates existing functionality”.



-Giri


From: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 28, 2019 12:54 PM
To: Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>
Cc: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] Call for Adoption: EAT draft


CAUTION: This email originated from outside of the organization.
Hi Eric,

CWT says it in the start of section 3 of RFC 8932: “…all claims that are not understood by implementations MUST be ignored.” So anyone can add any claims. There is a CWT claims registry, so if you want to be sure no one collides with your, register them. (Looks like EAT didn’t say this explicitly, but that is the intent. Anyone can add any claim. All claims are optional. This is just like CWT).

It quite the intention that a token can be generated on a general purpose CPU. However the idea is to mark it as such so the receiver knows. Of course, if a token in generated on a special security-oriented CPU, it will be signed there and the general purpose CPU will just be a middle man that can’t change it.

I foresee the work we do here as a general frame up for EAT including the definition of a lot of common and useful claims.  Then individual applications and use case and such will define profiles that say what claims are allowed or disallowed. The ARM PSA document is more-of-less an example of that. FIDO is interested in workin on a profile. I expect Global Platform to define a TEE-oriented profile.

LL




On May 28, 2019, at 11:19 AM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Giridhar,

I expect we will want to expand the claims over time.  Based on that, what are the limits to what can plausibly be populated as an EAT claim?

This is an important question at adoption time.  One of the things I like about Section 3 (everything but section 3.4) is that all the proposed claims are very specific/well defined.   And also importantly, each of these claims feel to be something which could plausibly be supported and signed within a hardware chip.  This is goodness.

However Section 3.4 defines "unrestricted" security environments which provide "no meaningful security assurances".    I can see why this might feel interesting: it provides flexibility for future use/applicability of EAT anywhere.  But a downside is that this could be read to mean that a general purpose CPU could add their own Claim types and then sign them.

Initially that seems like this flexibility would be ok.  But there are lots of protocols in the Internet.  And  I expect each of those protocols would want to maintain an explicit the list of attributes which might be passed on top.    So if those protocols are to someday carry EAT information, it would be good to define the universe of what might conceivably be carried within.  Without this, there could be unnecessary fights on who owns the purview of various nested protocol objects.

Eric

From: Giridhar Mandyam, May 28, 2019 10:24 AM
Sorry for the failure to respond.

Yes, your assessment is correct.  A custom claim can be created to carry the entire TPM attestation as a payload, similar to what is done in FIDO/Webauthn where the TPM relevant fields are included in a CBOR structure – see https://w3c.github.io/webauthn/#sctn-tpm-attestation.

Note that we would like to include claims into EAT that would cover measured boot.  There is no reason that entries in a PCR map couldn’t be represented as individual COSE structures (assuming the COSE algm. registry is consistent with the TPM specifications).  If so, then each measurement can nested within an EAT.

-Giri Mandyam

From: Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 28, 2019 7:09 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Rats] Call for Adoption: EAT draft

CAUTION: This email originated from outside of the organization.
Resending a question to the authors...   (It looks like it got skipped during the blizzard of emails on JWT/CWT)

Eric

From: RATS <[e-mail]<mailto:[e-mail]>> On Behalf Of Eric Voit (evoit)
Sent: Wednesday, May 22, 2019 1:53 PM
I like the draft, but there is one thing I would like to hear from the authors before answering the poll.

This YANG model is exposed by software on a networking device like a router.  The router can examine information from local cryptoprocessors such as a TPM.

In looking at the proposed YANG model (draft-birkholz-rats-basic-yang-module), the tpms-attest-result structure from this YANG model can contain the raw result from a TPM.  This to me seems to be a binary blob which could also carry CBOR encoded EAT claims.  Do you agree with this assessment?

Eric

From: RATS <[e-mail]<mailto:[e-mail]>> On Behalf Of Kathleen Moriarty
Sent: Friday, May 10, 2019 11:07 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Rats] Call for Adoption: EAT draft

Greetings!

At IETF 104, a poll was taken to determine interest in the RATS WG adopting:

The Entity Attestation Token (EAT)
https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/

This begins a 2 week period to determine interest in adopting this draft as a working group item.  The poll will close on May 24th EOD PDT.

Minutes from IETF 104:
https://datatracker.ietf.org/doc/minutes-104-rats/
--

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