ietf-rats-wg / eat Goto Github PK

The CBOR interoperability section should have RFC2119/8174 language where needed. Please also double check that there are no copy-pasted requirements from other documents without an explicit ref -- e.g., the stray "Duplicate map keys are not allowed." should have a ref to 7049.

The claim would list SW on the entity. It would probably include name the name and version of each SW component. This is probably a complicated claim to define.

See also issue #31

This might include a signer ID like https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-02 does

RIV uses IDevID which has a manufacturer and serial number. If this goes into attestation result then maybe it should be expressible in EAT.

Ben commented that 128 bits is not enough. Is my analysis correct?

128 bits (16 bytes) is enough for one trillion humans to each have one trillion devices and the probability of collision less than a trillion (log base 10 of 2^ 128 = 38; log base 10 of a trillion is 12; 3 * 12 < 38) So 128 bits seems like enough, but take it out to 256 bits because SHA-256 is popular and good and there is some extra margin.

Consider making an EAT a "CWT Claims Set" as defined in CWT (and JWT) to accommodate GP's desired for unsigned tokens.

See https://tools.ietf.org/html/draft-mandyam-rats-qwestoken-00#section-3.3

An optional context claim can provide information on intended usage to the recipient of the attestation token.

EAT is used to convey claims from the entity / device to the verifier, but it can also be used to convey the output of the verifier to the relying party.

For example, the input to the verifier may be software measurements. The output of the verifier might be a Boolean that the measurements were correct.

Also, some implicit claims might be made explicit. For example, if the verifier knows that the device will never send an attestation is the boot and debug state are not locked down, then the verifier can add those claims.

In section 1.2, it seems odd that the definition of the term "entity" is limited to things that implement this draft. The last sentence of this section and the definition of "The Entity" in section 1.3 bear this out. Generally, 'entity' is used pretty loosely throughout the draft.

Section 5 contains guidance on the registration of EAT claims using the CWT registry. There should be suggested guidance to the expert reviewers to avoid registration of claims intended to be used in EAT that will not achieve widespread adoption.

See https://mailarchive.ietf.org/arch/msg/rats/jBCYPK2hly554HGYTXZXa2t_AGw.

The JSON story is nearly OK, except for two things:

• the Submods claim where the JSON:CBOR equivalency is broken by allowing unbounded
  int keys in CBOR that can't have an equivalent in JSON;
• the StringOrURI type whose semantics can’t be preserved when transcoding.

(Possibly the former could be addressed by only allowing string labels, the latter by declaring we only deal with strings.)

Some comments so far in my reading (which is not yet complete):

The Manufacturer. The company that made the entity. This may be a
chip vendor, a circuit board module vendor or a vendor of finished
consumer products.

Given that it may be three (or more) entities, and they each have different
agendas, I think that it might be worth being specific about each level.

In this case the manufacturer should
perform the verification, because any release of the key material
would enable a participant other than the entity to create valid
signed EATs.

s/manufacturer should/manufacturer MUST/

See seclevel discussion in mail list archive: https://mailarchive.ietf.org/arch/browse/eat/

Sec. 2.2.2 of RFC 8610 allows for a choice expression based on a '/' delimiter between options. In order to avoid expression of potentially conflicting debug disable states (e.g. debug full permanent disable being true while debug disabled since boot being false), this could be an alternative.

Sec.'s 3.7.3, 3.7.4 and 3.7.5 start out with the term "this claim". These are actually not claims as per the definition in Sec. 3.7, but boolean values included in the boot_state claim.

Which CWT / JWT field is really the nonce?

The CDDL for CWT claims needs some adjusting: it’d allow only one CWT claim at a time in the EAT map.

Scaling up a bit, we should probably have a CDDL socket for EAT extensions in the top-level map - and exercise this extension point starting from CWT claims.

Right now, the second type of submod, the embedding of a full signed EAT token inside surrounding token is "direct".

I think it needs to be wrapped in a byte string to make it reasonable to implement. When decoding the surrounding token, the nested token will be returned as a byte string that can be easily passed to the COSE/CWT/EAT decoder as these will typically take a byte string as input.

If it is not a byte string, then you have to convince the CBOR decoder to return the CWT Tag as a byte string even though it is not a byte string or the same or related instance of the CBOR decoder used to decode the outside EAT must be used to decode the inside EAT.

No semantics would change. This is only for a practical consideration of the APIs used for decoding CBOR, COSE, CWT and EAT.

Clearly most part of the location claim are optional. For example you don't have to specify speed. Should latitude and longitude also be optional? Can you just specify altitude if you want to?

Guidance on verification procedures not covered in document. It is touched upon in Sec. 1.3, but not to the level described in comparable specifications (see https://www.w3.org/TR/webauthn/#defined-attestation-formats).

missing "="

There’s a typo in Section 4.3.1: the “nonce” label is missing.

Here are a couple of typographic thoughts about Debug Disable claim.

The "disable" in "Debug disable" looks redundant: it'd be better renaming it as just "Debug" or "Debug status”.

A bit more consistent wording wouldn’t hurt too. e.g.:

• "Not disabled" => “enabled” -- this, combined with the above suggestion, would move us from "debug disable not disabled" to a simpler to digest "debug enabled" :-)
• "Permanent disable" => "disabled permanently"
• "Full permanent disable" => "disabled fully and permanently"

https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-02 defines this in terms of EAN-13. This seems like a good thing to do.

This is possibly subsumed by issue 15. In section 1.2, why state "the attestation should be cryptographically verifiable by the EAT consumer"? Is the intent that some EAT consumers won't recognize the root of trust or that some EATs need not be cryptographically verifiable at all? If the former, maybe change from should to MUST and add qualifying words about root of trust for relying parties.

They can be addressed in a -02 version.

Sec. 3: Change ""It also mentions several claims defined by CWT and JWT are particularly important for EAT." to 'that are particularly important'

Sec. 3: Correct "* All claims are optional * No claims are mandatory *." Redundant.

Sec. 3.11: "Typically, one will be the device-wide EAT that is low to medium security and another from a Secure Element or similar that is high security.” Consider changing "Typically" to "For example".

Sec. 3.11: "The contents of the "eat" claim must be a fully signed, ...". "eat" claim should be "nested_eat" claim.

ietf-rats-wg/architecture#92 topic 3 has some points about EAT.

Topic 3: EAT. If accurate, I'd like to see a clear acknowledgement that the Verifier may need to act as an Attester for the Relying Party since I'd like to then see specifically how the IETF EAT specification covers this circumstance. In other words, for an EAT that represents an AttestationResult, would the Evidence for the Verifier be embedded or discovered? If embedded, how are submods distinguished for the Verifier's Evidence versus the AttestationResult's embedded claims, including nested EAT's?

(From David Wheeler)

What seems to be missing from the proposed structure is the ability to attach new key material into the EAT structure, with an attestation claim. The attestation claim can be that it was generated on the device, or generated inside the TEE and bound/sealed to the TEE. And perhaps even a purpose for the key material. A new attestation key, for example; or a special signing/authorization key for a particular application.

Many times, IMHO, it is useful to generate a new key that is attested in some way, and then future operations use that key. In fact, OTrP/TEEP has this implication, with the AIK keys for new installed Apps, but (IMO) it is not really that clearly spelled out, although I think the intention is clear.

Other attestation claims are also useful – the identity and cryptographic hash of the code of a particular TEE application; a DH public key to establish an encrypted channel; the set of root CA’s this TEE will trust; …

When should the CWT and COSE tags be used with an EAT?

RFC8392 doesn't say whether the URI tag #6.32 should or should not be used on the issuer, subject and audience claims. Without it the decoder would use a URI syntax matcher to decide between it being text or a URI.

The nbf, exp and iat claims in CWT are allowed to be floating point. EAT inherits from them.

Floating point is not universally supported by CPUs, particularly small ones for IoT. Even if the CPU supports it, the compiler and OS might not (I’ve seen this happen once).

I don’t think fractional seconds are of any value for these claims, so we are forcing EAT decoders to support this for no good reason. I’m not sure why CWT allowed floating point for these claims other than just inheriting from the CBOR epoch time format.

It is possible to use SW to decode a float and turn it into an integral value, but that is not fun to write and seems a waste.

I’d like to specify in EAT that floating point is not allowed for these claims.

(Separately, we do need floating point for GPS location, but that claim will be used much less frequently and it is a good reason for using floating point).

Need references to IEEE OUI and to fill in details

This claim would list measurements made on parts of the entity. Typically a measurement is a hash of some region. This may by SW component or it may be more of a run time integrity measuring memory images.

For TEE-based implementations, it is possible to evaluate the measurement on the device and only list the integrity status as a Boolean rather than a measurement.

See also issue #30

See https://mailarchive.ietf.org/arch/msg/rats/jBCYPK2hly554HGYTXZXa2t_AGw.

Future claims could be added that correspond directly to YANG objects (https://tools.ietf.org/html/rfc6020). There should be guidance in the document as to how such objects can be reflected in the CWT claims registry.

For CBOR claims, this could be as simple as providing a reference to https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/. It should be confirmed whether https://tools.ietf.org/html/rfc7951 is sufficient to address future JWT claims.

As per https://mailarchive.ietf.org/arch/msg/rats/d4GYkpwEMmh0VjD3Gmjd1h82Wpc -

"The EAT is always signed by the attestation key material provisioned by the manufacturer."
This seems to prevent nested_eat use cases (e.g., cloud workloads with container/VM entities) where the outer EAT is signed with an "ephemeral" attestation key associated with the instance that is itself attested by the inner EAT signed with the AKM. I suggest removing the sentence.

Profiles are very concrete, use case specific, documents that say which claims are mandatory and which are optional and other. For example there might be a profile for payments, one for automotive, one for a specific IoT industry and such. This claim would name the profile in use for this token, perhaps with a reference to its defining document.

This is used in https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-02

It would be good to have a clear example on how to carry a TPM-2 style PCR Quote in as an example of evidence carried by EAT.

Current text:

• All claims are optional
• No claims are mandatory
• All claims that are not understood by implementations MUST be ignored

•Should profiles be allowed to override this?
•Should there be text that says they can?
•How does this relate to JWT/CWT optionality?

If I wanted to expand the semantics of "Debug Disable" or "Security Level" with my own local semantics, how would I do that?

Should I create a new claim? Or could I extend the claim’s type? If the latter, how?

It’d be useful that the doc explicitly stated the rules of this game.

Re: https://tools.ietf.org/html/draft-ietf-rats-eat-03#appendix-A.2

'seclevel' is showing up in the example. Two issues:

a) seclevel is actually security-level in the current doc.

b) For a submod is not providing attestation info in the form of an (endorsed) EAT, is there any value in providing security-level? If it is there, what entity is performing the security level assessment?

Current text (-01) does not state assumptions on rand generation that would be necessary to minimize the probability of collisions from different manufacturers. This could be added to the Security Considerations section.

2 reasons:

a) Neither RFC 8392 (CWT) nor RFC 7519 (JWT) have operational models. Since EAT is derived from these specifications, it would be desirable to maintain consistency.

b) This topic is better covered in an architecture specification.

It isn't clear whether an key used for attestation is restricted to signing evidence that is controlled by a trusted environment. The risk of not having constraints is the key may be subject to a confused deputy attack where claims are presented as opaque data that then receive a signature and a verifier presumes the attester made the claims.

Should it be mandatory for EAT claims to reside within the security perimeter of a trusted environment such as a TEEP TEE / TEEP Agent?

This is a random value that is generated each time the entity boots.

https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-02 defines this.