Re: [Rats] Requesting a Nonce from a Verifier

[Orie Steele <[e-mail]>]

In the context of OAuth DPoP the same endpoint that requires proof of
possession, can return a fresh nonce, in error messages, and there is also
this draft:

https://datatracker.ietf.org/doc/draft-demarco-oauth-nonce-endpoint/

Which seeks to solve a similar challenge, without overloading an error
response.

OS

On Tue, Feb 27, 2024, 7:24 PM Smith, Ned <[e-mail]> wrote:

> Given 9334 outlines several possible ways to incorporate freshness and
> recentness and given the reference interaction models I-D provides patterns
> for exchanging information that should possibly include freshness and
> recentness considerations. And considering the WG charter biases the WG to
> focus on augmenting existing protocols over designing new ones, it seems
> Henk's suggestion to improve the reference interaction models I-D make
> sense.
>
> If this thread is focused on an I-D that modifies an existing protocol
> with freshness and recentness, then would it make sense to use the
> interactions models I-D to work out the general principles for how
> freshness/recentness is achieved first. Then, can it be cited as background
> for other I-Ds that describe specific modifications for an existing
> protocol?
>
> -Ned (not as chair)
>
> On 2/27/24, 11:35 PM, "RATS on behalf of Henk Birkholz" <
> [e-mail] <mailto:[e-mail]> on behalf of
> [e-mail] <mailto:[e-mail]>act> wrote:
>
>
> Hi Hannes,
>
>
> I am in a weird TZ offset, so just a quick reply.
>
>
> On 27.02.24 15:18, hannes.tschofenig=[e-mail] <mailto:
> [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?
>
>
> >
> > 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?
>
>
> > 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.
>
>
> > 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.
>
>
> >
> > 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.
>
>
> >
> > 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?
>
>
> 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). 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.
>
>
> >
> > Ciao
> >
> > Hannes
> >
> >
>
>
> Viele Grüße,
>
>
> Henk
>
>
> > _______________________________________________
> > RATS mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/rats <
> https://www.ietf.org/mailman/listinfo/rats>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <
> https://www.ietf.org/mailman/listinfo/rats>
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>