IETF Logo Mail Archive

Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)

"Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com> Wed, 22 July 2020 13:42 UTC

Return-Path: <hendrik.brockhaus@siemens.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 691F33A0835 for <ace@ietfa.amsl.com>; Wed, 22 Jul 2020 06:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 5v37hciIjVC8 for <ace@ietfa.amsl.com>; Wed, 22 Jul 2020 06:42:30 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10045.outbound.protection.outlook.com [40.107.1.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 938C93A0832 for <ace@ietf.org>; Wed, 22 Jul 2020 06:42:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BsPxke0RfnxgbojXaTEvbLzNIvk4ENrRrMbYg8Cx8dA5MprH7rJsyRTgEB49qo9ZIIBZeEs3kVPd2uXGxf1ogkoJcF2sWCizdIeaTniWhWXvBofzArYZzLhTNPxfDTjpnOoU1fAAhUemGTQiiLJOEggJe/1epIFX+pSlQJmcwerXBM6iMpXcqSvu9Mvo84PjZNp+Nia/hmgUCWeQZhC+g/WwUMLjm71oEYWpPP1cBQOt0RyAFSiJeB1ArXdUkVtqIUeYYkgmZwxLZ8NzFIWrUjRSE0FhEsmKeW6ACMyAG1021KTJEx41N/s1IJd1JsXZSPDA0Ud/8Dafz6VowAZiWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2RDW3W5vgY1cYbrPzatD2UBgTSAdlEHBybt81xq3mw0=; b=SepnjaiaXhuqffVRauPbye7/sPf6YRRwv0H0rNJTCpaL0KvTQ1CvRcYbDyFiMhcayFI1wibnzQNbP+6C9OGrnTrD6a7Ul8xbK228l7/8iAuXO84VMiyG6Ar3cwvbRgoK72LnXAesBmgPHgJ36Yh7e0sOCLrmMtlnlBGujFx2gTs52isQUrwIy2gOBQQxllIWB84HrpKznCFoOO5FS5cAmhoIW2btvSUj6++qfV2lJhfy3Uk69Wb/+PKxr9gcD/nOEaoIXjgFB8hkoBAerBhRCj1GcveWa9WtO+RtwE3h/VxkKsO2gSpNHYCXsLRkxtWvBFAJ3p9OXQ/QnAjbiuyI0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2RDW3W5vgY1cYbrPzatD2UBgTSAdlEHBybt81xq3mw0=; b=ARjmzT18O0Z8cyiKcVkayKt7nVP2O0O1qX17CO7SQoyX3z5h/LsGjSCcdGGY751VoNqNsrknyXbt3MiCPbnURpxQnpBHSBp51eYIEDpNSbyufDkAfRDGBH5GscDsTzQ/STNoYtkd8E7x6R+QkqznbiA3WGgWHGGQD6TdKQ+brmA=
Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2098.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:4a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Wed, 22 Jul 2020 13:42:26 +0000
Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 13:42:26 +0000
From: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
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" <steffen.fries@siemens.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)
Thread-Index: AQHWX5lapX1JlGFGAU2aq0XyrzvJB6kSfISAgAAYZoCAAKL0AIAAW0cAgAACj1A=
Date: Wed, 22 Jul 2020 13:42:25 +0000
Message-ID: <AM0PR10MB31536E2085A36420C0FB6A2DFE790@AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM>
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>
In-Reply-To: <DM6PR11MB25554D31E5C2DBFA677BD83AC9790@DM6PR11MB2555.namprd11.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=853d4b82-15da-4ce2-9193-0000a3646129; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T07:41:39Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a;
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.158]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 90600f02-165d-4117-c5b0-08d82e4511f2
x-ms-traffictypediagnostic: AM0PR10MB2098:
x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR10MB2098E1A2EAFC7630FF0ABCE6FE790@AM0PR10MB2098.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6vaOpPM33/+pxYAP5biEInH7+TF2K2Oc2W9cdeUYyc478oC3kao7FY69b4c1QIffsRrkCxAGkIQsJ7wwx3Cw65xQeJKoV+KVyFO7v21HJu39GRYdl5Dna++FRtafcWYWaZ/NiyTpOdHOijNGQf8M5nEayLu/tp1HMtWIB8XyPXLmSxWlgFMHKKSvLnfhZtl13pPq3xuKGzUkHmOxoNjIwcV/9kt72+8f/6tB8PZMznyfwFGOhnEiXJsaRKSE2tnFZJSC8ugo6P08zVYN81G3i85oajS1aN3vzvT349sQG4xM9FtFQzudGt+dlsW+UN2nHE+iIWvmkLqGyJD3b6BdRQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(39860400002)(136003)(396003)(376002)(9686003)(7696005)(99936003)(6506007)(478600001)(8936002)(4326008)(83380400001)(33656002)(26005)(52536014)(66616009)(64756008)(66476007)(2906002)(66946007)(76116006)(55016002)(86362001)(66446008)(66556008)(110136005)(55236004)(316002)(186003)(8676002)(54906003)(71200400001)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: WHgy/6iUcdRie51dT8xli1+ixi0Cy0ibqpAz7P9SGFh4voDWorATOs5APs5wl8v3sfxTKGN6DfkdQKRqjY3wtJXxa2731QNzhsHC364TgYMjnLJYnlX/TlMhfjKeL+iell5pVajYboO/j8hhIHRA+JqIuuehdxh44KHJVYRmi2mRqZqLTP3T2J6Hg/UBDaeItO16tYhOrohaCrrP371/9m37h6vw3HRV2ItqiEpgDE73ISyPVQbfLE2B1Am8GbcYBygPbuHa5RPdwLDMj8oVa9HgHH00mhelpxjCKOoOBZ7XMlLmdlRGqnxlZVdfKTDB0W6CpbFEOkffwTTke9nPwjpAChdvJWTo9WVSZbtLse6ZKDLRrrBsWtROKdvjlhTbfEqx0K+VZtrELdqhmDQQQLmp1RW0hx5F9jca6cACbCr1tqJxe+tt74B0BIumpIkQOvHnVZ7lOVG433EHJMx7TDrDufsf0WUIPDUf+968ji4LpnXraiFXW7DEEgnx+N+k
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0005_01D6603E.54979F30"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 90600f02-165d-4117-c5b0-08d82e4511f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 13:42:26.0414 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3G9iJck2bO/yK3pUHP2lHBKFg3o7rVNOPCPvSSb1waH46CRCJmLvE5RVocPVe3g4+0xYDa0XmR/SMmb3RGaHdLBs+Lb227j3/a3bNEfBlMY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2098
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/YVNpkHhTdJUOAG7RkhtZ1JsVmqY>
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: Wed, 22 Jul 2020 13:42:31 -0000

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

v2.23.0 | Report a Bug | By Email