IETF Logo Mail Archive

Re: [TLS] ITDA - IoT Device Authentication

Sankalp Bagaria <sankalp.nitt@gmail.com> Mon, 18 February 2019 03:00 UTC

Return-Path: <sankalp.nitt@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37D130EB0 for <tls@ietfa.amsl.com>; Sun, 17 Feb 2019 19:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IEIaEEA0UaH5 for <tls@ietfa.amsl.com>; Sun, 17 Feb 2019 19:00:08 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 374861295EC for <tls@ietf.org>; Sun, 17 Feb 2019 19:00:08 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id g1so25838402otj.11 for <tls@ietf.org>; Sun, 17 Feb 2019 19:00:08 -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=qB0Uguyr+YiLJCY9RufVbuZlfOUU94LRYcxNOd/Qsf0=; b=a6t4N1cJg2g7AqOFRO/k4iWj6qCI7x/SZ3C6DAUwHiFWz7VLyP+RnS8wln9rI06NIt LuJ13TToDtJrsNAPPPBz3tVgEIrSFyQVOGxhZ0NFW2vFEka/OPVEVu4J1eaM0nP2PPwo wzPERSCV8KikYZHfByWPOgKaZxUeazw8pmZA1O73F1C8VcffSD8sK/HrIxcwobLCPIjZ 6JbE8D2o7dVzQm672vsXsJXye42Hh8YsP92ZX5QggAnHJaxecPEj49/dVnCT4jEbGJJM sCtpS+4uMMeZmeXi9Gl3HGSJkxINSG1q4mxipfYgr1RNm07S5KGfUlo33pRMHH0OMNo6 6m1Q==
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=qB0Uguyr+YiLJCY9RufVbuZlfOUU94LRYcxNOd/Qsf0=; b=QbhnUo+7IOaKvdA2eB0RLm63Gv3II+5OHhknVsjUkxeRQhrtr/oN/4WawsVtmrj6Jj lX3SusN7nhGAAkEwGkPzottw8hCr02ItHmgNWnS4SP5lA5CBiDK7AJvxFN17ugNqd+Xw a1BMGD3GM9XLJ8Bow35HUJsjwY5x1DoDM6gp90VEDY9FIzqVuFVZ0vrcrmKOEAX4Pm6T yfj41vQkvBYZ1RCdyc24wH51snz9U+Dj7V9WMTJL6ISJNLKCZzgV73KuRsWOvFQS8M6s YWNCnf8MPnVx9v4TDGThGgK6TSnQ5XBMq0HCTzNWR0GNtc1Uj+bb7tQDmN7g+fMT3h/5 7yQQ==
X-Gm-Message-State: AHQUAuYXi5bvxhg+zfiOlGpp+fLAmVuNKbutkwrdYC+5z6zVsOu4aZUC VUKWpECZ4oIJPYWkBz3WmKuX+4I3jB7UKv9XxKU=
X-Google-Smtp-Source: AHgI3IbREYhLHZRprWSMTJXh05oe1pPibcO2Yxr2sbhP1loOQvx7qkQIHcJ9r20rDvE5WXVYMacRGhIRThQX//zrwSs=
X-Received: by 2002:aca:f2c5:: with SMTP id q188mr3318311oih.150.1550458807235; Sun, 17 Feb 2019 19:00:07 -0800 (PST)
MIME-Version: 1.0
References: <CAPZZOTgmiDVxJmEYq7J6amgCaWrdcBHDjww=ZjrVd0m-5nbsjg@mail.gmail.com> <1550365230138.15157@cs.auckland.ac.nz> <DBF8D4B0-0E1E-4C97-9923-B88FBC7AE823@akamai.com> <CAPZZOTgh9ODmZOBeUrk85xzYSe-jmeQ46JXd_+ZkrRXCmgVx1g@mail.gmail.com> <D7C57420-DAAD-4DD6-9F1A-1A357270CC0E@akamai.com>
In-Reply-To: <D7C57420-DAAD-4DD6-9F1A-1A357270CC0E@akamai.com>
From: Sankalp Bagaria <sankalp.nitt@gmail.com>
Date: Mon, 18 Feb 2019 08:29:54 +0530
Message-ID: <CAPZZOTji+nMyod9GZuF-BZERuN=7vTomVDq+j6Zwijzqn507yw@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, tls@ietf.org, "T2TRG@irtf.org" <T2TRG@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000071b99a05822252e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/e9UeVZaoa5jzSCTGrMZhD6TcT9U>
Subject: Re: [TLS] ITDA - IoT Device Authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 03:00:10 -0000

Hi,

I looked in net for Oracle and found the following limitation. PUF depends
on physical variations of chip at time of manufacturing and after
processing, should function as a better Oracle than any other algorithm.
Limitations (as per wikipedia)Edit
<https://en.m.wikipedia.org/w/index.php?title=Random_oracle&action=edit&section=2>

According to the Church–Turing thesis
<https://en.m.wikipedia.org/wiki/Church%E2%80%93Turing_thesis>, no function
computable by a finite algorithm can implement a true random oracle (which
by definition requires an infinite description because it has infinitely
many possible inputs, and its outputs are all independent from each other
and need to be individually specified by any description).

Thanks and Regards,

Sankalp Bagaria.

On Mon 18 Feb, 2019, 7:15 AM Salz, Rich, <rsalz@akamai.com> wrote:

> Do you know what I mean by an oracle?
>
>
>
>    - PUF provides a cheaper alternative to complex and expensive
>    cryptographic circuitry. As keys need not be stored at the IoT device. When
>    PUF receives a challenge from server, it calculates response and sends it
>    to server.
>
>

v2.23.0 | Report a Bug | By Email