[Rats] Re: Security considerations of remote attestation (RFC9334)

[Muhammad Usama Sardar <[e-mail]>]

On 24.11.24 23:01, Giridhar Mandyam wrote:

> >I am struggling to understand what would be the benefit of the device 
> generating a nonce itself?
>
> When there is no return channel from the verifier, then a nonce 
> generated on the device could provide some level of assurance (as 
> imperfect as it is). For instance, several years ago when we were 
> developing ATSC 3.0 (an IP over Broadcast technology), we were looking 
> into whether the rendering device could be attestable. Unfortunately, 
> the transport (https://datatracker.ietf.org/doc/rfc9223/) does not 
> provide for a return channel.
>
Not sure if get the term "return channel" right. RFC9223 does not define 
it. RFC4949 does not define it either. Here is my thought:

  * How would a device know when to send the attestation? The verifier
    would somehow request the attestation. The same channel over which
    it sends the request, it could also send the nonce within that request.

  * The attester still has to send over the evidence; the same channel
    over which it sends the evidence, it could send the evidence
    containing that signed nonce.

So why is a "return channel" required?

> A device-generated nonce provides the same kind of replay protection 
> as a jti (https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.7) 
> in my opinion.
>
I disagree with the following statement in that section unless the 
Verifier keeps a state of all the jti's:

"The "jti" claim can be used

    to prevent the JWT from being replayed."

Is jti signed as well? Even then, nothing stops the adversary from reordering. Here is a sample issue (simple Attester-Verifier interaction):

  * t=1: Verifier requests attestation
  * t=2: Attester in good state generates JWT1 with jti = "xyz"
  * t=3: Adversary stores this JWT1 and does not forward to Verifier
  * t=4: Adversary compromises the Attester
  * t=5: Verifier requests attestation again
  * t=6: Adversary sends JWT1 from t=2.

Verifier believes attester is in good state whereas it is not.

I don't believe the security considerations of RFC7519 are good enough.

> -Giri
>
> -Giri
>
> On Sun, Nov 24, 2024 at 12:14 PM Muhammad Usama Sardar 
> <[e-mail]> wrote:
>
>     On 11.11.24 22:21, lgl island-resort.com
>     <http://island-resort.com> wrote:
>
>>     There’s some framing in the EAT introduction that contrasts
>>     attestation security with authentication security. It discusses
>>     key life cycles which are very different for attestation. That
>>     seems important to discuss in the context of using TLS for
>>     attestation security.
>
>     The second paragraph of intro was an interesting read. Since it
>     states: "To give an example of one aspect of the difference", I
>     would naturally assume there are more differences in the minds of
>     editors. I would like to read more about it. Is there any
>     issue/thread/meeting where this was discussed?
>
>     Reading through the privacy and security considerations, I have a
>     couple of questions:
>
>       * Sec. 8.4 states (emphasis my own)
>
>     > The nonce claim is based on a value *usually*  derived remotely (outside of the entity).
>
>     I am struggling to understand what would be the benefit of the
>     device generating a nonce itself? How would the verifier/relying
>     party make sense of this value? Moreover, this directly
>     contradicts Sec. 10.2 which states: (emphasis my own)
>
>     > In this approach, an unpredictable nonce is sent by the
>     *appraising entity* and the nonce is then signed and included
>     along with the Claims in the Evidence or Attestation Result.
>
>       * Sec. 9.3 states: (emphasis my own)
>
>     > All EAT use MUST provide a freshness mechanism to prevent replay and *related attacks*.
>
>     What are the related attacks?
>
>     Thanks,
>     Usama
>
>     _______________________________________________
>     RATS mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>