[Rats] Re: Freshness with Nonces

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 24 June 2024 06:49 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
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 E83E5C1519A6; Sun, 23 Jun 2024 23:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.006
X-Spam-Level:
X-Spam-Status: No, score=-7.006 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmx.net
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 83y_057mZmLv; Sun, 23 Jun 2024 23:49:47 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9315BC14F5F7; Sun, 23 Jun 2024 23:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1719211783; x=1719816583; i=hannes.tschofenig@gmx.net; bh=uaTMAvb8pcPeImhRd6b4DGdCmOK0lB9b/ddpBW4SOgE=; h=X-UI-Sender-Class:MIME-Version:Message-ID:From:To:Cc:Subject: Content-Type:Date:In-Reply-To:References:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=lyb3Qrf1/LLCNbn0ZoKxwHMXbaJgEL98Fxg0sw9MSANykgrw6WGfm1/IOEKmMl1L OVKvBem1ZXKd03Use99sMVLzZno6Lny/XcdCHhqlTnSPSHGTZYHSgvdvde6rf8dxU CiV0aqpZ1PONkHIOGHKaNG/m4HJNommJKjL8DHqlcCMlEUzQii5wGS9ckdCv4eAg1 4UHPCM0Axu5tz8HhB93fRwhZ2Zb3XHbuNxBm16xX1meCG4/MWnSP33zJYa/wHqyEM b2uIOS+OdJRcIcYSopey3Q07RxBj6bRa9nZGyX8UMmDw1HnuMIwJ7Y8Y4dUneD73p yEfbn7sdj9+7UTi+xg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [109.43.50.121] ([109.43.50.121]) by web-mail.gmx.net (3c-app-gmx-bs24.server.lan [172.19.170.76]) (via HTTP); Mon, 24 Jun 2024 08:49:43 +0200
MIME-Version: 1.0
Message-ID: <trinity-bf4ca0a9-92a6-4aa0-b7c5-9147f3e80e68-1719211783023@3c-app-gmx-bs24>
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: Henk Birkholz <henk.birkholz@ietf.contact>
Content-Type: text/html; charset="UTF-8"
Date: Mon, 24 Jun 2024 08:49:43 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <533194ce-a8c3-2d41-9dbf-84f08f3afd84@ietf.contact>
References: <3D0F8C7D-D1C6-4014-B69B-714771152A7E@redhoundsoftware.com> <533194ce-a8c3-2d41-9dbf-84f08f3afd84@ietf.contact>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:6Qhv/d87p5W78xTPhS8XMjw7lJBUOhvjYL++1X5tmyNeNDZby2Ysm5HWL5Z4IbCXPMq7E rJU+I/QWk+/2F6tK9QAMNGKmh9S3IVbk5MtMRD9jT129JiEh2kwMW+PDo0UQBw0uf5VOsIVaWfa/ sRHDcLUpAoVE10q1lO3kcL9FwwU9u2sJTAzAeGpfaj9jT2fSWabUaAe2rnCnru5er2Ov5RM3DWxc fqaGv7mN/oNe1BsQf3cYtqn2m/R3E2BEBBWjswND2I2tldJk6qdpfrGiEOSBLRIvhS69ymWuzOot RU=
UI-OutboundReport: notjunk:1;M01:P0:fEwAE2EGLoo=;Ek9e2TJd3rwVOqgMns9DKNmqI8k yKdP5I0dcU9w2vtTcvH5GAbKu6nY1xNQPoE23SQvNHqcW4bg/J5taZMO+cCbi2RLr1iZk6i6q K0ZHiPAO5drL5xot3VRpEEKuKg3UCorag4WSvEiFCwfNoqjqNfX5Rek8Z/HGwx18HfAKxfa+1 jy/IIfsmIhhgyh3VimbOp4aYVnGXWpksvlaKVLDJ8/xrRCjFBhgQupMo2zH5h0CbEQfd4HKEt cpMB53lWXaEc9fRBPe70GMBVCHmIQoFBPe/yxMSdgh2H1KX7BbYFPZMHR9NBAYyB7pD/UyvJa PEuXh78dymiCQwOqmwUxUDk5MN9qxJTlsEEpJ6LJM9T6IXlj66VnjfojlM7bD+bT88NkdmjFz KwO7j9RcOYjsXgqonWrflReB3zGH6P36rXM/NJ0Yzf8eO3L6QvHdNnOl6Dww7/UvgXdeOLy3f muRV5kUvmsE1I3w1j6bPBJGehRTwwbqDX0SdOn+QI39LY9XX9+GfSRdf74nwEy5NyDV5OgTCX /OJ94ia769q5C7rTuMUj6NS/Po8pmbEFgGur3WtPK03GB/LXYwDG00NVPe2ZdDdFLMm0qWfB8 tIpFea3iR7gKJ8CGosZRSMlCnhh1qEnnLZwe7DgMDa9tNnmibjBW5E63TAzgeocnCG7ty+i82 KgxNztcychnzMszcvaGJMm2VdXqXB11mXH2bYlEHXzmwiaTczh4wmTvifngqpKE=
Message-ID-Hash: EMJLYM53N76D3BKV6XSZDLR2GVPIIB6H
X-Message-ID-Hash: EMJLYM53N76D3BKV6XSZDLR2GVPIIB6H
X-MailFrom: Hannes.Tschofenig@gmx.net
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/rK6xV3PjdDEUYWgVkI9sLBpHitk>
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 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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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