Re: [Rats] UEID where an instance is a group member
"Smith, Ned" <ned.smith@intel.com> Thu, 26 March 2020 21:58 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 CC35E3A087B for <rats@ietfa.amsl.com>; Thu, 26 Mar 2020 14:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 861_nveO7UEe for <rats@ietfa.amsl.com>; Thu, 26 Mar 2020 14:58:34 -0700 (PDT)
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 02FD63A073D for <rats@ietf.org>; Thu, 26 Mar 2020 14:58:32 -0700 (PDT)
IronPort-SDR: gQ4sk6h/w4e5g7V6ccEatQ9IqcKQuw1TjJjRmN6bV6aYmuJQ+bwPCLGUJ9iqQ7EVWUlV+tk1G/ p2APPjVv9G7Q==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 14:58:31 -0700
IronPort-SDR: Ff7zCwBvLlIaRsdTOJLF0mzygD2xk2+LwBTLyxFjOZTxp/8ExjDxV26vXU5n/0afvP8zofgb6p Oz1oma3pMicQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.72,309,1580803200"; d="scan'208,217";a="266010832"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga002.jf.intel.com with ESMTP; 26 Mar 2020 14:58:31 -0700
Received: from orsmsx108.amr.corp.intel.com ([169.254.2.172]) by ORSMSX106.amr.corp.intel.com ([169.254.1.230]) with mapi id 14.03.0439.000; Thu, 26 Mar 2020 14:58:31 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>
CC: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] UEID where an instance is a group member
Thread-Index: AQHWAsKRdD+aXklc+0GMpNNrohEb06hZ+cQAgAACJwD//6Z5AIAB9zeA///UPgA=
Date: Thu, 26 Mar 2020 21:58:31 +0000
Message-ID: <4F616CB6-6F42-43CE-94A6-ADD155900535@intel.com>
References: <C205FBA7-71A7-4987-AE82-DA855BF86B84@intel.com> <C3A707FF-4AF1-4E0A-BABB-8EE2F52A2D2B@island-resort.com> <33f462bb-979e-80cc-9c27-af1e3b77d5e6@sit.fraunhofer.de> <7C94FAC2-AADB-4397-A50D-4FBB11EFCABA@intel.com> <A4C4246B-400F-4C38-839C-6747620C35C2@island-resort.com>
In-Reply-To: <A4C4246B-400F-4C38-839C-6747620C35C2@island-resort.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.252.138.232]
Content-Type: multipart/alternative; boundary="_000_4F616CB66F4243CE94A6ADD155900535intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Jr9YuNXubecCWxJ9Qj6xLFl0dWs>
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: Thu, 26 Mar 2020 21:58:42 -0000
Laurence, The point I was making is that EUID and keyID are not always synonymous. In a case where a device only ever has one key, then maybe they are synonymous. Otherwise, they should be treated differently. My assumption is UEID identifies an entity (device) while keyID identifies a key. A GEID has the same semantics in terms of being an entity identifier (vs. key identifier) only the GEID points to an entity that is pseudonymously named. I agree it might be a useful to write a draft that defines how attestation for privacy sensitivity should be accomplished. The other observations seems accurate but I don’t see how they relate to the discussion about whether entity identifiers differ from key identifiers. Thanks, Ned From: Laurence Lundblade <lgl@island-resort.com> Date: Thursday, March 26, 2020 at 10:35 AM To: "Smith, Ned" <ned.smith@intel.com> Cc: Henk Berkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org> Subject: Re: [Rats] UEID where an instance is a group member The claims giving characteristics of the device should really just focus on the characteristics of the device, not the scheme for securing the evidence and results. Seems like overloading could result in trouble. For example, you need to change the grouping scheme because of some manufacturing problem, but you can’t because you are using it to represent some type or model info. Or maybe there’s a proxy necessary for securing attestation evidence. It would be best if it didn’t need to look into and/or modify the claims. Here’s a few schemes I think are likely to get used to secure evidence and results: * Basic flat per-device public key * Some X.509 hierarchy that may have X.509 certs carried in COSE headers * ECDAA and other variants of DAA that may have other things in COSE headers * Group keys like FIDO, Android and this proposal * Symmetric schemes, either per-device or group * TLS (particularly for attestation results) * Other new crypto protocol... COSE, JOSE, TLS, CMS and such all provide headers / parameters to carry things like key IDs to make all of these schemes work. Using UEID for the key ID for per-device keys is probably mostly OK because it is exactly using the semantics of the UEID. There’s not really any overloading. GEID used for a key ID and something else would be overloading. Better to clearly define separate claims for device types, models and such. I’d suggest defining a group key ID header for COSE (and JOSE) and using that instead of inventing the GEID claim. It would be even cooler and more useful to write a draft and standardize privacy-preserving attestation signing for COSE. It would be really beneficial for lots of people doing attestation that need to solve the privacy problem. Maybe FIDO and Android would eventually adopt it someday. If using the group key ID header, you’d leave out the UEID, so the number of bytes transmitted is the same (if you put the UEID in you’d break the privacy preservation). Keeping claims separate from security header parameters also keeps the SW stack simpler and cleaner. To verify typical COSE: - Parse the COSE headers to get the key ID and look up the key - Verify the signature and get the payload - Decode the sig-checked claims in the payload If you depend on the claims to verify the signature: - Decode the COSE structure to get the unverified payload - Decode the unverified claims to get the key ID and look up the key - Verify the signature and get the payload - Decode the sig-checked claims in the payload again LL On Mar 25, 2020, at 11:34 AM, Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote: It seems the purpose for using group ID (GEID) instead of a device ID (UEID) is for privacy reasons. UEIDs can be used to track device instance. This violates the pseudonymity/unlinkability requirement (https://tools.ietf.org/html/rfc6973#page-18). Therefore, if the device is operating in a privacy protected mode it might opt to use a GEID instead of a UEID as its identity claim/evidence. Keep in mind that keyID is also potentially privacy sensitive. Therefore, the keyID in privacy sensitive mode should refer to a privacy preserving / group key. For example, in FIDO there is support for DAA keys (I think?). The use of identifier claims and key IDs should be consistent with the privacy protection requirements. Either GEID is a privacy preserving equivalent to UEID (and a group attestation key is used to attest when in privacy protected modes). Or key IDs double as identifiers which seems to suggest UEID and GEID are unnecessary. However, since a device may have multiple keys over its lifetime (and therefore multiple key IDs) the value of identifiers (UEID / GEID) being distinct from key IDs is that the device / group identity persists even though keys are revoked/replaced/refreshed. -Ned On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org> on behalf of henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>> wrote: Hi Laurence, potentially, I just realized, it could serve the purpose of matching the Authenticator Moodel of a FIDO Authenticator and therefore might help the peer that the Atttester is talking to understand the format it has to expect being incoming based on the additional input of a FIDO Metadata-Service (aka the Authentcator-Model that is called, IIRC?). Any structure of that kind would help a Verifier to better... "guess" (well.. it probably is the output of some kind of negotiation), whether it is, e.g. FIDO or RIV? Viele Grüße, Henk On 25.03.20 17:46, Laurence Lundblade wrote: A GEID of similar structure to a UEID seems like a possibility, but what exactly is purpose of such a GEID? What does the RP do with it? What does the verifier do with it? An RP will use the UEID to track the unique, specific device. That is its clearly stated purpose. In some designs, a verifier may use the UEID to identify the verification key, but that is not the UEID’s purpose. It a useful side-effect. If the purpose of a GEID is solely for the verifier to identify the verification key, then I don’t think it is should be a GEID. It should be key id. So for me this kind of hinges on what a GEID will mean for the RP. What are the groupings it gives and how are they meaningful to an RP? LL On Mar 25, 2020, at 9:29 AM, Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com> <mailto:ned.smith@intel.com>> wrote: 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<mailto:rats-bounces@ietf.org> <mailto:rats-bounces@ietf.org>> on behalf of Simon Frost <Simon.Frost@arm.com<mailto:Simon.Frost@arm.com> <mailto:Simon.Frost@arm.com>> *Date:*Wednesday, March 25, 2020 at 8:47 AM *To:*Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com> <mailto:lgl@island-resort.com>>, "rats@ietf.org<mailto:rats@ietf.org> <mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org> <mailto: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 betweenarm_psa_UEIDand 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. _______________________________________________ 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 _______________________________________________ RATS mailing list RATS@ietf.org<mailto:RATS@ietf.org> https://www.ietf.org/mailman/listinfo/rats
- [Rats] UEID where an instance is a group member Simon Frost
- Re: [Rats] UEID where an instance is a group memb… Smith, Ned
- Re: [Rats] UEID where an instance is a group memb… Laurence Lundblade
- Re: [Rats] UEID where an instance is a group memb… Henk Birkholz
- Re: [Rats] UEID where an instance is a group memb… Thomas Fossati
- Re: [Rats] UEID where an instance is a group memb… Simon Frost
- Re: [Rats] UEID where an instance is a group memb… Smith, Ned
- Re: [Rats] UEID where an instance is a group memb… Laurence Lundblade
- Re: [Rats] UEID where an instance is a group memb… Smith, Ned
- Re: [Rats] UEID where an instance is a group memb… Laurence Lundblade
- Re: [Rats] UEID where an instance is a group memb… Smith, Ned
- Re: [Rats] UEID where an instance is a group memb… Henk Birkholz
- Re: [Rats] UEID where an instance is a group memb… Simon Frost
- Re: [Rats] UEID where an instance is a group memb… Thomas Fossati
- Re: [Rats] UEID where an instance is a group memb… Laurence Lundblade
- Re: [Rats] UEID where an instance is a group memb… Laurence Lundblade
- Re: [Rats] UEID where an instance is a group memb… Laurence Lundblade
- Re: [Rats] UEID where an instance is a group memb… Smith, Ned