[Rats] Re: Freshness with Nonces

Henk Birkholz <henk.birkholz@ietf.contact> Mon, 24 June 2024 16:49 UTC

Return-Path: <henk.birkholz@ietf.contact>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FC9C1CAE88; Mon, 24 Jun 2024 09:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.46
X-Spam-Level:
X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.355, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ietf.contact
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgOzlB8hWeZX; Mon, 24 Jun 2024 09:49:46 -0700 (PDT)
Received: from smtp06-ext.udag.de (smtp06-ext.udag.de [62.146.106.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE986C19ECBE; Mon, 24 Jun 2024 09:49:45 -0700 (PDT)
Received: from [192.168.16.50] (p4fce9787.dip0.t-ipconnect.de [79.206.151.135]) by smtp06-ext.udag.de (Postfix) with ESMTPA id 3BD3EE0C6D; Mon, 24 Jun 2024 18:49:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ietf.contact; s=uddkim-202310; t=1719247783; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G+H0uuapWkZhkY/Vqx4fORdAILNy5hgeZ5SyWYFXVlk=; b=xmwSDdVdpQGy/nImZL3wLnqi7ygR9Qdnc/IFeA3ob9Em6+XXvoF4M1OF4ZnzK3Pp+DvGqQ Z/+4frfzP62a28JUDQN5QYXgA0kuPMNWXhl0EPnA2v/d21eNkLiRsEupoEdKHtmVU4b+BI w64eJoPyGl50XqRUetoXWYRcB+ncVIJnt0ARwu2ZE0MqvUZEhYRUXuXfJGnEbK132b6EMe akG4W0tnh77WNphJnQ9CijBzwuM2GfUmwHGA6YMBVo4bMF0x8L9WPn+nQEx9zfELdLQ6rK KuNDpCIMB8LXw13+vYxNBOXlck4IUOOKwSEIgkUPD2zznIhe/ExkOA1s+OHLHQ==
Message-ID: <068888e2-5bc8-79bc-9ed6-07389930ce72@ietf.contact>
Date: Mon, 24 Jun 2024 18:49:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: Hannes Tschofenig <Hannes.Tschofenig=40gmx.net@dmarc.ietf.org>, Michael Eckel <michael.eckel@sit.fraunhofer.de>
References: <3D0F8C7D-D1C6-4014-B69B-714771152A7E@redhoundsoftware.com> <533194ce-a8c3-2d41-9dbf-84f08f3afd84@ietf.contact> <trinity-bf4ca0a9-92a6-4aa0-b7c5-9147f3e80e68-1719211783023@3c-app-gmx-bs24>
From: Henk Birkholz <henk.birkholz@ietf.contact>
In-Reply-To: <trinity-bf4ca0a9-92a6-4aa0-b7c5-9147f3e80e68-1719211783023@3c-app-gmx-bs24>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results: smtp06-ext.udag.de; auth=pass smtp.auth=henk.birkholz@ietf.contact smtp.mailfrom=henk.birkholz@ietf.contact
Message-ID-Hash: TQKCRSZ7TLMMP45NFG4A2RUJVS6QGRGL
X-Message-ID-Hash: TQKCRSZ7TLMMP45NFG4A2RUJVS6QGRGL
X-MailFrom: henk.birkholz@ietf.contact
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Carl Wallace <carl@redhoundsoftware.com>, "Tschofenig, Hannes" <hannes.tschofenig=40siemens.com@dmarc.ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, rats <rats@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Rats] Re: Freshness with Nonces
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/xsftG28dezJ6MOxNBck0RSOZdeg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

Hi Hannes,

Evidence that is still fresh after five years can be replayed.
An indication of recentness can help to determine replay attack.
While these factoids are related they are not necessarily related at all.

A counter example, a challenge-response interaction using a nonce can 
yield stale Evidence despite being recent and not being replayed.

The example highlighted in draft-ietf-rats-reference-interaction-models 
is exactly that: an example. The PoC size is... I want to say 
sufficient, but still just one domain of application in a world full of 
applications. The number fields conveyed are specific to the example and 
have nothing to do with freshness or recentness or countering 
replay-attacks.

If you require a protocol that scales, Michael and I might be able to 
provide some support there. The point of 
draft-ietf-rats-reference-interaction-models is to simplify 
specification text for such protocola by eliminating the need to 
re-write text about the interaction models implemented in each 
protocol-specific specification text.

Viele Grüße,

Henk



On 24.06.24 08:49, Hannes Tschofenig wrote:
> Hi Henk,
> digital signatures do not out-of-the-box provide replay protection via 
> any sort of freshness unless the information being signed includes some 
> timestamp, nonce, etc.
> What are we trying to solve, you ask: For the cases where the Evidence 
> included in the CSR needs to includes a nonce, this nonce needs to be 
> provided to the attester first.
> The reference to 
> https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-09.html#appendix-A <https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-09.html#appendix-A> outlines that you have stumpled over a similar need for a protocol interaction to request the nonce. When the CSR is carried inside a certificate management protocol, we obviously want to re-use that protocol for requesting and receiving the nonce as well. In your proposal you even carry more fields than we envision, which raises further questions about this protocol interaction. Surprising, though, you did not run into the question about how to route the request to the appropriate verifier. Most likely you did not run into this issue because of your small PoC setup.
> Ciao
> Hannes
> *Gesendet:* Mittwoch, 19. Juni 2024 um 20:41 Uhr
> *Von:* "Henk Birkholz" <henk.birkholz@ietf.contact>
> *An:* "Carl Wallace" <carl@redhoundsoftware.com>, "Tschofenig, Hannes" 
> <hannes.tschofenig=40siemens.com@dmarc.ietf.org>, "spasm@ietf.org" 
> <spasm@ietf.org>, "rats" <rats@ietf.org>
> *Betreff:* [Rats] Re: Freshness with Nonces
> Hi Hannes,
> hi Carl,
> 
> a generic comment first and then some comments in-line.
> 
> The subject says freshness and your first sentence then goes directly to
> "Evidence" and "detecting replay attacks". Nonces couple recentness
> checks with freshness checks and conveniently also improve replay
> detection when used in conveyance of Evidence (and I am assuming object
> security and not a secure channel here). But, for example, signatures
> can be used for replay attack detection, too. I think you do not need
> nonces for that at all. Nonces are very useful fore checking recentness
> and if recentness is your only way to check for freshness, well... then
> it's also your source for freshness.
> 
> To be honest, the questions below all arise, because I might miss
> something pretty obvious here. What problem are you trying to solve
> exactly? Maybe that is actually my most relevant question.
> 
> On 19.06.24 11:57, Carl Wallace wrote:
>  > Inline…
>  >
>  > *From: *"Tschofenig, Hannes"
>  > <hannes.tschofenig=40siemens.com@dmarc.ietf.org>
>  > *Date: *Monday, June 17, 2024 at 8:33 AM
>  > *To: *"spasm@ietf.org" <spasm@ietf.org>, rats <rats@ietf.org>
>  > *Subject: *[Rats] Freshness with Nonces
>  >
>  > Hi all,
>  >
>  > In the RATS architecture the Evidence is processed by the Verifier. For
>  > a given Verifier to check for replays timestamps, nonces, and epochs
>  > have been introduced. I only talk about nonces here.
>  >
>  > The nature of nonces is that they are randomly selected by the party
>  > that checks against replays, the verifier in our case. Section 10.2 of
>  > RFC 9334 talks about nonce-based freshness.
> 
> To my knowledge, the nature of nonces is that they are provided (not
> necessarily produced) by a challenger in a challenge-response
> interaction model, are intended to check recentness of the corresponding
> response and that they cannot be predicted by an attacker so it is
> harder to become an imposter responder (or in some scenarios maybe even
> an imposter challenger) successfully, right?
>  >
>  > No problem so far. However, when we integrate CSR attestation (which
>  > carries the evidence) into a certificate management protocol like EST or
>  > CMP we must request the nonce in advance before the attester is able to
>  > include the nonce in the signed evidence. >
>  > [CW] I don’t think this “we must request the nonce” is correct, at least
>  > where “we” includes the attester. In some cases, the attester is acting
>  > upon instructions provided to it. Those instructions may include a
>  > nonce. An example of this arrangement is a SCEP payload in the iOS OTA
>  > protocol. How the MDM (or whatever prepared the instructions) obtained
>  > the nonce is irrelevant to the attester and, in my experience, need not
>  > be signaled in the subsequent request.
> 
> 
> If you use a challenge-response model, yes, the Atterster requires a
> nonce generated by the Verifier. If you use other interaction models,
> the "nonce"-like value may come from other actors, as Carl points out.
> 
>  >
>  > This raises questions about how the relying party (in the background
>  > check model) obtains that nonce without conveying any extra information
>  > from the attester to the relying party about which verifier to select.
> 
> Why should the Relying Party need to know a nonce embedded in Evidence?
> It processes Attestation Results. I seems not really elegant to me, but
> if the Relying Party is a challenger for Attestation Results in
> challenge-response interaction models, then the Relying Party generates
> it, and it will be included in the response (again assuming object
> security and not a secure channel).
> 
>  >
>  > What information should be used by the attester and subsequently by the
>  > relying party to determine the verifier before transmitting the evidence?
>  >
>  > [CW] Your question raises questions about how the attester knows where
>  > to obtain that nonce without having been provided any extra information.
> 
> I actually am having a hard time following that question. Is this now a
> completely different topic and we left the nonce topic?
> Let me re-state so I do not get it wrong. What value should be conveyed
> from Attester to Verifier and then from Verifier to Relying Party before
> Evidence can be conveyed from the Verifier to the Relying Party?
> 
> I really would not know. Not a nonce? Maybe a MUD URL pointing to a RATS
> MUD file? I started something ages ago, but it move down on the priority
> list: https://datatracker.ietf.org/doc/html/draft-birkholz-rats-mud-00 
> <https://datatracker.ietf.org/doc/html/draft-birkholz-rats-mud-00>
> That is not an IETF document and was early work that we plan to pick up
> on again in the next 12 months.
> 
>  >
>  > Ideally, the RATS architecture should have provided an answer to this
>  > question but unfortunately it does not.
> 
> I am not sure what "this" is. It seems not to be freshness, but it also
> seems not to be about replay attack protection anymore?
> 
>  >
>  > [CW] I think this discussion is hinting at a desire for some attestation
>  > verification protocol. It may be that sticking an extensible field where
>  > the hint is now is the thing to do, to facilitate the relatively
>  > abstract current hint mechanism or a future, more concrete, link to a
>  > verification service.
> 
> Very simple CBOR-based request-response messages are outlined in
> https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-09.html#appendix-A <https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-09.html#appendix-A>
> 
> A CoAP-based reference implementation exists in:
> https://github.com/Fraunhofer-SIT/charra 
> <https://github.com/Fraunhofer-SIT/charra>
> 
>  >
>  > Ciao
>  > Hannes
>  >
>  > PS: We (Hendrik and I) thought that the hint introduced in the CSR
>  > attestation would have been a good candidate for this determination. In
>  > our mental model the hint would be something like an FQDN because in the
>  > passport model of the RATS architecture the attester also needs to have
>  > the FQDN (or even a URL) of the verifier to get the communication 
> working.
> 
> If all RATS role should be aware about the same "nonce"'ish value in a
> freshness period, I think that is an Epoch Marker? Nonces are not
> intended to achieve that by themselves, I think.
> 
> Viele Grüße,
> 
> Henk
> 
> 
>  >
>  > _______________________________________________ RATS mailing list --
>  > rats@ietf.org To unsubscribe send an email to rats-leave@ietf.org
>  >
>  >
>  > _______________________________________________
>  > RATS mailing list -- rats@ietf.org
>  > To unsubscribe send an email to rats-leave@ietf.org
> 
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
> 
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org