Re: [Rats] 802.1AR device identity

"Smith, Ned" <ned.smith@intel.com> Fri, 16 April 2021 17:55 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 BC51B3A2E28; Fri, 16 Apr 2021 10:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLb9k42Ek_oi; Fri, 16 Apr 2021 10:55:11 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 5A52E3A2E25; Fri, 16 Apr 2021 10:55:10 -0700 (PDT)
IronPort-SDR: tJBeZLP/tWY6ASIVCc7csHUzgHETpSwcPFug16wKTo/HWPCG0fsBMocA21mJOWQMZ1PyVHvYUQ pMhHmsOW0mJw==
X-IronPort-AV: E=McAfee;i="6200,9189,9956"; a="194637271"
X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208,217";a="194637271"
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2021 10:55:07 -0700
IronPort-SDR: /FdPzPbY0pFOT4qSC05eeMyB6eImkX5nGSjM85jroCPYDYASDkWeXwbFKP8CgGyViWNb1tcz0e XkCNeMfQBs/g==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208,217";a="533527927"
Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga004.jf.intel.com with ESMTP; 16 Apr 2021 10:55:07 -0700
Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 10:55:06 -0700
Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 10:55:06 -0700
Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Fri, 16 Apr 2021 10:55:06 -0700
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.171) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Fri, 16 Apr 2021 10:55:03 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1ATzJkDsE8F/CsjusRjVBd9r3nVC6j+WECUNqfH2m5L5leOIcSrWPte6PYjL65ATx19SeQTw7HB5x45uPvk2mQRCFr49qVogSxOVBTLGA962cY3ZrB2C1h27sVZywj/b2cle9aIVIPsOwG7SNCDmOGR5ORmYmqTc7qhU6Ry6lnecvGBxSKa54CxiaMYoIlwCXH6y4KgtF+9zGxzuVarBlR69aveDJEzoZrY7nVnRkMrlWx3+zyCa53X5e2o1erpYKidCjqshsL3VZMJ0hxt0W6mFadohIgk30uf8NOq+pNc0wBDBh3+L0cTK2M2hOfSV2k7pcnYZpLXv2d6ps5VfA==
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-SenderADCheck; bh=f2MUVIUsyso/UlD9MFy/qtrW1I10hc0+TZvFn11slAw=; b=FkCL3BlBRJpCe2bw27BO5WUgpum5IuWtRNxhot9nD3vFHnzQyTGHmJao5TPG5/HR6vibywHBdMpgNXcjPaX7fs4BENXYS6B0pEQkEr9TjYpPv2zXhmKO8u0opJXx0xTXAI31HLoU34Ie8dsODn/LMfPruqZk1ISOT+MXutLk8FmkIUBsBfjDsazHdFWC4IbzE4QnBNPwtSiCKHrVC6LzB3Rjq4g47W8h8t5CAXwSbm8EJkrnVcJGYlwkrZpK82byzszPIx4qiLPe9l4Vna/0tMDewRCzUKDFDFzbhWuaztJsSElXNfvMAK2nGClJsEv+31hGFCBsE9mbTwoJ17d0nw==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f2MUVIUsyso/UlD9MFy/qtrW1I10hc0+TZvFn11slAw=; b=GNuYc/XqCLs8Jmm7EsfbaLOGuZlmtsBXEd6ZqMmd5FQ+BNGzJKCQLfDgAns828G5EIK/WE2qw15Ndj0gBOJpQbIcStpUaDkxGctp+6mCkEtnGBJbHozm9sdQFYz2TMm33PKWztxyg8QcARGHeT8EDCGa0BlfpHWfxNchd69CdQU=
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by CO1PR11MB4945.namprd11.prod.outlook.com (2603:10b6:303:9c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Fri, 16 Apr 2021 17:55:01 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2%6]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 17:55:00 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>, Guy Fedorkow <gfedorkow@juniper.net>
CC: Ira McDonald <blueroofmusic@gmail.com>, "rats@ietf.org" <rats@ietf.org>, Eliot Lear <lear@cisco.com>, "iotops@ietf.org" <iotops@ietf.org>, "Henk Birkholz" <henk.birkholz@sit.fraunhofer.de>
Thread-Topic: [Rats] 802.1AR device identity
Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOAgACzxwCAAAOuAIAXhE8AgArnz9CAEXR1AIAEKBoA
Date: Fri, 16 Apr 2021 17:55:00 +0000
Message-ID: <BD13AD1F-0E35-464C-9D06-2CE4AC1372B3@intel.com>
References: <D197C29D-95C4-4696-BE22-703E14DFFE35@intel.com> <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com> <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <CAN40gSsCbjpVuCQwsWWjGwfL=cARHcAa0ZPsm+sk8H=9_otZUw@mail.gmail.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <BLAPR05MB7378A9F73457513AC951F82FBA7A9@BLAPR05MB7378.namprd05.prod.outlook.com> <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com>
In-Reply-To: <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21031401
authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=intel.com;
x-originating-ip: [50.53.43.22]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b696b0d0-f829-482e-cd68-08d90100c149
x-ms-traffictypediagnostic: CO1PR11MB4945:
x-microsoft-antispam-prvs: <CO1PR11MB494535A826294D4EA90C3891E54C9@CO1PR11MB4945.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:308;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZxpSYOBAAiqVPPZdOejoYfWGsRizzQlu1yiWtZ8jjcH4YT6p1adccwul4pYZWy8JuvG8YFVszEVMlnHx2s2VWVG5GgisgRgp8Sd559w4FGGXzM8RIl4Q+ivpgWDpi6zk1M8WWgD9U0osX1Hc9MZKbGgNZXvwVMLQ2L0EUx1ZOCA9zyAMHnZtUX3aI0PPhUSjFT6hYOCqQbVRCRw6lTVFYohHfLxSX/OTHzFkZlarYW1PL2S6v3vB+vM/RPmuqQ1Y4JyRZNcIALaBPPIMoeuaL6w7k0AODNqXexhuzpQKRgb07ALbagun+uwvbnP09NabYj+Bh+/eIvfZ6btXh+nuyFq3G9L5CYCrKgfWtCCZnenwlzHwoQWio9Fp+5k2KHLOtGgIYB6ujtVAYd2jXtsgKnk+1m0HUncJ+cKx9eGDdA3RMOSqeDujBhxySRn8E0cDtS9517xrrN1JvgwB44MUzizUWJ3PW8tBtWjKph3NjakbFk2JjBjgB7u7I2Zf0nfA8Y6MdmS/hhKUQgHQJrD4YbQ7CSQt0JuoZTWW8+FkeX05o3wnzshQVbeOe60hGFklThNk5W3DesxUy2/nAbEjyGgyLGdErSGiaCNlei4r8ab6Ud0hWNfzATxCFv203ZALx/Evw721V3DJFTeg3gu20adLZgf1q3wTTEhSWXwu3kFJPeDEjHls0dBkyyaiiW7MffDNlOe/xWvCN55mTvmS3teKOQ7Eeb7UhPpGFcd+SMTrJ4jdJli1FBxL0SlSUOv3/34FO//5DdhmayKfvoUHwr4JxMVE9+z66rUhB7WGbD4=
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:(39860400002)(376002)(396003)(366004)(346002)(136003)(5660300002)(83380400001)(2906002)(26005)(316002)(6486002)(8676002)(110136005)(478600001)(6506007)(966005)(122000001)(38100700002)(186003)(6512007)(53546011)(64756008)(66446008)(66476007)(4326008)(54906003)(166002)(33656002)(71200400001)(76116006)(2616005)(8936002)(66556008)(86362001)(36756003)(66946007)(134034003)(15398625002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?dS9rS21lVVVuUWZXcElYanpzVzNlYjVaaHgycHNncWFrV3BFNlhVLzZpWnVO?= =?utf-8?B?MkxkSkhjYThuRUJlTENyRlhodDZxMmMxUmFwaWNONkJkN08rYUtFVS9yQlVv?= =?utf-8?B?d1ZGUkY1aHdVTFpGM1pNYUN5eVF6YnBqRkZXb2swRDMvdENka2c1ZmM2MXd4?= =?utf-8?B?SzZiUDRUejVpNCtRM013bmJ5dFE1RncxTVVBZkxQM1ozeHA0YjZCdXMvTjdZ?= =?utf-8?B?VE43U0xCTE5SU1NvY2VuVk9MN3ZsVXVTd1p2cm9DenJ1cFlEK0pNM0J2aWFS?= =?utf-8?B?QUlEdEZ3bFhITEUrc1JMbVZoelF4WGd5cms4dDVzVzZkUU5hYTJJcGZUZ3d3?= =?utf-8?B?V3ErM0d5Zm4xQkk3L3hTV2JLZ1dnZ3BCVHpnOSsvclpkMzNEZmY2Uzhad0FR?= =?utf-8?B?NWkvRmRIeVV5UUMxNGFKQS96QlZrQWNNVVRsWStOL2lIalJ4aUtmSXVFbmFo?= =?utf-8?B?YVV4VnhmUUxCc1IxanFkbFNnYXR6Z3g0dEc1cDZXSkVmYnMwaWp5MW5xeEdV?= =?utf-8?B?SlNBWW9vbGt5VGFUWUo4OVJWendmLytVRThkaDBXMFY1eVFhVGZweDhMRDlx?= =?utf-8?B?cVZIaGhxQ3J5TytaV1I3K0dheUVDZkpEdXlJZjlCVUZndHVmNTBDNkF1VG9s?= =?utf-8?B?YnNPY1Z2Zzgwazd1Mkh3Sk5XeUZiejVJajRMUVByL3NsZm53MG9lMUJwdHpZ?= =?utf-8?B?b0w1YWpIc1M1UVROanRnZERMTWdwYkF4OWYvUTZGWDRvREQxL0x1RDEwUFJO?= =?utf-8?B?NXZaSk1qT3dWRUdmU2h5QXhuMUdBeC9kVUlDNUNhQU16Vi9xWGFVem5oU0hG?= =?utf-8?B?V0M3RGwydGZScUJLRTduSENlNHVMMG5YTmR4YkM0MFJDTlpzRE1CSlpEYXJw?= =?utf-8?B?WjlHQkYyS0tiSXZMYjFkemx5S2U4T3RmdzJPOVIzNkNFcjhnZ3NWdk10ZzZF?= =?utf-8?B?VW0yZ2l1bVczaktuVFRKNXllcEthS2hraDd6b2JzWllDTzN3WER2cTd4WlBz?= =?utf-8?B?bWlmeHpSWXJxV2JOeUc1aVJrQVhJS1hWY3o4ODRqaVcyMFNTLy9KeWxHZTEw?= =?utf-8?B?dE1FVllLMFc3TUJ2aDhKUzBneFhQaGU0ZWtlYVNCY3lXS1dXVENIQzZQZjJN?= =?utf-8?B?UzlET0ZZSzEyZlNxSzBxYWNja0NzOVYvOW1WQnlXdHhQN3IvUzRLdUZOK2RL?= =?utf-8?B?UG9HYythOGZnSkN4b2QxaC9QWmlVSkRhVDBZTFIrbkNPNTFva0F5TUh1WEVO?= =?utf-8?B?Ymg0QytDZjZIZitqandqZVNaKzdkSmFsOEZ5U0xoeHdYTzA4emFPSkRIMm9K?= =?utf-8?B?bnFaYjhEd0NzLzAvR25wbnRwbjZZMStiUUhxai9QUThBOEx5VWFFUlZ2RUdm?= =?utf-8?B?OW9XRjFIMERDSm05bWprWWFLNXM3U2xiSWxZK3JwcWltQkRtVjViS3hIdkJ5?= =?utf-8?B?NjBFakFKRk9WanV1VkJmSUZmY1JpejM1Q1VqSXNzVStobFlOeWZwcE10VE5u?= =?utf-8?B?ejI4dTVOdTNwUUxwTU5Qd0R4dGMwQU1xVDR6d0RCajI3N2R0UkNlRHUvVjFp?= =?utf-8?B?OGhlN2Q0OWtycHlHNVpyRXNsbnhTVVhBckNnZ28rLzVJdE5jWWtDUko1R3ZP?= =?utf-8?B?VFVQS3VkMUlmeVFFSEwzRFppajB5MDNYRDl3Smx3ZFdsUHhVdkVBZFY5Wmla?= =?utf-8?B?NjJKbU5HUHBDUWlHTVQ3dm52ZFkrVHVYeGRqREdCRVFNZm1YZkpiL2hDdjBt?= =?utf-8?Q?xIjX6qSfH+i8RRmJ4gs8zXATrM0kIx02ulz18xh?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BD13AD1F0E35464C9D062CE4AC1372B3intelcom_"
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: b696b0d0-f829-482e-cd68-08d90100c149
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 17:55:00.3515 (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: QoZlVQbtMr6+O/NEgxMfK792+kMpeKGCkrxy85wbbZShCamb/NaLunhDr4lnWhuimOo3+GNOvS7HeERBCZ7ckg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4945
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/dJCqdPl5Be1ui8EIaacPwsaUGVM>
Subject: Re: [Rats] 802.1AR device identity
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 16 Apr 2021 17:55:17 -0000

Device onboarding is probably the most prevalent use case for IDevID. But that is only a guess.

From: Laurence Lundblade <lgl@island-resort.com>
Date: Tuesday, April 13, 2021 at 12:26 PM
To: Guy Fedorkow <gfedorkow@juniper.net>
Cc: Ira McDonald <blueroofmusic@gmail.com>om>, "rats@ietf.org" <rats@ietf.org>rg>, "Smith, Ned" <ned.smith@intel.com>om>, Eliot Lear <lear@cisco.com>om>, "iotops@ietf.org" <iotops@ietf.org>rg>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Rats] 802.1AR device identity

Thanks for the comments, Guy. Appreciate it.

Agreed that repurposing IDevID keys for EAT might be a bit weird and wrong, but it is still really useful to understand how they are intended to work and are actually used to help with the design of EAT.

802.1AR section 7.2.5 say the keys can be used for signing. Appendix B has it participating in an EAT-TLS session and gives some other very general use cases.  No matter what, the key has to be used to sign a nonce for proof of possession, so there is some signing of external data going on.

https://www.trustedcomputinggroup.org/wp-content/uploads/TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf lists a whole bunch more use cases like IKE. Do these really get implemented?

What are the popular and widely deployed use cases for IDevID?

I kind of want EAT to learn from IDevID here. To understand what IDevID is about so that EAT is more capable and fits in better with use cases.

LL



On Apr 2, 2021, at 10:05 AM, Guy Fedorkow <gfedorkow@juniper.net<mailto:gfedorkow@juniper.net>> wrote:

Hi Laurence,
  I agree that IDevID is intended to persist through the device’s lifetime, while LDevID is meant to represent the current owner.
  In TCG-land, an IDevID is not advised for signing attestation evidence; its role is limited to identity, providing proof of the supplier and the real-world identity of the device (i.e., serial number).
  With TPM1.2 it’s actually not possible to use the IDevID to sign TPM attestation evidence, as a counter-measure to block spoofing by an attacker, so the TCG docs advise a separate attestation key with a binding that links them to the same TPM.  I think that’s not actually necessary in TPM2, although the advice for separation remains.
  So in that context the sentence “[EAT] separates the signing scheme from the identification scheme” seems puzzling.

  But in the EAT environment, where there’s no technological block to an attacker with access to the key to spoof an attestation result, I agree that the DevID could be used to sign an EAT token carrying attestation evidence.

  Let me know if I’m missing the point!
Thx
/guy



Juniper Business Use Only
From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Friday, March 26, 2021 2:21 PM
To: Ira McDonald <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>>
Cc: rats@ietf.org<mailto:rats@ietf.org>; Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>>; Guy Fedorkow <gfedorkow@juniper.net<mailto:gfedorkow@juniper.net>>; iotops@ietf.org<mailto:iotops@ietf.org>
Subject: Re: [Rats] 802.1AR device identity

[External Email. Be cautious of content]

I got my copy of 802-1AR.

I’ve made a PR<https://github.com/ietf-rats-wg/eat/pull/101> that
   1) Adds an SUEID to EAT that is similar to LDevID in that it can change on device life-cycle events
   2) Adds a whole appendix discussing the relation of IDevID to EAT

From reading 802.1AR, it’s pretty clear that IDevID is permanent. Here’s one sentence:
These additional operations can include deletion of the IDevID certificate or IDevID key, which can be logically equivalent to decommissioning the device,
802.1AR also provides for an LDevID that is less permanent in the ways that Giri seems to be asking for.

Please take a lot at the PR. It does a little compare and contrast between EAT and IDevID. I am interested in comments on it.

LL



On Mar 11, 2021, at 11:13 AM, Ira McDonald <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>> wrote:

Hi Laurence,

Thanks to the wonderful *free* IEEE Get 802 program, you can go to this link (from Guy earlier)
and create your own durable free Get 802 account and then download IEEE 802.1AR-2018 (and
anything else from the whole IEEE 802 series that you need).

https://1.ieee802.org/security/802-1ar/<https://urldefense.com/v3/__https:/1.ieee802.org/security/802-1ar/__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31Q-lsLJs$>

Cheers,
- Ira



On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:
I want to unpack and unfold a few things here.

Permanence / Lifecycle / Privacy — I think the main topic here is about when an ID changes relative to the lifecycle of the device and how this relates to privacy.

Compromise — I think compromise due to algorithms being compromised or the device being owned or such is a separate topic. Discussion of it seems orthogonal, should go into security considerations and really comes down to certification in the end if you really want to lock it down.

I’m not sure which is meant by “immutability” in the previous emails.

My intent in the definition of UEID was that it is truly permanent. It doesn’t change at any time in the lifecycle of the device. This is the simplest case to describe. It is not at all privacy preserving for some use cases (e.g., mobile phone), but is OK for others (e.g., dumb sensor).

I was thinking other folks might define other IDs for other use cases. Maybe the time has come to invent one or two of those and put them in EAT.

Some Solutions
One possibility is an SUEID, a semi-permanent UEID (maybe not use SPUIED). It is allowed to change in major events in the devices lifecycle such as events when ownership changes, the managing entity changes or on factory reset. I think this lines up with the way some MAC addresses are managed for privacy reasons. This line up is good because a UEID can be an IEEE MAC.

An RP might receive an EAT with only an UEID, only an SPUEID or both. The RP can decide what they want to use.


Another one is for the Attester to authenticate the Verifier and/or Relying Party and generate a distinct UEID or SUEID just for use by that RP. This is a solution to the privacy issue. I’ve actually done an implementation of this one.


A related solution is to have a privacy proxy between the Attester and the Verifier that makes RP-specific UEIDs or SUEIDs.


Separation of ID from Attestation Key
An ID that is not signed is nearly useless because anyone can forge it so we’re always talking about some sort of signing.

EAT intentionally separates the ID from the signing key. I haven’t read IDevID, but I don’t think it has this separation. The reason EAT separates them is to have a lot of flexibility to deal with the privacy and lifecycle issues that come up in real deployments for chip makers and complex supply chains.

For example, FIDO uses group attestation keys to deal with the privacy issue. One key is put into 100,000 plus devices which makes it statistically not very useful for tracking users. Maybe the device manufacture uses this tactic for billions of devices. Then maybe a use case involving only millions of these devices needs a truly global ID and have the means to program it. This can work if the keys and IDs are separate.

Or maybe the manufacturer changes signing schemes moving from a primitive MAC to EC-based pub key and onto some sort of DAA while maintaining the same scheme for device IDs.


Possible harmonization with other Device IDs?
I noticed that birkholz-rats-suit-claims<https://urldefense.com/v3/__https:/tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31d19M7lw$> mentions a device ID based on UUIDs. We should probably take a look at how this relates UEID. There’s probably others to check out. We probably want to re use a lot of the claims from Evidence in Attestation Results so they can be pass-through for the Verifier.

Note also that UUIDs are obsolete now.

LL


P.S., Any suggestions on how to get access to IEEE IDevID? I’m not part of a big company. I tried joining IEEE once, but that wasn’t enough to get access.



_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31_KoAAkI$>
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats