[Rats] Scalability ... RE: Requesting a Nonce from a Verifier

"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> Mon, 29 April 2024 11:52 UTC

Return-Path: <hannes.tschofenig@siemens.com>
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 EAEECC14F60A for <rats@ietfa.amsl.com>; Mon, 29 Apr 2024 04:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=siemens.com
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 FWZzC87sc2ZA for <rats@ietfa.amsl.com>; Mon, 29 Apr 2024 04:52:35 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2086.outbound.protection.outlook.com [40.107.22.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57034C14F6B2 for <rats@ietf.org>; Mon, 29 Apr 2024 04:52:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eYnD6Zkq2AqCNib8QpJitcLloCtlMj5AxgWILWMvgZuDI/J74dAOLxQL8JSEkt15M/gsnwqFRWhDLsBPbX9r4EuTf0BquuldMhE2CHhBsx1o+kzlmbDx1/kN7uj4JNtu2MfGrqXUvJ62pfykDCyw9FZIGEjEMBkqv8mRA4AiqKmCxQV9hILqjMyKkGno0aiprv606bsMEqnqyzLWTHFkvNMx7aySb04QJaWhlrC84Mosqz5gDwhD8pbQpYdHMapQgZGiw5IFAXMbiIkdQrWAaTO+5woYU6YnGOcpBHnorzWCAS2SQ/iFSq2o6vMNCTvKIoq8rkZOkX/iJBn2lwZCuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rr0YFPRuVTsZkikJWF7g7KyYaB0JrD4sBB+sTT5ty6g=; b=lmHRxaszj13BNc1LsR4omHFTmanKbmnEGcQnYX+84PGBT1YjR/UfaqDahiuvhX5XFtObhIK80iII1UPOERBPm3smAiAbEFivY5nthLW8zKDJFOYwqjO8+myASfTcgAYibcK5sCuOhcWzjruau7iSWwzijpv9OJq6Cp5KgEWli7ZtKES6kqFSKNhrFgKeb48dLQadfMxCJFJdTPeNAMJKrqw6nEiyH9L1r9dS1WiZAsg2JG738jq8YRUjVhA8YK1jZsLDgC2vSFzSqAwc7ZTz2KsNx01+IqQJJGMTJONGFxjL6d/ChHUTvf9NgBl6ndB/syNjxjJKOaL7bA9Mn/KqEg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rr0YFPRuVTsZkikJWF7g7KyYaB0JrD4sBB+sTT5ty6g=; b=qH/EiizsI4jgommueE4Fdy8Cb3STTQRLCK1GiMOzCLVuKmF3IqIW8u9oKbubXLgUOaDwAMJHrX+9ZfD0BUceUMc7MWH4u9UudNVpq0R1Vd7EzkZuSRyiy2dgfgPyZZH62bSnD6P0RanrH3qiDGKuWPlxf7tODfblKsEFbV/MhtUGjt0uaYI8Hbm/5Ycr3JLWRya0lUwFYzsRA6YPISEu6Li3RSULuVGihzT3pYvqcRstyYe5qX1zaP8p5JKPHknWwGG5itef1YHto6YYviywOpo4E7b4WBsyGZ9uSgMwZw2jGLE+5xTkJALQL1S3xz99vURiX5PSmBUfd3eh0uG3YQ==
Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5ab::22) by AM7PR10MB3860.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:17c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7519.34; Mon, 29 Apr 2024 11:52:32 +0000
Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM ([fe80::9172:20d1:3f36:a3d]) by AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM ([fe80::9172:20d1:3f36:a3d%3]) with mapi id 15.20.7519.031; Mon, 29 Apr 2024 11:52:31 +0000
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: "Smith, Ned" <ned.smith@intel.com>, Carl Wallace <carl@redhoundsoftware.com>, Thomas Fossati <tho.ietf@gmail.com>, "hannes.tschofenig=40gmx.net@dmarc.ietf.org" <hannes.tschofenig=40gmx.net@dmarc.ietf.org>
CC: Henk Birkholz <henk.birkholz@ietf.contact>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Scalability ... RE: [Rats] Requesting a Nonce from a Verifier
Thread-Index: Adpph2/sCzoh1slqSSKBshTevR+ZrgAArLOAAPUvtwAAnTVbAP//oEQAgAFKSQCAAKvzAIBIslx/gApnJBA=
Date: Mon, 29 Apr 2024 11:52:31 +0000
Message-ID: <AS8PR10MB7427492A34036D4967A4A4DAEE1B2@AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM>
References: <02c501da6987$d2d64490$7882cdb0$@gmx.net> <ecf9ac86-82f2-80b7-160a-bdde42387ef0@ietf.contact> <011b01da6d5e$e30e4e90$a92aebb0$@gmx.net> <a69d9a50-68e6-80c2-e400-f565da746d79@ietf.contact> <5E4A8C93-FC03-4780-9F41-F0CCA559B513@intel.com> <CAObGJnNPc_x691C0s7dEA_ccB0z6mQnN_xo5Ub8JOaD8PBkqgQ@mail.gmail.com> <08510523-D6C2-4F31-B6D5-F3DF1E995A77@redhoundsoftware.com> <CO1PR11MB5169BB7D67DE0BD588069186E5122@CO1PR11MB5169.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB5169BB7D67DE0BD588069186E5122@CO1PR11MB5169.namprd11.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=01a1ee1f-dab1-4e0c-b100-568c0da41f2c; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2024-04-29T11:46:20Z; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR10MB7427:EE_|AM7PR10MB3860:EE_
x-ms-office365-filtering-correlation-id: 759be4b1-4b0b-4511-f6a1-08dc6842da4b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0; ARA:13230031|376005|1800799015|366007|38070700009;
x-microsoft-antispam-message-info: TarBJpP12tu0edJ5uJRSO88qRLQz/XwijZd6dYzcJKW3pzYv0X6AIEt9RhyBSTD8fNWAEKypK5aqWrPb3siF2ZnRtUEvT9LGQHBVHisbxWUOa/NBpkYKcDhBSxWvZQNGL9GqXk6YOQS0C+bmFV2QE49Jar8Tjd1kxTpiYcpucWfm9DTcAtO/t4Ob7LcTu8RGtKT2WJmwiPf1M3tkW9/RDVbcNDp2RxjlL3nZp9RzWWAFyoeRB6dWChdBUrcvc0zPlGh53y9B4TzM3CxuJrBhWOeZGrPa0gunex1NfKkV2nCFWl75deTpWk85NlOaS1CHbtpFgFwX6Q/RGHsePFB5svXqPpfaEthHip1vJN/QXmuVOtm9QofqL9bvgVUg5+MhGa7UMUPsoh+Cg3MIrcIJ1SNxOHudKR45/OyAp4N1kgr3hRH91LiKWvWpiAzkaGqeZ69Zz05Q3ZXL2S16lrqCB45lj5bzXkbD9yn2HtPmawmfc2VJWmkb1S0DsrbIrn/MneEJ1Ks6G+RnR2qj/hy53nbdE1HPlt7vju+eSEr1I1UKXofWrcURvWoHq6aszSF/+O2JKpj7VVuSXZGX7IZEfqq5uGYUgTkU7XP+1nOF8vwPq2so0lrIU25+a30p9Yx56oDINHzC76WP9vdig3bsks0GqH8sO17AYLOVYUYpb17ZlWXNmXPVA4avOxuwET2i51fZXve4RGdM/BWGOu9n7scAmF/rO0Rv/pXFD2rcdmIixcv5UyrxoS2bRHg7oLoQsYLs2D2pG0OxpXJtUcRskl1p1++b54XzApp195YmHYRUyXKRPSlJjqeDEGl6dqhY9eHAllCR9zOBQlQv7QZcRCgH+vbi/EvYQm4m/EJfk5ozJLBuwbDXzAs12bTvxemKt7NOr2MND8mpd3AINFhIrto82Po/N0zx2c7eJjOMuz5dSF4Z9MmIyvHMYTBp97CNFa7KtcgQjC6eQoaBtadZ2e5ORvSJOF8uhGzIHIYXWHu7NWGYFwISpCrPAEHqArm+Uw9Exy2uSnOJ3rBe2SR046XRe+he/JnZ7t/edcDeugSRAwqdQqC+DrqoSjs0pX8Hm8pJvryMkvA4qAKIv9ZPak/g4KbZrtP3EeU7j5mGor0/XyyAENseaC2qtd0cTjYFwqR4qNSXm+pc5Fn15Ka156M41DxTxxVeFvd/B/ToxIazSFM8lUpl9LIYuZ4dNW7Q/77L4px0gMQx+6dfVhGYjXc25uN8EcaC7vhQllaAlTsgYJEuy4Ekk5j/5Fghny/RifIlmXBIfB6pwTtray+EUTayn/8MXmRRSV4+/9/wzOhZAGRAbUget9CS2WmPEF557holbM8pFP4te1xqwMkFvQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(376005)(1800799015)(366007)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: gLmQnrOy3N83fGEPOqey3UMdMY4mlzwwtA7Q29qM1o9Fz1+uExKLCaZ0bJv0kxc7B3gkMxaMPfIMuS9kV2tTf7uuBQDtMtekNVW5+/AqjCpGOEHyRaaDVvcMTGGR8RmTqZBAqHpZSVIXJALRv1AxpGWzKpN6PweQsTwLzn70RCw90Xeu/QzXdA75BpgAKYCzuGNc18V8TtG86Jg5cLaaKLYrX2USxa/Hc3zeEKUWywee87APkyCZsaRk+lj0jixOjaPEyhdWLb+itUJ0Lj8aL44p4/ZfeB/Bp2FXt4rLqFJRH0cjho616qTFynAaRf3uYrXPe2G+OUWokM/Ke8DAqk0Ntp2pfFnbWh438sdx0F/Ov2GFoazkii6HMdY1rYhL7ZrunCU3e2x+pWzF8Ggvryq9YLs4rlYXQBUqAb7a/WIuJ2Ufll3KqWdzl4ar3JFORH1O1GlNrcB99EF08OQ+WfsWU1VVkRBEqQqA6pNkM/5jEG/gjAfqTHRejpvksVjaUgzMd7v5SqLuqmNGS2iL8g4lKmimaAfDkCiNOrpeK8GM3MuPHvQkWNkeWzSXyFiMsg4eZV0FmhYRYgH78mEWM+WJl/21DAl0UXbq7g4I7NzKl6vvcpUnQDjm/kIICma4RKaz6ANQgvLtvUa38SRktlyUW62SIOMpmd6f5TJ8UzSD9XQ0vKU/PHpTcT/ymrdBxophfhVKJ1s7O04wbSqpljrSrIcpsnVcOGHMkEjNsWIOBmJ78WixUxdFDxx0nR79maiOp1GuH/LY69LkBPeKvJhOo7STWrr1gKrleC15ELFve7KWKa8szurPZ5CzpK46NK6j43YfaOV2ixmDDoEkmnivK2z/C5EyrhjZWFoXih7bJMGeQXiUQylDgVsRZ26F6ZkiF9rCWE8rjBwWb202aYcFN1ddl4HryvJa0iECs3y25a3U875Nxie2aFI+SNmeGs09kdEUCXdkBtDJOYp5bvANEJbVX5Qu6mni6DyVuv9VyDs0SLL+YPrdnBJ+QTrwd5vdXb0znkffvsQ23+MBhlTM+6jAlPIHl6icX9F/fgEsyfLdrxvNZIU87QGfHDoRJsu0RSz5D38H45YdYh+PH4ym+n3GIRwf5/y3vj85kbXdwh8+hme+ijqIkOy78X5v3w2kc113jShXchP1AnDVowkFHe34G6IFhdV47apKPO7tmSwgdaejHbrd6BNzr9h9RPQN0yG1CNuik1sJKJra0vWqaIrQOS02SJS/RGrrxT3sSaw6CV8Ezx0THTT0blZ2xW35tyLIAs3gT64Hkb+lAgXB2Qvmq8Rr2VAQ7sgMXbXHzOhGmlwcWl9WK/SWhtT2Ef0HA3jCflgqJu1i9hxpFncFRzhF1yixfedT+UUkBNzr+LJs5i6ZxJjtuekOdMMfrn8J5pbmwvvLNt5EYx94C30bAvEcoXEQF9jBrWYiuyid7srvWO4CMnINayZifLBzcmGqXkz44IzwAm7qvBksbEeKrh+e8n7IuVOlH5AzivRKtFcXueZDeEbuDeJ45NpuoWXCNvQ+AE1LoSBLMw/ffnbcX0PhDdg+lbonYh6o31n6nRQFJNgPzmYrwdb7cixG0o+UlyIJwqkxPOkju4z7xg==
Content-Type: multipart/alternative; boundary="_000_AS8PR10MB7427492A34036D4967A4A4DAEE1B2AS8PR10MB7427EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 759be4b1-4b0b-4511-f6a1-08dc6842da4b
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2024 11:52:31.8898 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: M96AaQEVnh3iVRy5jhzpUGMMwaLSieNFWwfbFLD0HK1YZKYDoMCzyT2tVKzWAcHDS9Yph9WnFXezLUO2uA4hcSH06OinQnUJdc49mSkaavs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR10MB3860
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Ux8SAxagUnChT5aSMqlqyV75AiU>
Subject: [Rats] Scalability ... RE: Requesting a Nonce from a Verifier
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2024 11:52:40 -0000

Hi Ned, Hi Carl,

imagine a world where remote attestation is heavily used. In that world, it is likely that relying parties will interact with more than one verifier. If the number of verifiers is indeed very small, then the dependency of the attestation architecture is relying on a small number of players.

Regarding question #4, in general it would be good to also provide information about the attestation technology. In some sense we are doing this by specifying the length of the nonce, which is attestation technology dependent. I agree with Ned that a generic solution may be tricky to design particularly if we consider more complex device. On the other hand, the use of remote attestation in more complex devices could be considered a research question. Hence, I would keep it basic for now and revise the solution in a few years when we gained more experience with these complex devices.

Ciao
Hannes

From: RATS <rats-bounces@ietf.org> On Behalf Of Smith, Ned
Sent: Monday, April 22, 2024 11:33 PM
To: Carl Wallace <carl@redhoundsoftware.com>; Thomas Fossati <tho.ietf@gmail.com>; hannes.tschofenig=40gmx.net@dmarc.ietf.org
Cc: Henk Birkholz <henk.birkholz@ietf.contact>; rats@ietf.org
Subject: Re: [Rats] Requesting a Nonce from a Verifier

@hannes.tschofenig=40gmx.net@dmarc.ietf.org<mailto:hannes.tschofenig=40gmx.net@dmarc.ietf.org> – did you get your questions answered?

  1.  At a minimum, the attester needs to indicate the length of the nonce being requested from the verifier.
  2.  EAT, however, supports also an array of nonces in the nonce claim. Should such a protocol interface allow a request for multiple nonces?
  3.  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.
  4.  Should the request for a nonce also include information about the attestation technology supported by the attester?

Note that I-D. csr-attestation describes a PKIX deployment where the RA is the RATS relying party and interacts with at least one RATS verifier.

The RATS roles, possibly confusingly, aren’t entities, nevertheless nonces (freshness / recentness) apply to entities in some deployment context. RATS Arch may be insufficient to resolve the freshness recentness architectures.

I think it’s reasonable that the entity requesting Evidence could be integrated with multiple Verifier entities, each expecting some sort of freshness indication. If multiple verifiers supply multiple nonces, then the context for which nonce belongs to which Verifier needs to be preserved.

Question (4) could be a bit tricky since trust in the attester may be understood in terms of Attester composition where one component may depend on another component such as in DICE layering or TPM trust chains. Presumably, Evidence has enough context for Verifiers to decipher Attester composition such that the trust dependencies can be walked to some logically meaningful description of the Attester as a protocol end point. It may be necessary for nonces to have Attesting Environment context too such that freshness of each AE in an Attester composition is knowable.

-Ned

From: Carl Wallace <carl@redhoundsoftware.com<mailto:carl@redhoundsoftware.com>>
Date: Thursday, March 7, 2024 at 07:51
To: Thomas Fossati <tho.ietf@gmail.com<mailto:tho.ietf@gmail.com>>, Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Cc: Henk Birkholz <henk.birkholz@ietf.contact<mailto:henk.birkholz@ietf.contact>>, hannes.tschofenig=40gmx.net@dmarc.ietf.org<mailto:hannes.tschofenig=40gmx.net@dmarc.ietf.org> <hannes.tschofenig=40gmx.net@dmarc.ietf.org<mailto:hannes.tschofenig=40gmx.net@dmarc.ietf.org>>, rats@ietf.org<mailto:rats@ietf.org> <rats@ietf.org<mailto:rats@ietf.org>>
Subject: Re: [Rats] Requesting a Nonce from a Verifier
Inline...

On 3/6/24, 11:36 PM, "RATS on behalf of Thomas Fossati" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> on behalf of tho.ietf@gmail.com<mailto:tho.ietf@gmail.com> <mailto:tho.ietf@gmail.com>> wrote:


On Wed, Mar 6, 2024 at 5:54 PM Smith, Ned <ned.smith@intel.com <mailto:ned.smith@intel.com>> wrote:
> I'm not sure I understand Hanne's use case. Is the CA doubling as the RATS Verifier?


No, the CA is the RP. The CA trusts one or more verifiers.


>If not, why does one CA need attestation results from multiple Verifiers


I guess it is to support devices that produce composite evidence.

[CW] Or just different types of devices, i.e., iOS devices, TPMs, Android devices, etc.

<snip>