Re: [Rats] Requesting a Nonce from a Verifier

[[e-mail]]

Hi Henk,

Thanks for your quick response. See my remarks below: 

-----Original Message-----
From: RATS <[e-mail]> On Behalf Of Henk Birkholz
Sent: Dienstag, 27. Februar 2024 15:35
To: [e-mail]
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=[e-mail] 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.

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


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

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

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. 

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

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.

 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.

Ciao
Hannes

> 
> Ciao
> 
> Hannes
> 
> 

Viele Grüße,

Henk

> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rats