IETF Logo Mail Archive

Re: [TLS] ITDA - IoT Device Authentication

Sankalp Bagaria <sankalp.nitt@gmail.com> Mon, 18 February 2019 01:38 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 97A91130E86 for <tls@ietfa.amsl.com>; Sun, 17 Feb 2019 17:38:09 -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 EiTXURtPV64H for <tls@ietfa.amsl.com>; Sun, 17 Feb 2019 17:38:07 -0800 (PST)
Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 E7825130E94 for <tls@ietf.org>; Sun, 17 Feb 2019 17:38:06 -0800 (PST)
Received: by mail-ot1-x341.google.com with SMTP id i5so25648844oto.9 for <tls@ietf.org>; Sun, 17 Feb 2019 17:38:06 -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=zIheLh3CCN4aD8aviI8TqKeETE6GNpc3FhQyW3Nvrfw=; b=m/SWN4QmIE4vkC+1exyB9jvz9soy/a9us8yXNHSEjUaEEZwy/abu5e2N2d/AukaF2k NBTdFm5TMsCMj+607l3i6ZHqJ5YSKAlM5RxPbKatQwnqZpbmCQ5RWrygNv2uVbapJxEd s8lNevLOP/fLPxKXCKOs86psAgAR/k8Ra5A5fDOdAhT27XWk3Fdx3oOglZ33tlFywHpx Q2ppKzDPpZWf6qKeOtpskVVWfwiH7P0TUhZvNwNvN+hhru1ZTnYLwuM3oOhbDQRGUGBC Q3KjELQ6Z3rvI5o96tUIF3oUHERtxW8zXBWimH13zzlm/ypa1QeoX7LJbDCExWHAw1DF /orw==
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=zIheLh3CCN4aD8aviI8TqKeETE6GNpc3FhQyW3Nvrfw=; b=LRPdvcxSYUKXe0jiqiPgE8rA+W7BPF5GHUw1BK34pXeb7a2+gGOf100Rr5PomiNYMD 9FomrG7k79fO5mT+N75JBm1rlWw0bAioDjSc8SM+53FTafaLuwc+QMyejXO2E0UCefMK j8ypjEDy+UY7StZdDbDBvjeU+Lbgh2niHmCYU1Ucv7weuTIg7QmVux4BMIlBV0hOxyiV S6nHswsH9lNoqnr0asudeThKQbniRWeXqcN6bs76+gfFhKrJtkIUBIGh6PVOa+CRiZEH 0rgRYl1uJKW2csgQGS/SR3vcgYXWsRO50w5cBfdy2coZlduArXVU2rSF1eQ//QReqY8p b7qQ==
X-Gm-Message-State: AHQUAuYXy30FD7PPcq1xivTXRC91pIhQ25vtOn/Br+WfBtqBMuP7fCQt ltRhR4sVTLjn/rS7LoKZmJdCrM586gmdyNJUlbw=
X-Google-Smtp-Source: AHgI3IYmmlaxzph/GYzyBZFRm+uY/EU3CWuSssQyX3kDuaXygDoYwYE9HBZnxwo2UB2uUbauv7Bg09bxAUUPu/8o2Io=
X-Received: by 2002:a9d:130:: with SMTP id 45mr12925383otu.355.1550453885900; Sun, 17 Feb 2019 17:38:05 -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>
In-Reply-To: <DBF8D4B0-0E1E-4C97-9923-B88FBC7AE823@akamai.com>
From: Sankalp Bagaria <sankalp.nitt@gmail.com>
Date: Mon, 18 Feb 2019 07:07:53 +0530
Message-ID: <CAPZZOTgh9ODmZOBeUrk85xzYSe-jmeQ46JXd_+ZkrRXCmgVx1g@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="0000000000001c1b210582212d38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/V4veUG2tra31jcy-EZ_6dq0R-gc>
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 01:38:10 -0000

Hi,

Servers are usually more secure and can store challenge/ response pairs for
all clients it connects with in Oracle.

Remote IoT devices can be attacked physically and keys retrieved from them.
To prevent this, costly and complex tamper proof cryptographic circuitry is
used.

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.

Thanks and Regards,
Sankalp Bagaria..



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

> I would also be concerned about adding a "new" scheme that easily
> functions as an oracle.
>
> On 2/16/19, 8:01 PM, "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote:
>
>     Sankalp Bagaria <sankalp.nitt@gmail.com> writes:
>
>     >We propose that the server is authenticated using X509 certificate in
> a TLS
>     >1.3 like protocol. The Server sends 32-byte Challenge. Client replies
> by
>     >sending 32-byte Response.
>
>     Something very similar to this already exists in the form of
> CHAP/MSCHAP over
>     PEAP/EAP-TLS/EAP-TTLS.  It's supported by every Radius server and vast
> numbers
>     (probably billions) of clients.  To compete against this huge
> installed base, any
>     new proposal would have to be pretty spectacular...
>
>     Peter.
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org
>     https://www.ietf.org/mailman/listinfo/tls
>
>
>

v2.23.0 | Report a Bug | By Email