Re: [Anima] ACME integrations with BRSKI and cmcRA bit

Esko Dijk <esko.dijk@iotconsultancy.nl> Mon, 20 April 2020 09:10 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 807D13A0866; Mon, 20 Apr 2020 02:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.021
X-Spam-Level:
X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_HELO_TEMPERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.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 5Yz5kgZOpgtj; Mon, 20 Apr 2020 02:10:06 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60139.outbound.protection.outlook.com [40.107.6.139]) (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 15CC53A0C3A; Mon, 20 Apr 2020 02:07:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lJXscDC9zDDDTecySWt1KoPHOHj8oDKxyGrnPUfbupcJ00BybQ0ZOBJF4CAqfZMaZOyze0lozSx2u0o7/pyFw4aGwcuHxD4mK/i165eVO66T9d34EkbpQmzO8efG0uPyiLNAlnEZSXuysIwOQkD2F/FifyNqgzhJ8C2aOclaOgGRb4QwNFhds9b4+YbyO4/jqzMlwohdVFxuVSAaDI4JrMxmGcFpbOub/+dBcISUYyhVcyHX6dPUA7MC2Ck8QCSD4XpumUG1YRulB6O7N0TyOQOrYqYYuR8VMucMqq0XzTfSU60HAQzMPzzta2xbHRm9QZN1sU7e4/c1C62S9GDYuQ==
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=YDROak04Y46vbRHoTJ3yLyIDhW5ilVZp8yOVFl5kX0k=; b=Y7ISPCmaLpUypQOwoGisi1/NTZCJ4yR2LdMzqhyQGXUhr4ZUriC49VvBWBWg+8ttFn6DQb3cVqZMxxoF76/mQcnvGPVLV4TmNBJ9rIrYDGonWLdRpvIeUhT0nlrD4WaQQayphIKCuetADQnoTjwBeZZy2KnE/BKRWppXt6H9G8pF7f9p6OUtjpNKOzBGvLuYVwnJvfPsVBQPsI8wGx1AEaMl3TP/3Z2kfRAhEWXKRpDU+MKyUpHtJHLVjJmbJN1cYLcr7HIMz88zANYO89lTQOTzE51Pz00fB+GH0S7XvX5Ij8E6z/IRNhyKR3957qoWruj4CLWg8EermF9Biu3NsQ==
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=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YDROak04Y46vbRHoTJ3yLyIDhW5ilVZp8yOVFl5kX0k=; b=UnhB5ZJSXlFhZC3VWJYk4YvjLS0vy3/IJIXoIgm2dR6gZ+BET6UFbyKl4lCa8Y45Lw1QvwbOzzvhWUgvFcuvfdRqetYvuwEsseefXFGRXcSd0qFX9e0fvSVGUpod41fwmXl8m0+IGsBvmlfe8hsjRCH1lbR/229ezmyld3QMx7g=
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:17::28) by AM5P190MB0292.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:21::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Mon, 20 Apr 2020 09:06:56 +0000
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::4419:db1e:a5a7:7485]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::4419:db1e:a5a7:7485%6]) with mapi id 15.20.2921.027; Mon, 20 Apr 2020 09:06:56 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Owen Friel <ofriel@cisco.com>, "anima@ietf.org" <anima@ietf.org>, "acme@ietf.org" <acme@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: ACME integrations with BRSKI and cmcRA bit
Thread-Index: AQHWDtCQLhCHHJtHakyP/U3Af+emZKiBxRrQ
Date: Mon, 20 Apr 2020 09:06:55 +0000
Message-ID: <AM5P190MB027501C1759C042E54C40137FDD40@AM5P190MB0275.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>
In-Reply-To: <14837.1586479192@localhost>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl;
x-originating-ip: [85.147.167.236]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5834feaa-5bc9-4104-c586-08d7e50a2cd9
x-ms-traffictypediagnostic: AM5P190MB0292:
x-microsoft-antispam-prvs: <AM5P190MB029290AAFD3B6C79D0D3601DFDD40@AM5P190MB0292.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(396003)(39830400003)(376002)(136003)(346002)(366004)(86362001)(186003)(316002)(6506007)(2906002)(52536014)(81156014)(53546011)(8936002)(508600001)(26005)(110136005)(44832011)(8676002)(33656002)(71200400001)(5660300002)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(7696005)(55016002)(9686003); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L0oBsuXzSalX1QE2sh1LYPkGbaxQ7L+L31wm+a7qSlkIWpZWx9/ocaEYRXP2tOt7/V5mJMSHoG0t7SH5kVMz8m2j96PZqiwNuyhZJaotWUe0otfu8vGMu7Iu3nA+798jt2B/5pFbdkKGQvwfpRwXgO2bROGnmVpOGw9WwR+efT5A8oCd4l3iP2MOchro+DUZo9aWs4yIyBK7V0Mg9nzwjUp4gAfyjBl4RFZYyJvxxJTe1KRHIhRF6YSQ4QyFJWXADxTjMMXJbSMPOWwhDksqQuwSb5jMZb4tjdFpTIYlUTaoomfp1nUS+lOOXllXhNtrcIfVTdwk+Wi3H9m94IvguY3TTb37lg1oCZTeJysHWjH1fNVaWDriDaAKPSDZtZ00T/EzGxAMqJqyP23HHZePTwoyZEHIEyxRpfb5GreaL7uqWqFeqfykfg+blcsBQhYC
x-ms-exchange-antispam-messagedata: kJUFLpTFdTcHHEv4YfQIBLBOptbBqrfX1MqOLuDa2/09rSv9NPvRVNby5sJNvceWGdWH9LtduAmfWM/tayoImVKRkPag0yzwnCtP75iqbow3oirygAQuF4DKVKUm7JfYNNCRiICR7eL4bScfOh8TPQ==
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-Network-Message-Id: 5834feaa-5bc9-4104-c586-08d7e50a2cd9
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 09:06:55.9648 (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: qKqmGEgb3qjWk03+q+288L7eg+reGy8HPMIwNtVL6ticS9bopO+9ZzPnoXm9MIV4zQaQNwBgitfzXkJKByKCrwDAslD3Yqwz8QTWH50daAg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0292
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/caudiwxPMW4MS_2k2S4Oam28apU>
Subject: Re: [Anima] ACME integrations with BRSKI and cmcRA bit
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, 20 Apr 2020 09:10:18 -0000

> 1) I think that the MASA may skip that check for recognized registrars, so
>    that the ACME integration work can work.  This would be a local
>    configuration.

This option sounds acceptable to me - if the MASA is pre-configured to trust a particular certificate supplied by the customer, then it can be set as trusted as an authorized RA for that customer.  Although doing the "RA check" on the Registrar cert would be an even more secure solution, thinking about some possible attacks where an employee could misuse this process to get his/her own EE certificate approved to 'act as RA'. But it's up to the manufacturer & customer here to choose the solution that works and provides sufficient security in their view.

> 2) It may be that draft-ietf-acme-integrations and/or
>    draft-friel-acme-subdomains may need to specify a way to ask for cmcRA to
>    be set within ACME, when using ACME when doing the pre-authorization for "domain.com"

It would be great if such functionality is supported.  I do not currently follow ACME in any way so I hope others have opportunity to bring this idea in.

Esko


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



-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: Friday, April 10, 2020 02:40
To: Esko Dijk <esko.dijk@iotconsultancy.nl>; Owen Friel <ofriel@cisco.com>; anima@ietf.org; acme@ietf.org; spasm@ietf.org
Subject: ACME integrations with BRSKI and cmcRA bit


Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > Currently BRSKI Section 5.5.4 has this text:

    doc> The MASA MUST verify that the registrar voucher-request is signed by a registrar

    > If the Registrar would use a non-RA certificate e.g. ACME (LE) standard
    > EE certificate, then it seems that it cannot get anything from MASA...?
    > And BRSKI would not work?

I agree that there are potential issues here.

1) I think that the MASA may skip that check for recognized registrars, so
   that the ACME integration work can work.  This would be a local
   configuration.

2) It may be that draft-ietf-acme-integrations and/or
   draft-friel-acme-subdomains may need to specify a way to ask for cmcRA to
   be set within ACME, when using ACME when doing the pre-authorization for "domain.com"
        cf: NOTE: Pre-Authorization of "domain.com" is complete
   The ACME spec does support authorizations for domains, and maybe that
   would be the best way to do this.
   This also supports the concept that the cmcRA bit ought to apply to all RA
   operations (CMP and well as EST), as proposed in LAMPS.

I think that we should perhaps plan a design team meeting/BOF around this discussion.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-