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

[Giridhar Mandyam <[e-mail]>]

>* 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)

OK.  Currently Sec. 1.3 defines 3 actors (entity/manufacturer/RP) and architecture doc defines 4 (attester/claimant/verifier/RP).  In the EAT doc the RP can be the verifier or rely on a verification service.  However, I am not convinced that entity = attester and claimant = manufacturer.  This could be something for discussion in the F2F.

>* The need for profiling EAT to make it work in reality is pretty obvious …

Agreed.  A key attestation profile could be another example.

>  * "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.

Filed https://github.com/ietf-rats-wg/eat/issues/19, but I am not sure how ephemeral keys can provide the same level of assurance as manufacturer-issued key material unless the environment in which the key is generated can also be attested.  Rather than simply removing the sentence, perhaps we can add something along the lines as:

“The EAT SHOULD be signed by the attestation key material provisioned by the manufacturer.  The EAT may be signed by dynamically-generated keys, but this key material itself may require its own attestation to achieve the same level of assurance as manufacturer-provided key material.”

>  * "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:
…
> "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."

Agreed that interop is aided by limiting the set of singing algorithms.  However, we have a COSE algm. registry (https://www.iana.org/assignments/cose/cose.xhtml) that bounds the set of algorithms that can be used for EAT.  It seems also that any ensuing profiles would leverage the registry.  Some defined profiles may mandate a subset of the registry, but some may allow any algm.’s in the registry to be used.  “will mandate” seems to be too strong a statement.

>  * "It also mentions several claims defined by CWT and JWT are  particularly important for EAT."
> Typo: "[...] that are particularly important [...]"

Filed a typo’s issue in the GH repo - https://github.com/ietf-rats-wg/eat/issues/20.  Will pick up fixes in a future version. Thanks.

>  * "All claims are optional * No claims are mandatory"
>Either one or the other is redundant?

OK.

>  * "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.

This can be softened to a SHOULD requirement.  Note that an issue has been filed at https://github.com/ietf-rats-wg/eat/issues/18 to better define verification procedures.

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

I agree that the statement above needs clarification, but the above statement is about transport security – it is not about all security considerations associated with challenges.  An RP should not rely on transport security alone for protection of the nonce.  It should be tracking the nonce sent to the device, and verifying the response accordingly.  One possibility is to remove the above statement, but add a discussion on the uses of nonces in the Security Considerations section (which is still a work-in-progress).

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

Agreed that the choice of rand gen and seed affects this.  I think it should be taken up in a security considerations section.  Added an issue - https://github.com/ietf-rats-wg/eat/issues/21.

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

I look forward to discussing this topic at the F2F.  There is an issue filed – see https://github.com/ietf-rats-wg/eat/issues/4.  However, this issue is not about a generic certification container.  Can you provide a proposal?

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

Note that this claim set was created based on what the editors understood about lifecycle based on our employer’s products (Qualcomm) and on what we were able to survey from other manufacturers.  I don’t think we will have a consistent view among vendors about how to best express the device state lifecycle in claim information.  This is why follow-on proposals such as the PSA profile are important.

Nevertheless, the differences between different debug disable states should be better highlighted in the text and how the claim values should be set by the attester.  For instance, if the attester sets debug full permanent disable, then it should not set the other debug disable states.  This can be addressed within CDDL itself using the choices option – see Sec. 2.2.2 of RFC 8610.  I have filed an issue - https://github.com/ietf-rats-wg/eat/issues/22.


>## 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).

There is an issue filed - https://github.com/ietf-rats-wg/eat/issues/13.  However, I think if we are going to address privacy in the context of attestation then we should not just fixate on location but address all aspects of attestation that could result in device fingerprinting/tracking.  As an example - the Webauthn spec attempts to describe privacy implications related to attestation in general - https://www.w3.org/TR/webauthn/#sec-attestation-privacy.

Moreover, in some ways, location is unusual in that there already exists a permissions framework by which the end user can manage privacy (e.g. seehttps://www.w3.org/TR/webauthn/#browser-permissions-framework-extensions for a discussion on browser permissions impacts).  There may not be a similar permissions framework for other claims in the attestation token, which means that the ability for the end user to manage privacy with respect to such claims may not be readily available.

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


This claim is meant to cover the time lapsed between when the claim info was provided and when the token was created.  Would the following text make it more clear:  “The "age" claim contains a value that represents the number of seconds that have elapsed between when the claim information (e.g. measurement, location) was obtained and when the token was created.”

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

Added to typos issue.

>  * "The contents of the "eat" claim"
> Typo: "nested_eat"

Added to typos issue.

>* "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.

If a verification procedures section is added, this seems to appropriate guidance to add.

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

Noted.


From: RATS <[e-mail]> On Behalf Of Thomas Fossati
Sent: Friday, July 12, 2019 7:33 AM
To: [e-mail]
Cc: Simon Frost <[e-mail]>; Thomas Fossati <[e-mail]>
Subject: [Rats] Review of draft-ietf-rats-eat-01


CAUTION: This email originated from outside of the organization.
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 hto
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.