[Rats] Review of draft-ietf-rats-eat-01

[Thomas Fossati <[e-mail]>]

Hi,

We did a quick pass over the latest EAT draft (-01) and amassed a few
comments (see below).  Thanks for all the good work you put into the
document!

Cheers, Thomas & Simon

# High level

* At a certain point we should probably do a pass to harmonise the
  terminology between the architecture draft and EAT (section 1.3 in
  particular):
  * basic concepts & vocabulary: e.g., RoT definition;
  * protocol roles & responsibilities.

* The need for profiling EAT to make it work in reality is pretty
  obvious when you think about the considerable number or things that
  one needs to state to achieve interop, e.g.:
  * Signing scheme
  * Transport
  * Supported claims
  * Type of UEID
  * Security level / certification scheme
  So it seem that having the "profile" concept, and an associated
  identifying claim -- for example, in PSA [1] we use arm_psa_profile_id
  -- defined as part of this doc would be beneficial.

[1] https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-02#section-3

# Detailed

## S1.3

  * "This attestation key material is used for signing EATs."
  * "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.

## S1.4.2

  * "No particular signing algorithm or signing scheme is required by
    this standard."

Isn't this a basic interop concern?  Is a EAT verifier supposed to
implement every possible signing/verification algorithm?
If we want to keep the above as-is, I think the following:

  "Over time to facilitate interoperability, some signing schemes may be
  defined in EAT profiles or other documents either in the IETF or
  outside."

Should say instead something like:

  "It is expected that EAT profiles or other specs building on EAT,
  either in the IETF or outside, will *mandate* a set of applicable
  signing schemes."

## S3

  * "It also mentions several claims defined by CWT and JWT are
    particularly important for EAT."

Typo: "[...] that are particularly important [...]"

  * "All claims are optional * No claims are mandatory"

Either one or the other is redundant?

  * "All claims that are not understood by implementations MUST be
    ignored"

While this is generally the right approach to support evolution, I'd
avoid making this a requirement here and let EAT profiles decide for
themselves instead.

## S3.1

  * "Note that intrinsically by the nature of a nonce no security is
    needed for its transport"

Not sure about the above: what about avoiding confusing the principals,
and/or reordering of messages from one principal?  In fact, it seems
it's exactly the opposite and that some security considerations would be
in order.  That, or dropping the sentence altogether.

## S3.3.

  * "No two products anywhere, even in completely different industries
    made by two different manufacturers in two different countries
    should have the same UEID"

Not sure how this assertion is compatible with type RAND UEIDs which –
unlike the other types – are constrained only by a local choice (e.g., a
"good enough" random generator) and not by any governance regime.

## S3.6

Security level is a certification-like claim except it's not backed by a
3rd party certification entity.  And even though the proposed 4 levels
look somewhat reasonable, I wonder what the benefits of having this
claim are?  ISTM that self-proclaiming sec levels adds nothing at best,
whilst altering the security perception in the worst case.  That said,
I'd not be against defining a generic "certification" container that can
be specialised by the specific EAT profile according to an existing or
future scheme, but that would be a pretty different thing from this.

## S3.7

I'm pretty sure we want to have something like this, but I'm not sure
the current definition is good enough.  Would this be better as a single
value with 4 states?

One problem with the current proposal is that "debug permanent disable"
implies "debug disable" but they can be set independently and therefore
inconsistently.

## S3.8

This needs some privacy considerations, in particular explaining the
interaction with UEID (the combo location & stable identity correlator
is pretty explosive.)  There is probably lots to be extracted from
previous GEOPRIV work (see, e.g., RFC6280).

## S3.9

  * "Seconds since the token was created"

I assume the "token creation" happens when the signature is applied?  If
so, I don't understand how can this information be sealed in the token
with a value different from 0.  If instead the age is "per-claim", then
a single global value is clearly insufficient.  Alternatively, if it has
"per-profile" semantics (e.g., "time since boot measurements taken"),
then this again can't be global, as it'd have profile-specific semantics.

## S3.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.”

Maybe s/Typically/For example/ : this is not necessarily the typical
case.

  * "The contents of the "eat" claim"

Typo: "nested_eat"

  * "It is either a full CWT or JWT including the COSE or JOSE signing."

Maybe worth a hint to dispatch it to the right decoder to avoid trial &
error and/or content-type snooping.

## S6

As already noted, this needs at least discussion around the location claim.

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.