Last Call Review of draft-ietf-rats-eat-13
review-ietf-rats-eat-13-secdir-lc-orman-2022-07-23-00

	 Security review of The Entity Attestation Token (EAT)
    	              draft-ietf-rats-eat-13

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This document describes the encoding of tokens holding data about "an
entity, a device, some software and/or some hardware."  The data are
called "claims".  The claims are for "authenticating, identifying and
characterizing implementations where implementations are devices,
chips, hardware, software and such."  In the provided examples, the
claims are generally relevant to the security status of an entity.

In short, the document says that an entity may make security claims
about itself, another entity can sign those claims (and others that it
cares to tack on), and a third entity can then verify the signature
and assume that the claims are correct.  It is difficult to fathom the
expected use environment, though.  Why should the third party assume
that the signer is trustworthy?  Why is it trustworthy for evaluating
the claims of the first party?  What are the responsibilities of the
signer?  How does the relying party let the other parties know what
attributes it needs?  How are these trust relationships discovered,
maintained, updated, revoked, etc.?

In this scheme, devices, be they hardware of software, must have a
universal identifier installed by the manufacturer.  The draft notes
that this is a privacy problem and suggests several ways around it.  I
cannot determine if the identifier is a required "claim" or not.  The
only required claim that I saw was the nonce, but the UEID occurs in
all examples.

The document seems to imply that relying parties need a guarantee that
the UEID is unique.  There is an appendix that purports to calculate
the collision probability of the universal identifier string (UEID)
based on the number of bits.  The calculation only makes sense if the
UEIDs are chosen with uniform randomness.  This onus is apparently on
the entity manufacturer.  The probability of this being done correctly
is lower than the chance of a collision if it were done correctly.

There is a "claim" that occurs frequently in the examples that has the
name "security level".  The document notes that it has no clear
meaning, but it has three possible values (which are not "low",
"medium", and "high").  There really should be a different name for
this, something like "special defenses" or "vague resistance
descriptor".

The document asserts that it defines "a network protocol for proving
trustworthiness to a Relying Party."  I'm not sure that it is a
protocol (and it does not "prove" trustworthiness).  It seems to be
only a format for describing some particular attributes that may or
may not be relevant to trusting a device.

The first example, Simple TEE Attestation, has a typo of "manfests"
for "manifests".