On 06.12.23 23:58, Daniel Migault wrote:
>
>
> On Fri, Dec 1, 2023 at 5:36 PM Henk Birkholz <[e-mail]> wrote:
>
> Hi Hannes,
>
> jumping directly to your questions!
>
> 1.) The term nonce was not renamed. The extra-data value used in
> challenge-response interactions (used both as proof of freshness and
> proof of recentness at the same time) is a nonce, yes. But at the same
> in other interaction models, the extra-data value is used by multiple
> entities at the same time: it cannot technically be a nonce, but would
> be an implementation of the EpochID concept. To be uniform across all
> interaction models in this I-D, in early stages the auhtors decided to
> use a "superset-term" for both nonce and EpochID. Please note that
> EpochID also is a name for a conceptual information element and not an
> implementation name, such as nonce.
>
> Maybe the definition of handle should be clearer: handle is a superset
> of specific extra-data that typically is a nonce and or some
> implementation of EpochID (e.g., Epoch Markers).
>
>
> I agree with Hannes that I also wondered why "handle" was used in the
> challenge response model. It probably helps to clarify why you called it a
> handle.

TL;DR: Proposal to re-label "handle" to "qualifying data" for challenge-response based remote attestation and "sync token" for streaming remote attestation?

I am not a native speaker and I am fine with renaming "handle" it to whatever makes sense. However, please keep in mind that this "handle" may not always be a nonce in the classical sense. In the TPM 1.2 context it is called "external data" (cf. https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf#page=174) of type TPM_NONCE and the descriptive text "160 bits of externally supplied data (typically a nonce provided by a server to prevent replay-attacks)". This demonstrates the typical usage as nonce, but it is not limited to it. In TPM 2.0, it is called "qualifying data" of type TPM2B_DATA with the descriptive text "data supplied by the caller" (cf. https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part3_Commands_pub.pdf#page=167), which suggests it can be different from a nonce.

To stay with the TPM-scoped example, TPM2 quotes include TPM clock info which in some cases may be sufficient to provide freshness and recentness (cf. https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part2_Structures_pub.pdf#page=134). In TUDA and streaming remote attestation, the unique value for freshness and recentness is the time information provided by the TPM. In TPM 1.2, there is no time/clock information as part of a quote, but it can be combined with TPM_TickStampBlob calls to achieve the same thing (cf. https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf#page=250), just for for more context on how many types of data can be included in these scenarios.

In summary, would "qualifying data" (instead of "handle") as suggested by the TCG's TPM 2.0 specification mentioned above be a better name candidate for that concept? This should work for, e.g., Intel SGX and Arm TrustZone based attestations, too. For the streaming remote attestation part, we would then also need an alternative to "handle". The TUDA term here is "Sync Token" which provides proof that the TPM's internal clock (local time) was synchronized with an external clock (system-global time) provided by the Time Stamp Authority (TSA) (cf. https://www.ietf.org/archive/id/draft-birkholz-rats-tuda-07.html#section-7). MAybe we should fall back to Epoch ID as described in RFC9334?

>
>
> 2.) The availability of the "knowledge of Claims to ask for" is pretty
> usage scenario specific. In your assumption, that knowledge is unlikely
> to be available, but that it not true for all usage scenarios.
> https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-08.html#section-7.1
> highlights that Claim Selection is not a mandatory thing.
>
> Maybe omission of Claim Selection should result in "an Attester's
> choice" (e.g., per-configured) of Claims to include in Evidence - in
> contrast to the current "by default all Claims that are known and
> available on the Attester MUST be used"?
>
>
> I think what matters is that we know it is either known or agreed.

We are not sure if this is true for all cases, but sounds pretty feasable. For example, with CoMID (and CoRIM) it is possible to learn how to request attestation Evidence from systems and how this Evidence is appraised, based on a description received or asked for. This would probably result in an additional (optional) step preceding the actual request to provide attestation Evidence. So, "known or agreed" would still fit. Kindly note that appraisal procedures are out of scope for this document, we focus on Conceptual Message conveyance.

> I also think that "=>" could be clarified, unless I missed it. I interpret
> them as the output of the function. If that is correct, I found a = f(x)
> a more common notation than f(x) => a. Happy to learn if there is any
> reasons to use the latter ?

The sequence diagrams shown here are more or less "lightweight" UML sequence diagrams. UML sequence diagrams would take up too much space in ASCII art and exceed the line length (see https://www.plantuml.com/plantuml/uml/VL5BQWCn3Dtx55ecCBb0wPI4D9H2LmraBpnAOl38KriszFRrsFbW6EgbtaTFpziWw2MELc4KXrfCGY5mhAOyDzfCo08x4Gf27Z00DiY9l3bN82dLzt18PY3M11_4v56COq0UOEyuqI_EIDyhXR1v0uGNk5GQxIsQCQomR39yEN0otl58B6lbIQ9dq8NJ0QKy_NANCFkyRY1b7qy_CIjhqh9sTSrxBNM0KQv7qf_leQiMHxAaPyfQASZl4KOxEoEtB8Mxe9abzqHLG4ELFEpQs-wTB2TgBHfxkWcRa__1cW_OJPD74z2MmbCELOh2Edw6MZ3gmDFvX3PIU9IFpsQ_AKGhQaiynD7-0G00).

In UML sequence diagrams, there are messages and calls that include return values, so they are not functions per se, but can be (similar to) functions. We have therefore decided to use "=>" for return values (or what would be even better for aasvg: "==>"). Do you have any suggestion in mind that we can realize in the I-D to address the issue better?

>
>
>
> 3.) The availability of the "knowledge about authentication secret
> ids" is also pretty usage scenario specific. In your assumption, that
> knowledge is unlikely to be available, but that again is not true for
> all usage scenarios.
>
> Having said that, "Attestation Key ID" is way more precise and we agree
> that it is a much better term. There are of course scenarios where
> multiple Attesting Environments with individual Attestation Key IDs
> exist (see
> https://www.rfc-editor.org/rfc/rfc9334.html#name-composite-device).
>
> What the I-D is currently lacking is better support for usage scenarios
> where the Attestation Key ID is/are unknown. In these cases, available
> Attestation Key IDs could be requested alongside potential Endorsements
> cached by the Attester. Alas, simply requesting Attestation Key IDs from
> Attesters without any kind of authentication seems to open a few attack
> vector, such as linkability or tractability, right?
>
> I agree this was also confusing to me. I also tend to think of it as an (attesting
> environment) instance ID. key_id sounds very much like the hash of a key in
> which case you need to have the key. I do not think you necessarily need to
> have the knowledge of that key. Typically, you could use an id (like an
> uuid) to which an automatically generated is associated. I am wondering if I
> am missing anything or if there are any reasons this would not work ?

In the end, Evidence is signed by some cryptographic key (asymmetric or symmetric, excluding the conveyance of UCCS via Secure Channels). An Attesting Environment can have multiple keys to sign Evidence. In a TPM, keys can be restricted to sign particular PCRs, e.g., one key that signs PCRs 0-7 and another key that is allowed to sign PCRs 8-11. We called it Attestation Key ID because there are many ways to identify a key. This can be the fingerprint of a key (typically the hash of the public portion), a custom internal identifier, a TPM key handle (transient; valid as long as the key is loaded), or other (more) persistent identifiers, such as TPM Feature API (FAPI) key paths (e.g., "HS/SRK/myAttestationKey").

We agree with Hannes that we need support for scenarios where the attestation key is unknown. In appendix A, we have the "hello" element ("if true, the TPM 2.0 AK Cert shall be conveyed") in the CDDL which serves exactly that pupose (https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-08.html#appendix-A). We agree that it should be described somewhere in the I-D in more depth. There may be some kind of Attestation Key ID discovery protocol, but we would consider any more concrete description for this out of scope for this document.

>
>
> Maybe we should add corresponding text to the SecConSec?
>
> @Hannes, based on the outcome of this thread, if you could provide us
> with proposals in the form of PRs that would be great!
>
>
> Viele Grüße,
>
> Henk for all editors
>
> On 29.11.23 17:45, Tschofenig, Hannes wrote:
> > Hi all,
> >
> > I have read through <draft-ietf-rats-reference-interaction-models> and
> > have a few questions.
> >
> > At the core, the document tries to define information elements that are
> > supposed to be used by a Verifier to ask an Attester for Evidence.
> >
> > In the request from the Verifier to the Attester, the following
> > information elements are mandatory:
> >
> > * Authentication secret ids
> > * Handle
> > * Claim Selection
> >
> > None of these terms are defined in the RATS architecture document. The
> > claim selection is supposed to give the Verifier a chance to tell the
> > Attester what claims to return in the Evidence. The Handle corresponds
> > to the freshness mechanism used (such as a nonce) and the authentication
> > secret id allows the Verifier to tell the Attester what keys to use to
> > sign the Evidence.
> >
> > A couple of questions arise:
> >
> > 1. Why has the nonce term been renamed to handle?
> >
> > 2. How should the Verifier know what Claims to ask for given that it is
> > not likely to know what attestation technology the Verifier
> > supports? The model assumes that the Attester is so flexible to
> > report a subset of the claims and the Verifier also needs to be
> > flexible to know that a certain subset of claims make sense from a
> > processing point of view. Is flexibility really a good approach here?
> >
> > 3. How does the Verifier know what values for the authentication secret
> > ids to convey to the Attester given that it is not likely to know
> > upfront what attestation keys the attester will have stored? Do you
> > expect the Attester to have many different Attestation Keys to
> > choose from? Why is the term “Authentication Secret ID” used instead
> > of “Attestation Key ID” or something along those lines?
> >
> > The authors seem to make a number of assumptions that need further
> > explanation.
> >
> > Ciao
> >
> > Hannes
> >
> >
> > _______________________________________________
> > RATS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rats
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
>
>
> --
> Daniel Migault
> Ericsson
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats

# Alte Mail

Hi Hannes,

jumping directly to your questions!

1.) The term nonce was not renamed. The extra-data value used in challange-response interactions (used both as proof of freshness and proof of recentness at the same time) is a nonce, yes. But as the same extra-data value that is used by multiple entities at the same time, it cannot technically be a nonce, but would be an EpochID. To be uniform across all interaction models in this I-D, we decided to use a "superset-term" for both nonce and EpochID. Please note that EpochID also is a name for a conceptual information element and not an implementation name, such as nonce.

Maybe the defintion of handle should be clearer: handle is a superset of specific extra-data that typcically is a nonce and or some type of EpochID.

2.) The availablilty of the "knowledge of Claims to ask for" is pretty usage scenario specific. In your assumption, that knowledge is unlikely to be available, but that it not true for als usage scenarios. https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-08.html#section-7.1 highlights that Claim Selection is not a mandatory thing.

Maybe omission of Claim Selection should result in "an Attester's choice" (e.g., pre-configured) of Claims to inculde in Evidence - in contrast to the currrent "by default all Claims that are known and available on the Attester MUST be used"?

3.) The availablilty of the "knowledge about authentication secret
ids" is also pretty usage scenario specific. In your assumption, that knowledge is unlikely to be available, but that again is not true for all usage scenarios.

Having said that, "Attestation Key ID" is way more precise and we agree that is a much better term. There are of scenarios where multiple Attesting Environments with individual Attestation Key IDs exist (see https://www.rfc-editor.org/rfc/rfc9334.html#name-composite-device).

What the I-D is currently lacking is better support for usage scenarios where the Attestation Key ID is unknown. In these cases, available Attestation Key IDs could be requested alongside potential Endorsements cached by the Attester. Simply requesting Attestation Key IDs from Attesters without any kind of authentication seems to open a few attack vector, such as linkability or tracablilty, right?

Maybe we should add corresponding text to the SecConSec?

Viele Grüße,

Michael & Henk

On 29.11.23 17:45, Tschofenig, Hannes wrote:
> Hi all,
>
> I have read through <draft-ietf-rats-reference-interaction-models> and
> have a few questions.
>
> At the core, the document tries to define information elements that are
> supposed to be used by a Verifier to ask an Attester for Evidence.
>
> In the request from the Verifier to the Attester, the following
> information elements are mandatory:
>
> * Authentication secret ids
> * Handle
> * Claim Selection
>
> None of these terms are defined in the RATS architecture document. The
> claim selection is supposed to give the Verifier a chance to tell the
> Attester what claims to return in the Evidence. The Handle corresponds
> to the freshness mechanism used (such as a nonce) and the authentication
> secret id allows the Verifier to tell the Attester what keys to use to
> sign the Evidence.
>
> A couple of questions arise:
>
> 1. Why has the nonce term been renamed to handle?
>
> 2. How should the Verifier know what Claims to ask for given that it is
> not likely to know what attestation technology the Verifier
> supports? The model assumes that the Attester is so flexible to
> report a subset of the claims and the Verifier also needs to be
> flexible to know that a certain subset of claims make sense from a
> processing point of view. Is flexibility really a good approach here?
>
> 3. How does the Verifier know what values for the authentication secret
> ids to convey to the Attester given that it is not likely to know
> upfront what attestation keys the attester will have stored? Do you
> expect the Attester to have many different Attestation Keys to
> choose from? Why is the term “Authentication Secret ID” used instead
> of “Attestation Key ID” or something along those lines?
>
> The authors seem to make a number of assumptions that need further
> explanation.
>
> Ciao
>
> Hannes