Re: [Rats] Review of <draft-ietf-rats-reference-interaction-models>

[Michael Eckel <[e-mail]>]

Hi Daniel,

Thank you very much for your comments. Please find our response inline.

Thanks,
Michael

Fraunhofer SIT
*Michael Eckel*
Deputy Head of Department | Cybersecurity Researcher
🏭 Cyber-physical Systems Security & Automotive Security
📧 [e-mail]
🕿 [phone] <tel:[phone]>

🏢 Fraunhofer Institute for Secure Information Technology SIT
🏠 Rheinstraße 75, 64295 Darmstadt, Germany
🌍 sit.fraunhofer.de <https://sit.fraunhofer.de/>

Member of ATHENE <https://www.athene-center.de/>

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 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 RFC 9334?

>
>> 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 uncertain if this is true for all cases, but sounds pretty 
feasible. 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 produce 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 purpose 
(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
>>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats