Re: [Rats] Requesting a Nonce from a Verifier

Hi Hannes,

most of your replies are pretty well scoped. Please find responses in-line.

Viele Grüße,

Henk

On 03.03.24 12:35, hannes.tschofenig=40gmx.net@dmarc.ietf.org wrote:
> Hi Henk,
> 
> Thanks for your quick response. See my remarks below:
> 
> -----Original Message-----
> From: RATS <rats-bounces@ietf.org> On Behalf Of Henk Birkholz
> Sent: Dienstag, 27. Februar 2024 15:35
> To: rats@ietf.org
> Subject: Re: [Rats] Requesting a Nonce from a Verifier
> 
> Hi Hannes,
> 
> I am in a weird TZ offset, so just a quick reply.
> 
> On 27.02.24 15:18, hannes.tschofenig=40gmx.net@dmarc.ietf.org wrote:
>> Hi all,
>>
>> Hendrik and I have been working on an update of the CMP/EST
>> extensions, which allow an Attester to request a nonce via the Relying
>> Party (in the background check model). This “nonce draft”, see
>> draft-tschofenig-lamps-nonce-cmp-est, aims to provide freshness for
>> the CSR attestation draft (see draft-ietf-lamps-csr-attestation).
> 
> Why focus on a nonce for a combination of recentness and freshness, when you could also use an epoch marker?
> 
> [Hannes] Nonces are a popular technique used by attestation technologies, which we have to support.
> Anyone can write another draft that uses epoch markers or timestamps to offer freshness for CSRs.

Yes, it is a well-known word with a few well-understood mechanism behind 
it. See (bar) below.

> 
>>
>> We have been wondering about the design of this protocol interface. At
>> a minimum, the attester needs to indicate the length of the nonce
>> being requested from the verifier.
> 
> Why? It can cut it short, the Verifier will understand? Are there obvious security considerations that I am missing here? The nonce is requested via an authenticated channel, I assum?
> 
> [Hannes] Different attestation technologies use nonces of different length. For example, the PSA attestation token supports nonces of length 32, 48, and 64 bytes.

Yes, but that was not the question. What are the security consideration 
of ignoring (or "overwriting") some parts of a nonce in a response? I 
think Watson implied security implications w.r.t. predictability. Are 
there others? Otherwise the Responder to the challenge can cut the nonce 
into some "required" size if needed.

> 
> 
>> EAT, however, supports also an array of nonces in the nonce claim.
>> Should such a protocol interface allow a request for multiple nonces?
> 
> Sure, the you do not have to request a nonce for ever interaction and the Verifier can keep track.
> 
> [Hannes] OK. This is a concept that does not seem to be supported in the draft-ietf-rats-reference-interaction-models draft. The question is "why". Did the EAT draft authors went a bit too far and the feature isn't really needed in practice or are the RATS documents not well synced-up yet?

That is a concept being picked up in Epoch Markers though. It happens in 
some scenarios. It is not great for all scenarios. But the "use once 
'password' concept" is pretty popular. Are there security considerations 
that would restrict the application of the concept?

> 
>> Furthermore, the Attester may also need to provide information about
>> the Verifier. This is necessary when there are many Verifiers in the
>> system and not everyone of them might be able to successfully verify
>> the Evidence. Should the request for a nonce also include information
>> about the attestation technology supported by the attester?
> 
> Discovery of appropriate Verifier and "requesting nonces" (which kinda is still shooting from the back into the eye) are different things. You can compose both protocol action, but my initial reply would be:
> Discovery, Feature negotiation, and then epoch marker requests are quite different things.
> 
> [Hannes] How do you solve the following problem: Image a device wants to transmit a CSR with attestation evidence to the CA. The device needs a nonce to demonstrate freshness. There is more than one Verifier.
> 
> How does the exchange look like such that a Verifier is selected, which fulfills two properties:
> * it needs to support the attestation technology of the attester, and
> * the attester's signing key of the evidence is trusted by the verifier.

Well, Epoch Markers are one solution to the scenario, of course. In that 
case, if you trust an Epoch Bell, you would not have to worry about the 
number of Verifiers.

In your scenario of Verifier and Capability Detection, MUD, for example, 
could help you with that. Minimally, MUD could help you to identify 
Verifiers, but it could also help to identify Capabilities.

Establishing trust in the Attester's Identity Document is not the 
Attester's duty, IMHO. You can burden it with that duty and can compose 
a very specific system of solutions here. But how do you imagine to 
enable evolution this very specific setup?

> 
> We cannot design a solution that only works when there is only a single verifier or when there is a lot of out-of-band information exchange necessary to get the technology working.
> 
>>
>> We thought that this type of foundational feature is described in detail
>> in one of the RATS working group documents and the
>> draft-ietf-rats-reference-interaction-models seemed like a good starting
>> point for such details. Unfortunately, this document falls short in
>> explaining these types of aspects because it is heavily focused on a
>> specific TPM deployment.
> 
> That is bad. Please help us fix that.
> 
> [Hannes] I will definitely plan to contribute to the draft but before I create a PR I would like to understand the design constraints.
> A sort of "discuss first" - "write later" approach.

Let's do that off-line. We'll miss the cut-off. But maybe we can find a 
fast way to create a PR bi-lateral.

> 
>>
>> Has someone in the group thought about this aspect already or has
>> otherwise gained experience with this aspect?
> 
> Requesting a nonce and therefore taking on the role of a challenger in
> arequest/response interaction model to then get a nonce to provide a
> solicited push of Evidence is bit of a flaky procedure, isn't it?
> 
> [Hannes] Not sure what you mean by flaky procedure. In a typical CSR approach you have a device that creates a public/private key pair locally and wants to turn this into a certificate. With the CSR attestation work we want the device to request a nonce first to demonstrate freshness of the evidence.

Yes, but there you'll inherit quite a few trust decisions every 
participant here has to make. The "trigger" process seems to be more 
robust, wouldn't it?

> 
> How do you assure that the recently received nonce is used to convey
> fresh evidence? Is there a timeout? Can you cache it? (like with the
> array of nonces).
> 
> 
> [Hannes] In the CMP/EST draft, there is a timeout field.

Ah, okay!

> 
>   Why can't the Attester just trigger the Verifier to do
> the challenge/response? That seems a bit more straight forward? Maybe I
> am missing something very obvious here.
> 
> [Hannes] We are using the background check model here. The attester is the device creating the CSR. In the background check model the device talks to the Relying Party (the CA), which then contacts the Verifier. Figure 1 from https://datatracker.ietf.org/doc/draft-tschofenig-lamps-nonce-cmp-est/ shows this exchange graphically.
> 
> In the passport model the attester talks to the verifier directly. This is also a good model, which we should also support. As you know, in the LAMPS design team we started with the background check model. We have to start somewhere.

So it is not a good idea to relay some kind of lightweight trigger first?

Viele Grüße,

Henk

> 
> Ciao
> Hannes
> 
>>
>> Ciao
>>
>> Hannes
>>
>>
> 
> Viele Grüße,
> 
> Henk
> 
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats