Re: [Rats] UEID where an instance is a group member

"Smith, Ned" <ned.smith@intel.com> Wed, 25 March 2020 16:29 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 327113A0BCF for <rats@ietfa.amsl.com>; Wed, 25 Mar 2020 09:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cjPQSPIaB39N for <rats@ietfa.amsl.com>; Wed, 25 Mar 2020 09:29:51 -0700 (PDT)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 9AC5F3A09A4 for <rats@ietf.org>; Wed, 25 Mar 2020 09:29:36 -0700 (PDT)
IronPort-SDR: WZLcKGZLvVKrBCv1f+4v7iqyoS9Hp7XW/BELppdXNAuAfSy46oCnfphwe2amyyhFpVylIleaiJ dUCc2GBx6UTg==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2020 09:29:35 -0700
IronPort-SDR: RtVUID7bNCpSB+yb7dcAANbyAK8Wr2l13mtcJ52lmC30ldKQ9uU8h7x+twu9T0P6VxZscdxwaR bQTMjy9mTwIw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,304,1580803200"; d="scan'208,217";a="393678469"
Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga004.jf.intel.com with ESMTP; 25 Mar 2020 09:29:35 -0700
Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 25 Mar 2020 09:29:35 -0700
Received: from orsmsx108.amr.corp.intel.com ([169.254.2.172]) by ORSMSX159.amr.corp.intel.com ([169.254.11.47]) with mapi id 14.03.0439.000; Wed, 25 Mar 2020 09:29:34 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Simon Frost <Simon.Frost@arm.com>, Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] UEID where an instance is a group member
Thread-Index: AQHWAsKRdD+aXklc+0GMpNNrohEb0w==
Date: Wed, 25 Mar 2020 16:29:34 +0000
Message-ID: <C205FBA7-71A7-4987-AE82-DA855BF86B84@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.35.20030802
x-originating-ip: [10.255.229.179]
Content-Type: multipart/alternative; boundary="_000_C205FBA771A74987AE82DA855BF86B84intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/8cFefYE7paSOp7uneLMHv_FyGqk>
Subject: Re: [Rats] UEID where an instance is a group member
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: Wed, 25 Mar 2020 16:29:56 -0000

Is a GEID structurally different from a EUID? I think currently a EUID is either a 128-bit or 256-bit bstr. I assume the semantics of uniqueness differ.

From: RATS <rats-bounces@ietf.org> on behalf of Simon Frost <Simon.Frost@arm.com>
Date: Wednesday, March 25, 2020 at 8:47 AM
To: Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>
Subject: [Rats] UEID where an instance is a group member

We had an internal discussion in response to some changes in PSA which have elaborated the definition of an Instance Attestation Key (IAK) so that it may either be “unique to each device or a collection of identical devices”. The definition of the Identity claim is now a value that identifies the IAK. This has been done to support entity grouping for (some) privacy scenarios.

While we have an EAT Profile for PSA that uses a full set of custom claims, our intent has always been to be to migrate as many claims as possible to the standard once the RATS work is complete. Previously, there has been a direct analogy between arm_psa_UEID and the standard UEID. With this change though, we would have to move away from this. The current description of UEID makes it clear that it must be device world unique. There is some discussion (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations) of the group scenario, but the only statement about the claim situation is that “It will often be the case that tokens will not have a UEID for these reasons”.

In the privacy scenario, it is still desirable to have an entity identity claim, for use by a verifier or for general usage. The options seem to be:

a/ If the entity is unique, include an UEID claim, otherwise include a custom group claim. It seems a pity to encourage diversification between profiles.

b/ If the entity is unique, include an UEID claim, otherwise use a new standard GEID claim

c/ punt this problem out to the kid of the COSE wrapper. This would ignore any more general uses of group identities.

Of these, b/ (introduce a new standard GEID claim) seems to make the most sense and is the option we would propose to the WG.

Thoughts?

Thanks
Simon

Simon Frost
Senior Principal Systems Solution Architect, ATG, Arm
Mob: +44 7855 265691

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.