[Rats] Re: Freshness with Nonces

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 24 June 2024 06:52 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 4D873C1519A6; Sun, 23 Jun 2024 23:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.708
X-Spam-Level:
X-Spam-Status: No, score=-2.708 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_LOW=-0.7, 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] 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 1EtLulv49cWR; Sun, 23 Jun 2024 23:52:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 51043C1519A3; Sun, 23 Jun 2024 23:52:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1719211973; x=1719816773; i=hannes.tschofenig@gmx.net; bh=iElie74/AKfCHof+uc2+70kXVYnkFP7YNrmGPzr3jeA=; 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=VZNgWjqc6/jTRjAnuV6t2z2VSPi+0F4ruOTHS8kWzY0uCwzvGrAjR1pwg6vHcZx3 QApvk76VQqeSKCJRf3VY4jpBDqk37KGvXolrV2i4lyJVdZBNY6zztYIshbpkxnlKw 7rS2Mb693WZHJhUdFCdk95cSo4heNOMc20v28lfMTLOMwKqoi+4vHaCRb25Wkxjgk C4qWeIBNa9KRISLzW0MbauMBlnzow9aBKpGJ6qaSFII/4Xr0Ci7yUh+EhOmZ2qctV vjYkwbwRQih3ndEoiLUSMwd7sfCMd8hR5a8t9eZXEzeMnAcQxIvUtXm1YF7uXfyPd PmLka/iUzmcpFamzfg==
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:52:53 +0200
MIME-Version: 1.0
Message-ID: <trinity-e9d548b8-7cfa-4b36-a9d3-a304d09cba32-1719211973692@3c-app-gmx-bs24>
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: Carl Wallace <carl@redhoundsoftware.com>
Content-Type: text/html; charset="UTF-8"
Date: Mon, 24 Jun 2024 08:52:53 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <3D0F8C7D-D1C6-4014-B69B-714771152A7E@redhoundsoftware.com>
References: <3D0F8C7D-D1C6-4014-B69B-714771152A7E@redhoundsoftware.com>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:B6Ga0V+yKoAUigpd5cYIMmeDy6lbsSQbL3Ng7MXCQfAVIxxACPZmjyYWxClT0TQc+ssKk s1Y0NJdDNRCg+aWAat6FhUiK7+X9WiSpZBrmwGQ7PH5e8ud0UyFHDeD5LgHEI6nQWMBpu7ivESYH jyXkkPdJXNFBRQ2Y54mYMKrUBKhY5LuTuy/x7eVu5aG/1mcxF5CLaPOuU7iFUlVrKnvqrr/OVKoU CiyAxU7v/4dLyHNXJCcEN0e0i5oFdDjdqhj+3Q+c7ygi6Zl58JMxXXuDcCvRVGR8a20C62hX76/N 1k=
UI-OutboundReport: notjunk:1;M01:P0:mfv7R0uG1UQ=;eGAStX0DwrIeKyryRbx0LwDIH7O vtZj1uaYbDQyo/ZE7g6YmxLPB5HR/ey1eB/rqo7A+cKH27MmRSowPX3CRbLX4yaW80kydFFix wdKxsRdCd5tWEqSlY2KTnjeCua9W+fBVDdmUFX1rpfXaxlYUA3PwCnFjCtWOkcpVj+5JyCMcQ BbKSTorExIZpQ2oap/BRl8BySDyFw1fb5bhyy6e53Q0ZyFRkA0x1jUkvBlnUCVAb2Pb1y1RVk zAIi9bqDyg/eVafljwtp24fzLuYqCXWyUk/dJT+w4nXF4QDWE0Yngtl66QiffSxU3pi3D/9pC g6a6L0QFadNjHo70oLv7Y6l1lpbA3JFfVwuTjmtsELGXjUfej0X6dsxaL3cJM9sa7CLQAG3Rd Mftw+LVzVI2okrYS8dBQ/KUJ/+u8M9IcjKYaqeNr/AKP8pZ7bdOPfnDwIo1MvyGmMNiCqzxGr utktr2Ql0KCT7uuxD1M1siTuzXOgVBcI0ZXIFDh/Q4/crCkA1OOT8lgIyjywj2n5mzRpGErLj pKhITnARY/LJy7hdFJHzvNtOhOXoK9725zefkcF5mwdGvwVKT+KX2hBbV/fiClx9tmy3HJq4B 3ZTLUCg8jSehZPZWShP3sn2RruNs1P7jtZkaXxpnaMBMQjsofA4XWrCKIb6djd6bU7yVv9WBh F25/O0fTwv4PDSDN2MA9fobJS1hmJ1AFyrZHZT17hUhzfcEBApbIsn5r9A34awE=
Message-ID-Hash: DBUKOUW6HJM7E2BUEHFVGPX4FAP2PEXY
X-Message-ID-Hash: DBUKOUW6HJM7E2BUEHFVGPX4FAP2PEXY
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: "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/Wp7SQo1U5RoHpl8I_pCZmUUDj9I>
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 Carl,
 
what you are saying is that you have some proprietary protocol that allows the attester to obtain the nonce. I am arguring that we need to standardize the details for the integration of the CSR attestation into CMP, EST & co if we care about interoperability.
 
Ciao
Hannes
 
Gesendet: Mittwoch, 19. Juni 2024 um 11:57 Uhr
Von: "Carl Wallace" <carl@redhoundsoftware.com>
An: "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

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.

 

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.

 

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.

 

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.

 

Ideally, the RATS architecture should have provided an answer to this question but unfortunately it does not.

 

[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.

 

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.

 

_______________________________________________ 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