Re: [Rats] Requesting a Nonce from a Verifier

[[e-mail]]

Hi Orie,

 

I think a lot of what you wrote in your email below regarding the use case should go into the draft. I wonder whether it would make sense to put the content of the nonce draft together with your other draft. 

 

Regarding being stateless: If you borrow the ticket design from TLS, see https://datatracker.ietf.org/doc/html/rfc5077, then you can be stateless. There is even a recommended ticket construction that is very lightweight (and widely used in deployments). 

 

That’s at least what Hendrik and I have been considering. In the attestation context we couldn’t, however, use the ticket design directly because the size of the ticket exceeds the expected size of a nonce. Hence, we would have to convey the nonce along with the ticket to the device and then return the CSR + evidence + ticket in the response. That would be yet another change to the CSR attestation draft …

 

In your use case nonce size limitations does not seem to exist. Hence, you could more or less copy the ticket design from TLS.

 

Ciao
Hannes

 

 

The draft is meant to support use cases where a nonce is needed in digital credential issuance and presentations.

 

Using a signed or encrypted value allows the verifier to remain stateless. Which prevents DoS against table based nonce solutions.

 

It also enables scope or context binding for the nonce value.

 

In the attested status draft the credential holder needs to demonstrate possession in order to receive a fresh status attestation... This means they need to aquire a nonce first.

 

For a concrete example, imagine a digital wallet requests proof that a digital drivers license is not suspended, every few days.

 

The wallet proves possession of the license, the issuer provides a fresh proof of non revocation, and then later (within some validity period window for the status attestation) the wallet can present both the credential and the proof of non suspension, even to an offline verifier.

 

OAuth has a number of endpoints that are anonymous access, but endpoints that perform more expensive operations, such as encryption or signatures, should consider more aggressive restrictions... Suggestions are welcome :)

 

 

OS

 

 

On Sun, Mar 3, 2024, 4:59 AM <[e-mail] <mailto:[e-mail]> > wrote:

Hi Orie,

 

Thanks for sharing the draft. Of course, I have been aware of it.

 

I have been wondering about three aspects of your design:

 

1.	What use cases do you have in mind? Obviously, this draft was not written for DPoP since that already has a solution. You also haven’t written it for attestation in OAuth since there is this other great document that also specifies a solution.
2.	Why do you require encryption of the nonce?
3.	How do you protect the nonce issuer from DoS attacks?

 

The write-up in the CMP/EST nonce draft was inspired by  the Attestation Verifier implementation.

 

Ciao

Hannes

 

 

From: RATS <[e-mail] <mailto:[e-mail]> > On Behalf Of Orie Steele
Sent: Mittwoch, 28. Februar 2024 02:42
To: Smith, Ned <[e-mail] <mailto:[e-mail]> >
Cc: Henk Birkholz <[e-mail] <mailto:[e-mail]> >; rats <[e-mail] <mailto:[e-mail]> >
Subject: Re: [Rats] Requesting a Nonce from a Verifier

 

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] <mailto:[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]>  <mailto:[e-mail] <mailto:[e-mail]> > on behalf of [e-mail] <mailto:[e-mail]>  <mailto:[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]>  <mailto:[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]>  <mailto:[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]>  <mailto:[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