[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
- [Rats] UEID in EAT Kathleen Moriarty
- Re: [Rats] UEID in EAT Laurence Lundblade