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

[Henk Birkholz <[e-mail]>]

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

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"?

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?

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