Re: [Rats] Attestation Terminology

"Smith, Ned" <ned.smith@intel.com> Wed, 20 September 2023 19:38 UTC

Return-Path: <ned.smith@intel.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 E7409C14CE40 for <rats@ietfa.amsl.com>; Wed, 20 Sep 2023 12:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=intel.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 9-JdCIXAg9B5 for <rats@ietfa.amsl.com>; Wed, 20 Sep 2023 12:38:24 -0700 (PDT)
Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) (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 9C4F6C14CE2C for <rats@ietf.org>; Wed, 20 Sep 2023 12:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695238704; x=1726774704; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ADBbRJZHzG60tphyKu52jY+8nAZ3Q81XOlXL79Je6+I=; b=NLnjNRBMQYfDvFzp3BoxoXhPftNWddbxWYtqAkpuJozKyb81R7TdvqLp z7X6xd2uFiiBvRQriDgJEidZrVoKpeoOW6HIfg7j7jPTF+WK21V6R+3/n cQxhDEs5WkiP/NnvqxQ+M4q64wHOGUsjqM9DkSyLCUKBBMZayjgLO+s+k Oz6AY9CQhsZ8uZZk6vod/GnxTvm3lB/M08swpvCzuSw5PYZ7/H5y1uHWO ETbTSmpNUnPNpWv9VmrG40mtIweQfHymdoTfOxNyDxpoPbxNVqwNzlgGy GG01n7gaABG7jCCiXYuECbe6vjvu4Cm5Ngu6CBxHWgsDeLXii8sRj0N5T g==;
X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="359702931"
X-IronPort-AV: E=Sophos;i="6.03,162,1694761200"; d="scan'208,217";a="359702931"
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 12:38:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="870501669"
X-IronPort-AV: E=Sophos;i="6.03,162,1694761200"; d="scan'208,217";a="870501669"
Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 20 Sep 2023 12:38:16 -0700
Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 20 Sep 2023 12:38:16 -0700
Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 20 Sep 2023 12:38:16 -0700
Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Wed, 20 Sep 2023 12:38:16 -0700
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.44) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.32; Wed, 20 Sep 2023 12:38:15 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FmMZ7eE3fc7+SHYCH8GFyYNSfb8ph1KtW/4t/t2RC/pUVRI3HdqJw+GCZzBHMhCvslhrvsIWQROUynWEGtWiWapCf1WaH5pPJlvXYpCbJn/LFk4N2EMnDAG0TI5hixAZhjnaAhsf5Yzf8pImrfI7eYwjkYzhuGtSVZ8QbXMcLFhsLJqtF0Vp28QD9nAE/QxzOFxuVntpGE7xkoGYx5SBIHt7EhNil0n7RYeGI2wO7JqYHUvqWViZf0yQyqszcQxYy7Lmxb+1pFCrKe7X7RkRgV1A5Zlp8zSPXNeIDpmvjrLoV2HUMWq+fSHb322Nqq28Tu/G6P6El164LL/z4vsK+A==
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=ADBbRJZHzG60tphyKu52jY+8nAZ3Q81XOlXL79Je6+I=; b=H7l6mblpsVpvm0Wf1VhMO7vbZ+NBX2ccHqawZtzQaswYkbLNOtAScJgmkPhMIolEx9YuMHhD/KN5ARWLd7GC04OXSJsUKmV/45Gbyq0pPBv+utwJOZefbSSbfx9RpQbiGFqoOaGXaIB/HveYV22dX5jW225UGicbB3SIaszip+fSpKGv319bnJ+VFohjIdJwiQv79kilp+JHoZYNIpR76cbOc7w86sSQX3+Te/d9xTEwvIE6A8Pr3xa7ZfP1+eFvdHg7uWw9ouBRV8cwfRRl7UVHe9lmsm15G2l8uKHcF48+42CdP7L3unkW/eE64tNTiwiTDN/ijuj/xMaXLBJZ0Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by DS7PR11MB6040.namprd11.prod.outlook.com (2603:10b6:8:77::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.28; Wed, 20 Sep 2023 19:38:12 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::5fb6:7200:97a4:b7e9]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::5fb6:7200:97a4:b7e9%7]) with mapi id 15.20.6792.026; Wed, 20 Sep 2023 19:38:10 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: "lgl island-resort.com" <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: Hannes Tschofenig <hannes.tschofenig@gmx.net>, rats <rats@ietf.org>
Thread-Topic: [Rats] Attestation Terminology
Thread-Index: AdnqydtfjPaMHIqxQYm7XOY/OvM+XQAJsxKAAEGk74D//5ApAA==
Date: Wed, 20 Sep 2023 19:38:10 +0000
Message-ID: <08E29163-7E46-4028-8AD4-8D00C2C254D4@intel.com>
References: <002e01d9eaca$65aa4010$30fec030$@gmx.net> <cfaf21a1-7294-fcb1-b16b-17280ff56704@sit.fraunhofer.de> <099FEACB-9B88-44A2-A467-2EBF54C5422F@island-resort.com>
In-Reply-To: <099FEACB-9B88-44A2-A467-2EBF54C5422F@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.77.23091703
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR11MB5169:EE_|DS7PR11MB6040:EE_
x-ms-office365-filtering-correlation-id: 19fb9352-e650-4f85-d7b5-08dbba111f85
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /H8DjSEDxVb2gdht+uuftZTpDDTf3A8dAP5zHkcOcbT1IHq8rnUX8d3w/ruEHwQ52AuLSGRw00X+Dw2wfSt6TaoSs22EMLtcrL50M9VDlcRhGz6xe48+t2OCeaQxHTNZk3Ogjb40buxwOlj2g4KUcjrUwcOJSQQoaErfaiAOBKft8DfMtsTGHgeo38P/7FxiGl3mtHPu6cxZ54AZEh4iXvMTB4o6QF/cn1E4BqprFZAZizd2MCy/BYgCA5Gj6sAA4iCZtoFVVRkil0/bN9eICiZxgpf1tz4YiTWn1VqLwPKlmODX0nPtgofOPUcqVB/7QCgYCDtZNmHvr9U3B4kkvsCGakY/vntpbajPkZFqy7UhVlrMFhTuZz0WEnKZJzE+Uddl9IOIGXnkT/mItJIQxOHoVJrYejTG0pu7SFKcQMmTZIXAOBi0L12dse9JxS0R51f5m4w3spsicCFZ+yb0PQ5xY9jZHc2FuAMYNLy2nvxWFN/f3XwEUYVLgtZNeqwVgDlFIagLkTFXVbI1SK9Zin7gZOia2A9jXMAObjbkojbHd/ARdC/xQfiQ1mVNwHIPgbg114IUgxCpy39Zkaf1xeGJYGxqWTqmvpOMiEl7k25CXQ4238Tu1Ef0hDJvqvLS7AdZoXqQYYbR+uyYB0mp/Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(39860400002)(396003)(366004)(136003)(346002)(1800799009)(186009)(451199024)(478600001)(6486002)(53546011)(6506007)(86362001)(82960400001)(166002)(36756003)(33656002)(38100700002)(38070700005)(122000001)(2906002)(26005)(71200400001)(6512007)(83380400001)(8676002)(8936002)(4326008)(5660300002)(2616005)(966005)(41300700001)(66556008)(110136005)(316002)(76116006)(54906003)(66946007)(66446008)(64756008)(66476007)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: cnp3z1ZBqABi8ZxyKr1VLzOxZItAuLiSJYkpp4sdhu7g3TTqQPFNB5IZdHHHjczE4fvZAD+E4a6at/YubDAwN6rsidl5/7/hqde4s3sq06Bihd02UuNlxbwNUk4+t5ovRhaorH7LgNVyXFk32yGjqj1qN3I/YrQvGus9jeaiLuKt7tPMZ3OM+/xdXmOhoXj1y3oo/InJjIIEoISstWkYrs+Y9cG4qgFfY31JP5V0GHBP+HrWYX2oM6Rzqq5M3c/c+HnHnODEbHavq4Nprgm8eQhKz9xUG6a9JXc4Pny5fDMLbTYziUx3bsS4gDFQZLHoogtcgN84xKvxQ/ooHJStg0zZk8JiQwt8mRhYcoR0u8JLGL+rdUDibXCD6/aM5mMRzGCLtoT2xN4lttjEI5DnYhLORJv4kr4D26PLYIlvoKZ+tMSvEHAKsxgmWwMX+REC8GMo+27Swh4t1yiKIQD2/eBiAywktNRvFSI692kehLFOTxBEp/l4oaQkQtx/ASt84iprMugIgkDBKD6+dzYRgSlU4f22HbBlH+DPi8Tsp6q+iwx20B3oyp/zYqzrMKFhc2GmSLCelvJMo5saGzqEYkrn66ZZddPTmzQFhwSlh2idceuZdFMAalYWymWqwJTyaMv27ugbPXTGfezLqHlEV5k4dEH7fAw+4nsRyiA4fp1AsFpRYHdTxXpIEfGn4ekV4bjHb0qiuvLjCgsoSkUW0eb3LkwUHU9qpQ3o5NTdDzyaatdRRwB5ZMaww2vsX0gJCuil6YxSZrLIPKVt6CYFbqWYTIpvDm1UaUWVPZZygtuNUBOPxC8w3/5rHRjvlFuuPfjyvNRnAT9gM8nBavNhlge42jS1voRmgwW0yFFY/AsY/HlaTk/5+z/RfFQrnXY+FtN+Hz2dNY8muhoDM2vhg3Ht0UvLj/3H9S0PFs0CzLjePoELEeG+bW/n3jPG700CHeaK/xacSikIh2KL8lQYjEfCYgSXOp8sO/X1RYEzlzX2/G5rtwJvHIuj8pif+vT1cfKR01LEfoRUteSmnjot13728OxhQTb45e/przCCJ6amCjV1g1JBIpRhrJJd1sAxTPmjSXuC3dLpXQ03HxxV1ZhL22BVI9BHzQQoBjfvIA27inzFcboFd9rSe3GwbN/fc6pKai2CVtiQVWQWh8kb4N/4QABayCFyqhSXvXMc0gsxPiH4UHXdGQywJpUFtrLOKr1VBwpDo2t/PXpQIIsh99JrUQBe4Z5Y5IfX99HKTgaT/jS44XT6+YPfC8xGmhwxYP+auXak8jJBDKAYIJ7nfxdG+V+3rF0F0f4yPHZ0ry3zPkak/sVKc4fHLFWOd4tr5q5f/QuSntXAA8ky9lA7+mKttMmPmq2MVt86lzDWRcJbGjYTEsMsncteIY+sqPVqpbMPuEXXZyxVMMrTi7V8BjN3qS/aVkCJ8LdlLI8zLMgIudtsmlbF28aDnn7pGJohs+6mE4zLuGvZzXQmu7mh13wRJfspETobw69fE7jjjfjfUrWhiAjtlVJIB7Wxj7GyaqNGzLi1aC4OoLnVV4J3Sai9775hRuKhKMumaiV96eaiE4UoeDmlkci1CRA4+WOp
Content-Type: multipart/alternative; boundary="_000_08E291637E4640288AD48D00C2C254D4intelcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19fb9352-e650-4f85-d7b5-08dbba111f85
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2023 19:38:10.8631 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fRjBKHLf//IUIVQs40SY3vrOClUNH9D/Oicz/F3U6qxe8ihBOgLNUkyKWAJYsf6Ft369z+gkgzCBb0GTzEZW0Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB6040
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/4uTppVCsaqtUAHd1VBepqRVuMow>
Subject: Re: [Rats] Attestation Terminology
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: Wed, 20 Sep 2023 19:38:29 -0000

Right. This echoes the consensus of the RATS WG, that definition of attestation was a non-blocking item.

Possibly, this thread is clarifying that any RATS draft (outside of 9334) that includes a definition does so to accommodate the interest of the audience that is the focus of the draft/RFC?

At some point in the future, if there is interest and a clear path to a consensus definition, then either 9334 or 4949 could be updated to include a definition.

From: RATS <rats-bounces@ietf.org> on behalf of "lgl island-resort.com" <lgl@island-resort.com>
Date: Wednesday, September 20, 2023 at 12:19 PM
To: Henk Berkholz <henk.birkholz@sit.fraunhofer.de>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, rats <rats@ietf.org>
Subject: Re: [Rats] Attestation Terminology

I personally don’t have a need for a canonical definition, but here’s how I think of it — how does it tie back to the legally responsible party?

User authentication like passwords, SASL and FIDO authenticate the human or organization buying the item, accessing the data, …

Server authentication, primarily TLS, authenticates services, the company selling something or providing a service

Attestation authenticates a device or implementation that is doing something for you and indirectly the manufacturer of that device

Lawyers move liability around with contracts. We move liability around with crypto and protocols. It eventually goes back to some legal entity you can sue, prosecute for a crime or such.

It good and well to check that the SW is up to date, but that requires you trust the HW that is reporting on the SW, so in the end you really need to *authenticate* the HW.

LL



On Sep 19, 2023, at 4:58 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:

Hi Hannes,

w.r.t.: `attestation`

there is no satisfying answer to your question, I afraid. The RATS architecture was explicitly and carefully worded to avoid the word `attestation` as a stand alone term. As it causes confusion in the context of "activity vs. message" and is horribly overloaded, in general:


https://csrc.nist.gov/glossary/term/attestation

(here NIST captures the confusion in a nutshell)

That is why RATS is about _remote attestation_, and corresponding activities, such as Evidence Generation, Conveyance, Appraisal, etc.

w.r.t.: `key attestation`

The RATS WG has not defined the more narrow term "key attestation" today. As Denis pointed out, "OpenID for Verifiable Credential Issuance" does, for example. Looking at that definition there are two essential components:

1.) "a certificate including a certificate chain asserting that a particular key is managed, for example, by a hardware security module"

2.) "provide this data along with the proof of possession in the Credential Request"

In RATS (IETF/TCG) words, I think, openid is defining `key attestation` as as an Endorsement (according to 1.) of key material that is then combined with a PoP (according to 2.). That is not the same thing as remote attestation, as there is no Evidence about the trustworthiness of the Attester generated.

I am not entirely sure how useful it would be for the RATS WG to specify  yet another meaning of the term `key attestation`. What I would see as useful in any case, however, would be writing up a definition (independent of any name). Maybe something along the lines of "Evidence about an endorsed key storage that is augmented with a PoP of a stored key" or something to that effect.

But that probably just reflects my half-baked understanding of "RATS key attestation"... what would you think `key attestation` means in the context of RATS, Hannes?


Viele Grüße,

Henk

On 19.09.23 09:24, hannes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net> wrote:

Hi all,
I am wondering why the group has not defined the term “attestation” in the RATS architecture RFC. Instead, it is defined in a solution document <ietf-rats-tpm-based-network-device-attest> where nobody finds it.
Ciao
Hannes
PS: Where is the term “key attestation” defined?
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats