Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)
Jim Schaad <ietf@augustcellars.com> Fri, 24 July 2020 14:33 UTC
Return-Path: <ietf@augustcellars.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 018C33A0A2C for <ace@ietfa.amsl.com>; Fri, 24 Jul 2020 07:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6eSh_nM_Yhyv for <ace@ietfa.amsl.com>; Fri, 24 Jul 2020 07:33:07 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C273A0A26 for <ace@ietf.org>; Fri, 24 Jul 2020 07:33:07 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 24 Jul 2020 07:32:59 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: "'Panos Kampanakis (pkampana)'" <pkampana=40cisco.com@dmarc.ietf.org>, "'Brockhaus, Hendrik'" <hendrik.brockhaus@siemens.com>, 'Benjamin Kaduk' <kaduk@mit.edu>, 'Michael Richardson' <mcr+ietf@sandelman.ca>
CC: 'Mohit Sahni' <mohit06jan@gmail.com>, steffen.fries@siemens.com, ace@ietf.org
References: <mailman.1850.1595355742.7860.ace@ietf.org> <CAEpwuw0JN9RGzEBs+fmcL18OFcHzKj_DDzXCt4VkSkSmG3Rvnw@mail.gmail.com> <9794.1595363465@localhost> <20200721215825.GB41010@kduck.mit.edu> <AM0PR10MB3153493DF2B63A8A061BD916FE790@AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM> <DM6PR11MB25554D31E5C2DBFA677BD83AC9790@DM6PR11MB2555.namprd11.prod.outlook.com> <AM0PR10MB31536E2085A36420C0FB6A2DFE790@AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM> <BN7PR11MB2547B298898A544F8A26C0F9C9770@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547B298898A544F8A26C0F9C9770@BN7PR11MB2547.namprd11.prod.outlook.com>
Date: Fri, 24 Jul 2020 07:32:58 -0700
Message-ID: <031b01d661c7$55e3b1a0$01ab14e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJDOCht90xMMdcWXdaGmJSaoGyAUwGmUsTZAiZ3QyQBjyIiHwIWdmgAAsOmbfoCcGA7TwGonbgIp8ql7gA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/53oM5SSeHdpueTzi10do1zh2tJ4>
Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 24 Jul 2020 14:33:09 -0000
> -----Original Message----- > From: Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis > (pkampana) > Sent: Friday, July 24, 2020 7:05 AM > To: Brockhaus, Hendrik <hendrik.brockhaus@siemens.com>; Benjamin Kaduk > <kaduk@mit.edu>; Michael Richardson <mcr+ietf@sandelman.ca> > Cc: Mohit Sahni <mohit06jan@gmail.com>; steffen.fries@siemens.com; > ace@ietf.org > Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) > > Hi Hendrik, > > Thank you. Understood about the end-to-end protection of CMP and POP. > > I would argue that establishing the end-to-end keys to offer the application > level protection functionality in a scalable way does not come easily. On the > other hand, even CMP allows for an RA trust model instead of end-to-end POP > like EST-coaps does. [JLS] EST-coaps does allow for an RA trust model for POP as well. The RA is the terminator for the coaps connection. Jim > > > I am uncertain if I understand your question correctly. Est-over-coaps > described EST transport and not CMP transport on top of CoAP. > > I meant why do we need two enrollment protocols to run over COAP? > est-over-coaps took a long time and a lot of work. The reason we pursued it is > because we were getting requests from vendors that wanted to enroll certs in > constrained environments in the energy sector and industrial automation and > EST was standardized in IEC 62351. Is the cmp-over-coap argument that you > could run it over plan UDP and use out-of-band established, end-to-end > protection the sole motivating reason? > > Rgs, > Panos > > > -----Original Message----- > From: Ace <ace-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik > Sent: Wednesday, July 22, 2020 9:42 AM > To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Benjamin Kaduk > <kaduk@mit.edu>; Michael Richardson <mcr+ietf@sandelman.ca> > Cc: Mohit Sahni <mohit06jan@gmail.com>; steffen.fries@siemens.com; > ace@ietf.org > Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel > Migault) > > Hi Panos, > > thnaks for you feedback. > > > Von: Panos Kampanakis (pkampana) <pkampana@cisco.com> > > > > Hi, > > > > > Looking into Mohits draft, cmp-over-coap is much simpler than > > est-over-coaps, as CMP does not need any binding to an underlying > > (D)TLS handshake. > > > > Not sure that is accurate. And EST does not bind to the tunnel > > protocol either unless proof of possession is used. For now the > > cmp-over-coap draft says > > > > When the end to end secrecy is desired for CoAP transport, CoAP over > > DTLS [RFC6347] as a transport medium SHOULD be used. > > > > COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and > > maybe Websockets. I am not sure someone would run cmp-over-coap over > > TCP because then he could just run CMP natively without COAP in the > > middle. Any application layer protocol (CMP etc) can run over any > > transport but I am > not > > sure there are more transports than the usual ones for cmp-over-coap > anyway. > > It is not needed to run CMP over CoAP over TCP. UDP as transport protocol is > fine. Actually CMP over CoAP also does not need DTLS underneath. But it also > does not hinder to have a second line of defense. > As I understand EST, proof-of-possession is purely provided by the > self-signature in PKCS#10. But EST provides the proof-of-identity of the > requesting party by the (D)TLS client authentication bound to the PKCS#10 > (tls-unique copied in the P10 password filed). Is this correct? > Such binding is not required for CMP. CMP does not have any requirements in > this regard and provides prove-of-identity by signing the CMP messages. The > advantage is that this prove-of-identity can be end-to-end and not only on > the first hop to the (D)TLS server, like with EST. > > > > > > > I agree that if this gets picked up it should be by ACE. > > > > I would like to understand what gaps it is filling compared to > > est-over-coaps which took a lot of work and where it will be used and > > implemented in. > > I am uncertain if I understand your question correctly. Est-over-coaps > described EST transport and not CMP transport on top of CoAP. > One prototypic implementation can be found on > github.com/siemens/embeddedCMP. > > - Hendrik
- Re: [Ace] IETF 108 tentative agenda and presentat… Mohit Sahni
- Re: [Ace] IETF 108 tentative agenda and presentat… Michael Richardson
- Re: [Ace] IETF 108 tentative agenda and presentat… Benjamin Kaduk
- Re: [Ace] IETF 108 tentative agenda and presentat… Brockhaus, Hendrik
- Re: [Ace] IETF 108 tentative agenda and presentat… Panos Kampanakis (pkampana)
- Re: [Ace] IETF 108 tentative agenda and presentat… Brockhaus, Hendrik
- Re: [Ace] IETF 108 tentative agenda and presentat… Daniel Migault
- Re: [Ace] IETF 108 tentative agenda and presentat… Mohit Sahni
- Re: [Ace] IETF 108 tentative agenda and presentat… Panos Kampanakis (pkampana)
- Re: [Ace] IETF 108 tentative agenda and presentat… Jim Schaad