[Rats] UEID in EAT

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 11 September 2020 12:26 UTC

Return-Path: <kathleen.moriarty.ietf@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 600DB3A0FA4 for <rats@ietfa.amsl.com>; Fri, 11 Sep 2020 05:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.603
X-Spam-Level:
X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lDVOmV108pvH for <rats@ietfa.amsl.com>; Fri, 11 Sep 2020 05:26:26 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 B45023A0FA1 for <rats@ietf.org>; Fri, 11 Sep 2020 05:26:25 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id ay8so9716971edb.8 for <rats@ietf.org>; Fri, 11 Sep 2020 05:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0wvIVeCm8iydyBq2UcPsHAEflUTO5Bzn8Dj1HJNu4ok=; b=vdwpTMBWiG2yFLpghX8408oWl+LGwGc/g3FMKqFP+zZdLtdfGMwKj5QBLAI62oc6N2 sPhRE8gC+YBLprAf3JE+qHja+3V1vl4lOBpvQFU7zpYHAz5CXBH8BoKriYw41r+Nu1tK Et/ydlnzJ0JRPlY3n6C4vvDwUa4OU71grI/cd/q29Ze4wH5hhOozGOV/sinlqql7mtNO bXinrcPppLtCDSC73/ZfDuCLJHkZUwYxMnVfskkrdegJzSlPzTrdrmym3Zm7TU3mmi36 0gzuklOnMOJ4PZbnFM01vWuoFj+/deCPYtpz4oTm+55o/+XgDyFZ5NzM/mA+IV+TrkZP 6/2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0wvIVeCm8iydyBq2UcPsHAEflUTO5Bzn8Dj1HJNu4ok=; b=ifh52HP9e73Q9kteKbrcukguY11LMLw10ZWHrV8zUnqlvgyBp2uTR3iIkleKHALi/3 3/cL+MTvM3GPyOvXgI3qgXKwyffZRk7t5UQQuWU0euNV79SiNcy3fjims5i3DvF3SGSm wBrNIVg+Kw8cjDufbpXQzQgXzsHBbCre94ZOxH4St22zhjahe4wFxym4LY4u0yTtE4Yj 11IgtzhP89XV7EXZKEjqvDRa4CVpY+fDdWBIAijk7BfQegitX1p7HVQw/xfg0nUm4k12 kb2hjQeh+ZJvjEEHJF45NvMfNh3USjE8q4HqoWDU0zKo7QFpxU+oNzkPcKtfBdokMjGV UIdA==
X-Gm-Message-State: AOAM532K87i/5INObUOqT7roUi7n1qei1WFPdj2S3PtpBKEZWJWqdUEc 1PEDhPwjGrzIKjXEuM1cZqDq0kbpM9SXgt0k4ncWp7ITuVc=
X-Google-Smtp-Source: ABdhPJwYLaAf+dyQzY0hqdtxERT1kre+Heb0OQ7PmFBKR/l23qqp84dG6f4NFozv7cQEuz8fGU2msS/S6QwsCvX/Cd4=
X-Received: by 2002:aa7:cad3:: with SMTP id l19mr1614194edt.352.1599827183993; Fri, 11 Sep 2020 05:26:23 -0700 (PDT)
MIME-Version: 1.0
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 11 Sep 2020 08:25:47 -0400
Message-ID: <CAHbuEH6RrPYAGOKq_JvDmS1ZvP51BfWr_GpJ-Gd+r0yXuUWw-A@mail.gmail.com>
To: rats@ietf.org, Juan Carlos Zuniga <j.c.zuniga@ieee.org>
Content-Type: multipart/alternative; boundary="0000000000000106e405af08cb88"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/xzMtpujSt5D5xnrfKRKxmUs6lu0>
Subject: [Rats] UEID in EAT
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, 11 Sep 2020 12:26:28 -0000

Hello,

Someone had pointed out a possible problem with the UEID, so I dug a little
and wanted to poke at it.  In looking at the UEID, it relies strictly on
the collision rate for hash generation, setting the number of bits high
enough for the very large number of devices that could be assigned an
UEID.  It also states that the UEID never changes.

The question posed to me privately is that there seems to be a conflict in
the two sections on this proposal.  How do you ensure uniqueness across
vendors?

Going back to an example, collision attacks have been successful even
though they are highly sophisticated.  The earliest example was in one of
the exploits used in the STUXNET attack.  That example resulted in
deprecation of older hash functions.  Minimally, some recommendations
should be provided on hash functions, pointing to a registry of maintained
recommendations.  The problem across vendors is also interesting in that
you can track this within a vendor, but how do you ensure uniqueness across
vendors?

I am copying Juan Carlos as he and others did work within the IEEE that
could be very useful here.  They standardized a method to produce
randomized MAC address values.  While vendors had their own method, privacy
was not assured as it was possible to detect what vendor generated a
particular value due to variances in their algorithms.

IEEE has also moved to a method to allow for changing MAC addresses for
increased privacy.  Should EUID remain a constant value or be able to
change over time?  There's likely value in allowing change over time for
privacy.  You can find IEEE information on the problems associated with
changes over time, but usually that type of work can lead to answers on how
to make it work.

I am hoping Juan Caros may be able to assist a bit here and we can learn
from IEEE's experience and save a bit of time.

Thank you,
Kathleen

-- 

Best regards,
Kathleen