Re: [Ace] EST over CoAP

Hannes Tschofenig <> Tue, 15 May 2018 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F25D612DA2C for <>; Tue, 15 May 2018 07:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tOFELsF6arhm for <>; Tue, 15 May 2018 07:15:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3ACFA12DA28 for <>; Tue, 15 May 2018 07:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WqC6Et1otna1rK3G9MkBZwNPd8gktrUW1KQagycKV4c=; b=MQh+bmoDDqBogNVWHBaAuMx8W3W4n8IUES1gOD4gnoOayxCBxUi+fuyZIcTCmdoQyASWsJAzcjz9oW527FVgT/t7TyIPv6got9ttT+rXs5Zt4VAMp5vjjcQ+IFxKR0wYlIrgtYmqkCUAEc8HmOr5Gm5yXl30oJffwOdF3FM6sPQ=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 14:15:53 +0000
Received: from ([fe80::7c43:c1a5:4f69:5365]) by ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 14:15:53 +0000
From: Hannes Tschofenig <>
To: "Panos Kampanakis (pkampana)" <>, Mohit Sethi <>, "" <>
Thread-Topic: [Ace] EST over CoAP
Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwACEdrwAAEZULAAAAeJoQ
Date: Tue, 15 May 2018 14:15:53 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1392; 7:9TPJvHTEDfptqhycJRFGIrMi6rqFWNDxAvEy2S6eIZJ+M5DoZnjhin5kr9AX64X/i7EBjoRpIOoBF7RglBG1fSp1AtYQEVGl11pBFJvXbN2ncN5Q0bV5s0XGThplDdRNmiX02eTC0uqM7cKQMJYjM2SM4ntY7vy1ePzu7v/f7aPzcQ23IjJuDT/WayJCP+gJKnWFFxocWEqurqz4KBBRORRmHxbBcIFirf+2bXFCbMgDPts6cz1pypuWDj/wnohS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1392;
x-ms-traffictypediagnostic: VI1PR0801MB1392:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(180628864354917)(120809045254105)(95692535739014)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1392; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1392;
x-forefront-prvs: 0673F5BE31
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39380400002)(366004)(376002)(39860400002)(40434004)(189003)(199004)(53754006)(86362001)(6246003)(3660700001)(5250100002)(11346002)(446003)(102836004)(476003)(54896002)(606006)(3280700002)(6306002)(55016002)(5890100001)(53546011)(6506007)(316002)(25786009)(486006)(93886005)(2501003)(236005)(478600001)(8676002)(2906002)(72206003)(26005)(66066001)(3846002)(53936002)(5660300001)(74316002)(2900100001)(105586002)(110136005)(59450400001)(8936002)(7736002)(966005)(229853002)(81166006)(99286004)(97736004)(76176011)(186003)(551934003)(6436002)(33656002)(81156014)(68736007)(6116002)(9686003)(14454004)(7696005)(790700001)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1392;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: s4pI/SdTrvvcIA0vQ4LgG2ZQ3FZqLMzEYACHb1LrFKLHbs4XuM4+g8IV+KJUgGxBHNBmUHAdro2nMHfcixx0+TGKOHajZgacG46NRNJpv75V2X1hDXQgQScaF4qyN14egMeXa3qZJ+7fQiM5mSuKtUUICjqoArJ6ckeEAXdOQjOiM3VmXeOfA4bl1P32MKuf
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112C9B4B7B1C3ABFC475DE9FA930VI1PR0801MB2112_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1f5f94d7-99da-4296-6afd-08d5ba6e5e54
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f5f94d7-99da-4296-6afd-08d5ba6e5e54
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 14:15:53.2990 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1392
Archived-At: <>
Subject: Re: [Ace] EST over CoAP
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 May 2018 14:16:07 -0000

FWIW I would untangle the tamper resistance property from the lifetime of these keys.
You will want to issue new keys periodically anyway.

From: Ace [] On Behalf Of Panos Kampanakis (pkampana)
Sent: 15 May 2018 16:01
To: Mohit Sethi;
Subject: Re: [Ace] EST over CoAP

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.

From: Mohit Sethi []
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) <<>>; Hannes Tschofenig <<>>;<>
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?


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.


From: Ace [<>] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
Subject: [Ace] EST over CoAP

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see

-        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?


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<><>

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.