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

[Daniel Migault <[e-mail]>]

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.

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


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


> 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