Re: [Rats] 802.1AR device identity

Ira McDonald <blueroofmusic@gmail.com> Thu, 11 March 2021 19:13 UTC

Return-Path: <blueroofmusic@gmail.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 630E73A0E1E; Thu, 11 Mar 2021 11:13:40 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V0wvC-OYwXMx; Thu, 11 Mar 2021 11:13:38 -0800 (PST)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277393A0E1A; Thu, 11 Mar 2021 11:13:38 -0800 (PST)
Received: by mail-vk1-xa36.google.com with SMTP id p8so723604vki.7; Thu, 11 Mar 2021 11:13:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=adG6uzpbviDnP1EzUSUu63ppaq/APxuHaE8PTZk2J7Q=; b=ntLRAk/NT2zTR8hBaUMUzjOHtPNLDw0eqD3xQtWoIFvpv5HIxSTLLRBwMusNAOtbWs MOXwqYalbtdz+5tdC8GG2UKAFaEJx1E2Y0KNSIZhV507DUKkH/DSGIDiIshwfFp1CM+O c4q53UipVV72npWcM+J+HsFGYSHSSF1b7B5PNLN3lJb0NaTvDuYN1F3leZiLXbMKflil 1ad/wK8ymRSedqeSIyPkMRjT7l3MW1TEwqbzZPshzUsTbe0o8/VxBhu/6tI0W/VS8sNi Y0SMOH5MY5n4ydCIQtdb6IBjEXxtYB1E53YJEWgJnBOS7En3Bg8sW/BUgizYBrPScp51 1RQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=adG6uzpbviDnP1EzUSUu63ppaq/APxuHaE8PTZk2J7Q=; b=onRDBCa/JH2b0MGCS0k96NBFnoZS7ccWk2vUGKn2skzw3YVQFmeZaTLcJHQN6YdNmJ DFYVddvSfVl9sm3KE28kXGuRzgbX7GydV6OIssS6SGw/xq/4QR+ZJBbHLaYR3kk9rjg3 2UyTnfa/fcEdqtAAE5IzotWQMYDIzLxhfVYSheAQaVxJPWZqkmibGwfUTzqxLGhjrAYi UXWXVT2DUp5V51V68qN+aZKxLgCKLDMXBTQfLK1Fq4SoadJ+OPMags/QhDIKjRMpL8mJ PdMcwW/KPTry9t8YPPHsBPzgNFXcjEf1AZfhFmxcqTFl2riOIBqKa57rkKzDX25oTLqQ sIoQ==
X-Gm-Message-State: AOAM531nW0OHyn1H4xUMqQk9rnAKrX7anICWB7R5ULnPZZU7yulVcKR2 IZF9AFpzVamF6dmszAKj5KXdUtLmHZW6zYAR5XI=
X-Google-Smtp-Source: ABdhPJy4CPs4CmMCobjFfPHtEt4QAgZ0UPAj4wkZlPWscf+aNGKq+3SlLAb7iq/R10JOfZFERWa7HhrdpERXBXjsKVw=
X-Received: by 2002:a1f:50c5:: with SMTP id e188mr5880706vkb.19.1615490015295; Thu, 11 Mar 2021 11:13:35 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Thu, 11 Mar 2021 14:13:24 -0500
Message-ID: <CAN40gSsCbjpVuCQwsWWjGwfL=cARHcAa0ZPsm+sk8H=9_otZUw@mail.gmail.com>
To: Laurence Lundblade <lgl@island-resort.com>
Cc: "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>, Guy Fedorkow <gfedorkow=40juniper.net@dmarc.ietf.org>, Eliot Lear <lear@cisco.com>, "iotops@ietf.org" <iotops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007ffbe305bd4794a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ktbt4nk7C26NNlq_QS23Y5MMTOY>
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: Thu, 11 Mar 2021 19:13:40 -0000

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/

Cheers,
- Ira



On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <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://tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt> 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
> https://www.ietf.org/mailman/listinfo/rats
>