Re: [Anima] ACME integrations with BRSKI and the cmcRA EKU

Esko Dijk <esko.dijk@iotconsultancy.nl> Mon, 07 December 2020 13:53 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9213A13D5; Mon, 7 Dec 2020 05:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=iotconsultancy.nl
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 3PpaYd4Ewxod; Mon, 7 Dec 2020 05:53:44 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140113.outbound.protection.outlook.com [40.107.14.113]) (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 CC5423A13D2; Mon, 7 Dec 2020 05:53:41 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CnY0fN1uPiuHJ6Fd0CB5tt5z1Lmj3bBFZhfqDkIv4Wuu1uWqoC4c2UOzzbA4c+7mrtYJEu+je67AUZslOUoeS7ay1dHbsRJBY6SFgWLhE0+TtVULMzlXKbcFGj1HPEr2RVuUAk2v1K6YsxGvr82kO82sc0MUAsAGxbvNFqCt8dRBVGu1gVA40xnTb1GTz+Wp6PowOhiS8Kk/0RiXLV6DaxkiuuhTuNfD8v6IhuRv23UO92tfDdg4F5w0jSAdAu1SZSy9cm383NFuM59mSW+fUImjAV2jU5Bybqw4J61DB9tEuL9s1G2pP4dapte9FhwhzBOYu46F/BmY3vZHvE6rjw==
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=+u93UEs5iBRW3wp/gIvoOtRv08lyr46EK630bWfLmlQ=; b=eU5XT4vtQsRk5e/2dDiHdfJXUqho6K2GxN/C8Guql+hTBj760DDlZAqnioVss3hF5KTcnNxiqdUofyTZCu5Nq7u88pxRg95rMcVxHAlpFXa5jcr+VxFjVmNq6I1UAZHblgo7292y5rLSMNVpXaSjJF0O3JnzuAqX8B+FihpjHCDl8g85fvrA6PLbIsRRNApt12s58+S2KxevB6cI6yaizND3hQgrp/uZCEYsEFv8pGci4QXK1Kl1E7Se7AoqWXAdXow1wOchYy6xPozD9KVIb6ttMhu5a65+JGhQzrfkxBMrgNpBSj+lzVpXQ2U06upgoIHmCzSo0XFxsy6EyHR9RA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+u93UEs5iBRW3wp/gIvoOtRv08lyr46EK630bWfLmlQ=; b=D5mBcKrpW3iw+MPztCNat/nNmOGW1W0TbXTnfZrA8dPvYgInUwpom70SrfHoynS6hr0QAVi4nkdBEJEeMrun+Owu7OyznZzwsJloxFwvqyqcdhxtKmViBYJD8grBNRWXL3rpTpFqcyh4PJnJcQoN68gEYJ52CKNYrUSzUovdMlE=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0081.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Mon, 7 Dec 2020 13:53:37 +0000
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3611.031; Mon, 7 Dec 2020 13:53:37 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>, "acme@ietf.org" <acme@ietf.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "iotops@ietf.org" <iotops@ietf.org>, "lamps@ietf.org" <lamps@ietf.org>
CC: "Max Pritikin (pritikin)" <pritikin@cisco.com>
Thread-Topic: [Anima] ACME integrations with BRSKI and the cmcRA EKU
Thread-Index: AQHWynzIFTxls/YioEynislZJikrbanrcCTw
Date: Mon, 7 Dec 2020 13:53:37 +0000
Message-ID: <AM8P190MB097940886FE07FDA40227781FDCE0@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <158561301296.11367.9776561744635554098@ietfa.amsl.com> <4603.1585620652@localhost> <20200331150202.GH50174@kduck.mit.edu> <600.1585687336@localhost> <AM5P190MB02751866462AE590EAD2EB14FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <5633.1585770340@localhost> <AM5P190MB027524F2D1530746DD48C4DDFDC60@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <13227.1586052088@localhost> <AM5P190MB0275BA7298686DBADD31F0A3FDC20@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <14837.1586479192@localhost> <AM5P190MB027501C1759C042E54C40137FDD40@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CY4PR11MB1685181D4456431F05071D05DBE90@CY4PR11MB1685.namprd11.prod.outlook.com> <23785.1605650162@localhost> <CY4PR11MB1685A60B58D9CB1269978B5ADBE10@CY4PR11MB1685.namprd11.prod.outlook.com> <26304.1607113986@localhost>
In-Reply-To: <26304.1607113986@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=iotconsultancy.nl;
x-originating-ip: [2001:1c02:3103:f000:71d7:27c6:6e0d:88b5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c7650576-9d69-49ca-c95f-08d89ab77ef9
x-ms-traffictypediagnostic: AM4P190MB0081:
x-microsoft-antispam-prvs: <AM4P190MB0081C931E2B374B118DACF8CFDCE0@AM4P190MB0081.EURP190.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: 38XdXxUf/Mi+J2C3S/A7wYCe4ftcdly8YqwscJLTxbO+KjaVJTwSPalMTdaTLuTmmBwTtDFFfoduDWeZM2V7PQ17Q4kRrMxgWS+urLBtjPin7CvA3H0S6iRWW3ro0FUg9DFdH0XRno+1r5fI6awkfPkEHACn1XMn7Ps7aXybFWqWeLSowmAV8z28h9zuWF29eTBsU9fi2mVr20pofFKMGahqJLaPIVe2+uBinLaeyflriJOM1d2px+/oCCQmRXe7h4p2aDYku1QZ11KVp/vTt3c0sgOeTqoK92h7wcFSTqFWf1wK/oUksrrEBuRt/SPjP5WUFfCiNh+4ipGQaoE5cA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(39830400003)(376002)(366004)(55016002)(53546011)(71200400001)(2906002)(66446008)(76116006)(66556008)(66476007)(64756008)(66946007)(9686003)(52536014)(316002)(8936002)(5660300002)(7696005)(6506007)(186003)(44832011)(86362001)(478600001)(4326008)(83380400001)(8676002)(33656002)(110136005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?a1V4TDhFUjFWNDBveXcrMHhTMUNmaDNFTzlOVG16d3ZyNHBCaTFPdXNRUEpx?= =?utf-8?B?b0o0LzBScjN5dWdEUTJkWFgyYXVUT2k5Nm15Q0gvSVNUVS9tNy9MdndhbXBq?= =?utf-8?B?M1JTWWhhUjU1Q28wMzhLb1NpM3k5SzdVbnI3SlozRUkzc2NPejRtOGo3R3Aw?= =?utf-8?B?MnZ2TjE1dyt3TzJjNEdES2UwK0xidVJESVI0bTVGYWJxVUxFWnVmSkVYK1Va?= =?utf-8?B?Ykd5alBjdGxmbVU3WDJicE1EcjFaOE9YUWxIWWgxaUUyY09MemljVXFsMXY4?= =?utf-8?B?MnA0YjJQK0owUHRkbS9LVm9kZWd0a0NEbmFJOUdkSTRRNDJFSGhBRW1aMnYy?= =?utf-8?B?Zmh5amFPVDF2SXRSS0YwbHhla2F2OFpZN2I5NnV4dTg2clpBc3FSMkFrc0xn?= =?utf-8?B?YkZYdUUvU2lmaFpBZWFvai9lVytUY2hDRWRiOElTZHpCUGpBcExBN3d1MFVr?= =?utf-8?B?RWRkOUdHNDlqV1V3dEloWVVqUm5CZkdSdTVUTzB6SGRsdWZPTUtLL2VteFBN?= =?utf-8?B?cFB5VjFMMkhsWTlHYWlGWDQrRnFsOUhCVjRUdnF5NEttSVR6WVc4L08wNUIv?= =?utf-8?B?bFZ6Q0ZYb3MzMWFmVjJURUQ5N200STRhd0x2QW52NjlTSXF3ZFRmVExUbUZ0?= =?utf-8?B?dXo4UlI5Y1hySWJzUm83ZEtDTFZJMFYxSWtMRmppTDhDVmlUZ1NIeXZnMlhL?= =?utf-8?B?a240elE5bUJ1L2VzUDkyc3JIYjhSbTE3dzRsNXU3SjVrcXR4MHV0RkpFTEhS?= =?utf-8?B?SHFJcndJSzVDQWpiWllSL3c5L2ZuNkt5L0Z6VkU3WTRXQTMycmxkRXV0WnVG?= =?utf-8?B?blVMRmpBbG0xK0NKbkFONHN4UjN1ZE9EWWJwcWc0b2VqV1djTTlhMkVEL0VF?= =?utf-8?B?SkxoMGVKUUN0MXFid2JEendMcnBKNDUzaHoyQS9NSjVFUkxPK05yckdkOWtt?= =?utf-8?B?cFNuNEtNVGlFQjZ6MXExcE44Z1V6VGRGUjB3UXQvZXVNQlZSYVFYcGpvUFEy?= =?utf-8?B?NDJIdGd6c0FKYysreVFGallieEkybDUzRFhPRC9uanJFR0p0SzEyVWJWK1ps?= =?utf-8?B?akZiL0RyUXZIMUl0L0dqd1N1M2pidHAxSzl1NkM1dGFFRzdIc3E2RDdWWlpr?= =?utf-8?B?cXlNUmMvSWVsK0pOV0JhQUpPeSs1NXhGWEVBeDJsbk53anRnYm43Qk0wOUov?= =?utf-8?B?MStmUjhtZVIvSTFoc1FTSUV4SHZ1ZG9ROXVaYzY4QUxUUkJPTmt5elB6QU5t?= =?utf-8?B?UlEyZG14UkpmVlNVSzUvLzBWNENCRHlwSU5lQTFKM3ZBUkUzYmNxeXphTkp5?= =?utf-8?B?eDdUSmRSUElvRzZHYzZpS3FCRWdMdWdTbnZOOU1yRnIreUhuOHpzMkM0M29x?= =?utf-8?Q?uzWNgQXGxlxZI2i0BPPB0TQlofpfVYWk=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: c7650576-9d69-49ca-c95f-08d89ab77ef9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 13:53:37.1841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wjYE384SrSyo1+kdUUuUeFXWjo9VHgBkcwzxvws4blylr3lUnNtGnKoMsFd5b/Feq65pTgRZok9qCw5R2fjo1wmKf1P6w1ty9FRqUFY3xm8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0081
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/KLWf2ntMOJ5Zw5nmqsAq177gXvo>
Subject: Re: [Anima] ACME integrations with BRSKI and the cmcRA EKU
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 13:53:47 -0000

Thanks for the useful intro Michael. 

> A Registrar that uses RFC8555 to talk to it's CA could have three different
> kinds of anchors:

The Registrar also could have different identities used at the same time:

1) ACME client TLS identity   (towards ACME server)
2) Registrar/EST-server TLS server identity  (towards Pledges)
3) Registrar/EST-server signing identity  (for signing Voucher Requests)
4) Registrar TLS client identity towards MASA server

For #1, ACME client it could use any identity / 'account' that was able to prove control of the DNS domain, so it can be unrelated to other identities. 

> 1) it could use an RFC8555/ACME EE certificate that it obtained for itself.
>    In that case, the cmcRA bit is most likely not set.
> 2) it could have a self-signed EE certificate, where the cmcRA bit could in
>    fact be set. {Would it have any real meaning?}
> 3) it could use a raw-public-key.

These options could be considered for the signing identity #3:

1) it wouldn't work if the 'RA' flag is not set. The BRSKI security architecture depends on 'RA' being set for Registrars, and also ACP does. In my view a MASA MUST check for 'RA'.
2) this can work
3) Registrar signs with a certificate not with a raw-public-key. And a raw-public-key cannot have an 'RA' flag set. So that wouldn't work

Option 2) looks good as an identity for signing Voucher Requests.  Either a single selfsigned RA+CA cert, or a chain of two: RA -> self-signed-CA. The latter is useful as it allows in the future more Registrars (with RA flag set)
to be created within the same private domain (CA).  Of course this certificate / chain must then be created by hand i.e. it cannot be automated using ACME.  Do you see this as a problem? To me it seems acceptable.

Details of this solution: MASA will accept the above signing (since 'RA' is set - check passes) and will pin one of these certs. The Pledge will too accept as per BRSKI 5.6.2 because the Registrar's cert is either equal to, or chains to, the pinned-domain-cert.
The Pledge will do after BRSKI-specific bootstrap operations the GET /cacerts (Section 5.9.1) and the Registrar then serves back 2 CAs: { self-signed CA ,  ACME CA } .  The Pledge will then do EST e.g. /simpleenroll with Registrar; and Registrar 
meanwhile interfaces as a client with the ACME server to obtain  a new operational domain cert for the Pledge under the DNS domain owned by the Registrar. The Pledge can verify this new cert against its trust store that now contains the 
two CAs: { self-signed CA ,  ACME CA } , so it will validate.  Note that the Registrar enrolls the Pledge into a domain (with ACME-issued cert) that the MASA knows nothing about!  I assume this is allowed by BRSKI as I read that the Pledge is
supposed to install the /cacerts response in its trust store. 

Now if above solution option 2) works with ACME, there seems to be no need to request certs with 'RA' set from the ACME CA.  The 'RA' certs are under the control of the Registrar's private domain. The auto-created EE certs are created
by the ACME CA under control of Registrar.  

Or would there still be some need to use option 1) and update the ACME RFC to enable ACME CA handing out certs with cmcRA set?

> One thing that occurs to me that a pledge which *can* form an ACP, probably
> should *not* if the cmcRA bit is not set.  

As said above the BRSKI security architecture depends on 'RA' being set for Registrars, and also ACP does. So it seems risky to assume situations in which it is not set and MASA lets the bootstrap continue.
So the Pledge doesn't need to evaluate if cmcRA is present - because the bootstrap wouldn't succeed in the first place if cmcRA is absent, right? Or do I miss something.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: esko.dijk@iotconsultancy.nl 

-----Original Message-----
From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Friday, December 4, 2020 21:33
To: anima@ietf.org; acme@ietf.org; iot-onboarding@ietf.org; iotops@ietf.org; lamps@ietf.org
Cc: Max Pritikin (pritikin) <pritikin@cisco.com>
Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU