Return-Path: 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 6F4C5127241 for ; Mon, 14 May 2018 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3KXnrWswxR_y for ; Mon, 14 May 2018 06:58:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D8D1241F3 for ; Mon, 14 May 2018 06:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16156; q=dns/txt; s=iport; t=1526306308; x=1527515908; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Qe/nVXw+6hHQMW1dPryrojU3NIGBsVFwx0EV13b7u/I=; b=K3y21ms6dxs6zLfuBmKk8Dw/0Fro115I1daFPif+8mNrHxPakM79JCBH sNhoT0hGEuR9Xt6aVwXute3vuPtUYXsncoFmTSrZcVaLrXRmoJvNB4hXP IKh5CTizF1+gtBhn1wpq7eK9FjOTBIsIcBIKl9BT3yvghI4VXTDGmRg0P o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAAC9lfla/4gNJK1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTUsrYXsoCotsjG6BeYEPjjuEdxSBZAslhEcCgxEhNBg?= =?us-ascii?q?BAgEBAQEBAQJsHAyFKAEBAQQtQwIXAgEIEQQBASgHMhQJCAEBBAEJCQiDHYE?= =?us-ascii?q?bZA+sT4g9giIFhyh9gVQ/JWqDC4JvIgIDgSEJAQgKAQlMhR4Chx+JaoctCQK?= =?us-ascii?q?FZYU5gymBPhqDS4dUiVWGZwIREwGBJAEcOGFxcBU7gkODMQECh1yFPm8MjiO?= =?us-ascii?q?BH4EYAQE?= X-IronPort-AV: E=Sophos;i="5.49,400,1520899200"; d="scan'208,217";a="114205946" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 13:58:23 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4EDwM3q008469 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2018 13:58:22 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 14 May 2018 08:58:22 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Mon, 14 May 2018 08:58:22 -0500 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: EST over CoAP Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZw Date: Mon, 14 May 2018 13:58:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.197] Content-Type: multipart/alternative; boundary="_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 13:58:30 -0000 --_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, To address your question about server-side key gen, below is the explanatio= n 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 pro= xying, but instead use the concept of the registrar that terminates the con= nection 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 wit= h 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 Subject: [Ace] EST over CoAP Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP dr= aft, 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 t= he meeting but in general I am curious where we are with the document. It w= ould be great to get it finalized. It appears that we are adding new featur= es and therefore will not be able to complete the work in any reasonable ti= meframe. 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 confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes, =

 

To address your questi= on about server-side key gen, below is the explanation we have put in the d= raft already and will be in the next iteration
~~~~~~~~~~~~~

&n= bsp;  Constrained devices sometimes do not have the necessary hardware= to

&n= bsp;  generate statistically random numbers for private keys and DTLS<= o:p>

&n= bsp;  ephemeral keys.  Past experience has shown that cheap endpo= ints

&n= bsp;  sometimes generate numbers which could allow someone to decrypt = the

&n= bsp;  communication or guess the private key and impersonate as the de= vice.

&n= bsp;  Studies have shown that the same keys are generated by the same = model

&n= bsp;  devices deployed on-line.

 

&n= bsp;  Additionally, random number key generation is costly, thus energ= y

&n= bsp;  draining.  Even though the random numbers that constitute t= he

&n= bsp;  identity/cert do not get generated often, an endpoint may not wa= nt to

&n= bsp;  spend time and energy generating keypairs, and just ask for one = from

&n= bsp;  the server.

 

&n= bsp;  In these scenarios, server-side key generation can be used. = ; The

&n= bsp;  client asks for the server or proxy to generate the private key = and

&n= bsp;  the certificate which is transferred back to the client in the

&n= bsp;  server-side key generation response.
~~~~~~~~~~~~~=

 

This is a need that we= have heard from customers at Cisco.

 

About the proxy-Regist= rar question, we already have made the change in the working copy of the dr= aft 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 an= y new features in the doc after removing the BRSKI stuff.  =

 

If you want an early p= review 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
Subject: [Ace] EST over CoAP

 

Hi all,

 

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

http= s://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secu= re-coap-00

 

-  =       Operational parameter v= alues

-  =       Server side key generat= ion using simple multipart encoding

-  =       Explain trust relations= for http/coap proxying

 

I have challenged the usefulnes= s 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 finaliz= ed. It appears that we are adding new features and therefore will not be able to complete the work in any reason= able timeframe.

 

So, do we have a plan for how t= o 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 othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

--_000_a4d27053f1d2431abee07d2597e14972XCHALN010ciscocom_--