Re: [Ace] EST over CoAP

Mohit Sethi <mohit.m.sethi@ericsson.com> Wed, 16 May 2018 08:08 UTC

Return-Path: <mohit.m.sethi@ericsson.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989AA12D77B for <ace@ietfa.amsl.com>; Wed, 16 May 2018 01:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 IOmbR-SDnprt for <ace@ietfa.amsl.com>; Wed, 16 May 2018 01:08:21 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FDC1201FA for <ace@ietf.org>; Wed, 16 May 2018 01:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526458099; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fHdDO9dAhi9GxBtlLOdcbvFrYZtk01NKAmJCkSdEUiw=; b=fJ5istje8/54bXAHeI8Hb0JKCOZQHvHUhVfnLGqufQQmmPfV5LDztfOZFa+yv3CO lCQsMikql7gkidVwPilKYidg92TxeSkWskrjSQU8YropHaT4uGJwWRVzzCJwf19b gPHmKVWFJiwJfl0kDxVqyj8bqOrlvRhuOzcu+9lvZ7M=;
X-AuditID: c1b4fb2d-a6b079c00000050d-51-5afbe6f3c5b0
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.C8.01293.3F6EBFA5; Wed, 16 May 2018 10:08:19 +0200 (CEST)
Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.382.0; Wed, 16 May 2018 10:07:47 +0200
Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 6F7C148085C; Wed, 16 May 2018 11:07:47 +0300 (EEST)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 1B70248070F; Wed, 16 May 2018 11:07:46 +0300 (EEST)
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>
References: <VI1PR0801MB21122D93F906F952E5E85C87FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <a4d27053f1d2431abee07d2597e14972@XCH-ALN-010.cisco.com> <068f2690-e1a1-b225-463a-4048e06365af@ericsson.com> <c478ad350e0b416eaffbdd526fd3616e@XCH-ALN-010.cisco.com>
From: Mohit Sethi <mohit.m.sethi@ericsson.com>
Message-ID: <8f5dc6ee-d6e1-9a9d-0e23-f7056f743229@ericsson.com>
Date: Wed, 16 May 2018 11:07:46 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <c478ad350e0b416eaffbdd526fd3616e@XCH-ALN-010.cisco.com>
Content-Type: multipart/alternative; boundary="------------EDC17B96B51870F67F666F03"
Content-Language: en-US
X-AV-Checked: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdQPfzs99RBjOPqlh8/9bDbPHlwipG ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSujd8YytoK9hxgrDlxfzdTAeG4KYxcjB4eE gIlEy6SYLkYuDiGBI4wSr3/sY4FwdjBKPHr9kh3C2cwosa3jNhuEs5BRYsPkqUBlnBzCAgoS y5r/M4PYIgLhEg0fJzBCFPUwSTw5OZsRJMEmoCfRee44WBGvgL3Ekgu32UFsFgFViYnHz4HZ ogIREvfOf2KDqBGUODnzCdgCTgFXid0vJ7CC2MwCYRLvbh5jh7DFJW49mc8EYksIKEssaFkE tktIQF1ia8cBxgmMQrOQjJqFpH0WkvZZwCBgBjrpwdYyiLC2xLKFr5khbH2J63fus0LY8hLN W2czL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGC8Ht/zW3cG4+rXjIUYBDkYlHl77 J7+jhFgTy4orcw8xSnAwK4nwZvIChXhTEiurUovy44tKc1KLDzFKc7AoifPqrdoTJSSQnliS mp2aWpBaBJNl4uCUamCc9t3o3VTDY3FrbycpOP98xLBeYXE3u0M+1/0Yed1ZzAu3vLD8bn5O 3O560e8PCxvtX83nOOo+obJz2rIb5+y6oi2t1VnMEzp/Wlgyzoj/tV/Y8nLNVNfEmp7MX8v1 T4UkHW7UnbPq2vRV12SPy/s0JV6ctjRr05c/qeeuXDFarum+Kp1zcv0KJZbijERDLeai4kQA KR7mbpMCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/onihbvdcKZoJWL4-OJO9G93kWBY>
Subject: Re: [Ace] EST over CoAP
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2018 08:08:25 -0000

Hi Panos,

I wonder what kind of devices you have in mind? On one hand, the devices 
are constrained enough not to have resources for generating 
cryptographic quality randomness. But they somehow have support for 
tamper-resistance identity protection? Is it cheaper to have 
tamper-resistance? And is it somehow more energy-efficient?

I understand that generating strong identities and storing them securely 
are different issues. But I would be interested to learn about IoT 
devices that have tamper-resistance storage but no possibility of 
generating cryptographic quality randomness. Also, what protocols do you 
think the devices would use for authenticating these identities?

--Mohit

On 05/15/2018 05:00 PM, Panos Kampanakis (pkampana) wrote:
>
> Hi Mohit,
>
> These priv/public keypairs+cert are provisioned and used on the 
> endpoint as identity for authentication. If tamper-resistance is not 
> supported on the endpoint, the keypairs could be reprovisioned more 
> often than the traditional cert lifetime as the server-side key gen 
> transaction does not incur significant workload to the endpoint itself.
>
> Rgs,
>
> Panos
>
> *From:*Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
> *Sent:* Tuesday, May 15, 2018 1:37 AM
> *To:* Panos Kampanakis (pkampana) <pkampana@cisco.com>;; Hannes 
> Tschofenig <Hannes.Tschofenig@arm.com>;; ace@ietf.org
> *Subject:* Re: [Ace] EST over CoAP
>
> Hi Panos,
>
> How do you intend to use these server generated keys once they are 
> provisioned onto the device?
>
> --Mohit
>
> On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:
>
>     Hi Hannes,
>
>     To address your question about server-side key gen, below is the
>     explanation we have put in the draft already and will be in the
>     next iteration
>     /~~~~~~~~~~~~~/
>
>     /   Constrained devices sometimes do not have the necessary
>     hardware to/
>
>     /   generate statistically random numbers for private keys and DTLS/
>
>     /   ephemeral keys.  Past experience has shown that cheap endpoints/
>
>     /   sometimes generate numbers which could allow someone to
>     decrypt the/
>
>     /   communication or guess the private key and impersonate as the
>     device./
>
>     /   Studies have shown that the same keys are generated by the
>     same model/
>
>     /   devices deployed on-line./
>
>     //
>
>     /   Additionally, random number key generation is costly, thus energy/
>
>     /   draining. Even though the random numbers that constitute the/
>
>     /   identity/cert do not get generated often, an endpoint may not
>     want to/
>
>     /   spend time and energy generating keypairs, and just ask for
>     one from/
>
>     /   the server./
>
>     //
>
>     /   In these scenarios, server-side key generation can be used.  The/
>
>     /   client asks for the server or proxy to generate the private
>     key and/
>
>     /   the certificate which is transferred back to the client in the/
>
>     /   server-side key generation response./
>     /~~~~~~~~~~~~~/
>
>     This is a need that we have heard from customers at Cisco.
>
>     About the proxy-Registrar question, we already have made the
>     change in the working copy of the draft as well. We no longer call
>     this functionality proxying, but instead use the concept of the
>     registrar that terminates the connection and establishes the next
>     one.
>
>     We didn’t add any new features in the doc after removing the BRSKI
>     stuff.
>
>     If you want an early preview to comment on, we can share the
>     repository with you.
>
>     Panos
>
>     *From:* Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hannes
>     Tschofenig
>     *Sent:* Monday, May 14, 2018 5:05 AM
>     *To:* ace@ietf.org <mailto:ace@ietf.org>
>     *Subject:* [Ace] EST over CoAP
>
>     Hi all,
>
>     At IETF#101 Peter presented a list of open issues with the EST
>     over CoAP draft, see
>
>     https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00
>
>     -Operational parameter values
>
>     -Server side key generation using simple multipart encoding
>
>     -Explain trust relations for http/coap proxying
>
>     I have challenged the usefulness of the server-side key generation
>     during the meeting but in general I am curious where we are with
>     the document. It would be great to get it finalized. It appears
>     that we are adding new features and therefore will not be able to
>     complete the work in any reasonable timeframe.
>
>     So, do we have a plan for how to complete the document?
>
>     Ciao
>
>     Hannes
>
>     IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged.. If you are not the
>     intended recipient, please notify the sender immediately and do
>     not disclose the contents to any other person, use it for any
>     purpose, or store or copy the information in any medium. Thank you.
>
>
>
>
>     _______________________________________________
>
>     Ace mailing list
>
>     Ace@ietf.org <mailto:Ace@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/ace
>