Re: [Rats] Call for Adoption: EAT draft

[Giridhar Mandyam <[e-mail]>]

> 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]>
Sent: Tuesday, May 28, 2019 12:54 PM
To: Eric Voit (evoit) <[e-mail]>
Cc: Giridhar Mandyam <[e-mail]>; [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