Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt

Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 15 April 2020 15:58 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 552693A0B9D for <anima@ietfa.amsl.com>; Wed, 15 Apr 2020 08:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 sxkHsgtOIPVm for <anima@ietfa.amsl.com>; Wed, 15 Apr 2020 08:58:01 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150118.outbound.protection.outlook.com [40.107.15.118]) (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 B24953A0B2B for <anima@ietf.org>; Wed, 15 Apr 2020 08:58:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZJB2h7MKmtvdKlqItw1Xs1vlkFe/Obiqy75Dj43nZxdcn/3aNAMl/T21mFGurGyuxhMYd6xkKbHglsvd8iikRSe98RX20DWcmWCIFJ8UYitrNJ7w5Jn4tA8QC7BsAsymI+c5oKmugHAMlJ3/pZogHjCvLJJpU7GrQjkbPkTg5ePCLkphNkfVK/nroXgeALphpWJ4BXdCbsRGE+T1ZtPbxakstXs+JhRpRgB8GiOMSm8Uhs7Ywxj61FzdAoEiTfmFask/TZ2Fk/nTROJ0WzX4vtom51LArKwPIvyPKyqAEntgXP2+rWNuwM2V8HuVRIkfE1XLr3YOtyTCdxNOC0cvNQ==
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=lw2zrY7aF8jOOdC/C5l9vAtUZrWFEYV7RvMcMib+kF8=; b=Y5SLwEQ1MbJItM54Y4hGRbNKBdAbPBc71ZtwvKyHu0HFYPdW/+dV1VeIRx8ONqEDtGyWQJBZXtqOH8v5MH6rfIj36lv7FFX8L7YWtACn/c5lzxH3hLcePraJ3/XRotrPqPsbKxNHhWu6NYCKyniP8aRVn04Kx2d63bRKCV8xEECR39gX1sgHYEruFcNYhWMZ+y7nowH356izBRI+km3yLCBnfU7N9F86tQLyNwDEFcH0mSR33+/WxJejXn4QRZS7rgNTsX8Q3pMgLxVq8SR0hfQ30UbdOahOwotoPDPG6IEIfwqHHh9SGsHMafqHyxeU08TL8vBnETESRHg9iwAy6Q==
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=lw2zrY7aF8jOOdC/C5l9vAtUZrWFEYV7RvMcMib+kF8=; b=Hfjb2yPV6jfCDIdTMK4m4Kye/nctSSW8p5GUkO9lEelDm/Q3I1/Ej1Nrrl4TJMgW+/bYCefdG12YFQpdn5UAeaFGjnWIxYZMSP6UkQpEX+l2L5l06T/lCPKo59ObuI0+UiM3SvYx4iLcHkZ2hmdkmCiYoen7MNvKuvc+p8r2G9M=
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:17::28) by AM5P190MB0402.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:18::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Wed, 15 Apr 2020 15:57:57 +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.2900.028; Wed, 15 Apr 2020 15:57:57 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt
Thread-Index: AQHWCSqcqTUWDSvXL0+BjspUpmOUYKhntWFggAnUCICACFFrsA==
Date: Wed, 15 Apr 2020 15:57:57 +0000
Message-ID: <AM5P190MB0275E110AAF1C6CE5D93CA4EFDDB0@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
References: <158585811816.26641.249532267918234026@ietfa.amsl.com> <AM5P190MB02758EC376F90508572AB99DFDC70@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <9947.1586478043@localhost>
In-Reply-To: <9947.1586478043@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: faf543fc-5e82-4daa-fedb-08d7e155c43a
x-ms-traffictypediagnostic: AM5P190MB0402:
x-microsoft-antispam-prvs: <AM5P190MB04021B7825343BA4C018EC47FDDB0@AM5P190MB0402.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0374433C81
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)(39830400003)(346002)(396003)(136003)(376002)(366004)(26005)(6506007)(64756008)(76116006)(66446008)(66556008)(66476007)(316002)(66946007)(7696005)(55016002)(71200400001)(5660300002)(8676002)(186003)(53546011)(4326008)(508600001)(81156014)(8936002)(86362001)(33656002)(2906002)(9686003)(44832011)(52536014); 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: WIDgBz8sGKr6vB03e3vpA+xtYj9BjoQUfkP9jfHWs7YU+yR/nKGfAwUb+qos/WrYnrwVqDywsj5uXA3RgpwhPL4i+we0svUy7wTjHPQH2m9t9EAZvYv/g/xZQt5AfrkPIP6Mfhy42FUu5cwiN0VwiI9fkul3/IXL+B81o8+w4BkIElXcW0Kixss/rgd/Q+VFCUkt9YgntwxKmTEzpuVNKNTGOXMZ6DzB9M00lFPDYCas0vRZoKecxeC+4h6b0RdpsC3O8Tlw7oVU+NikMlqFFZ2WSlpWcawWUR1mPJ3ldIXU3uAci+B5yDiIlJd8yCzyMgwTQCQOIsxGyqDG6Lo3q7uSirbDLVeN0PUEKWzQ6VyuJFV7nG8ROGQK5yAKskWlRqywiM4rKof0Hf+Y4RkVC1zP68tdF4s8oXUq2vfdR2xOYEW3/+e44dymelJ/9zIQ
x-ms-exchange-antispam-messagedata: 7twj20ugjHblQ6Tn3i4FAxcaW3Y/8lDOz/onDvdi9zxZOGBr/ZwVRzPzWFlB1DzUXZNdTYCdUWJivd+fjhEKTxyQ02zblQpB7erEDJSLwmhsCwzEtOlOexpHYwv1ymzNRVoMjDxpLQ+Js1rBmpXPjA==
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: faf543fc-5e82-4daa-fedb-08d7e155c43a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 15:57:57.6325 (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: vqRrerjPXEafCVwU/fS1LmyR27s5eCG/PkDJv6mtzYQ3aV1x7dKZIINGmMIn6oDE75meB5hhJtRs8OZ+025vNW7ngCnB6dKNGMmipPiowpQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0402
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/SGjZk6a9DBPYunDJGhxf6dy7GI0>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt
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: Wed, 15 Apr 2020 15:58:07 -0000

>      > It looks like the "domain certificate" here is then not meant as (1)
>      > the EE certificate that the EST server will hand to the Pledge later on
>      > (as I thought), but rather (2) the Registrar's certificate that is
>      > supplied to the Pledge in the initial handshake.
>  
>  Can you explain "later on"  here?

With 'later on' I meant the moment of the first distribution of a new domain certificate to Pledge, as part of a bootstrap process. That is, the phase immediately following the phase of sending the voucher to the Pledge - typically done using EST. 

> The Registrar's TLS Server Certificate could be a different PKI hierarchy
> than the resulting PKI.

So the interpretation (1) above must be incorrect, as it would force EST to use the same PKI hierarchy, with the pinned domain cert always somewhere in the hierarchy of the EST-issued domain cert.

The piece of text in RFC 8366 inside the "leaf pinned-domain-cert { ... }" YANG is confusing me because most mentions of "domain certificate" in the RFC refer to the certificate that is being pinned by the voucher. (E.g. 4, 5.3, 7.3) Called the 'pinned domain certificate' or 'domain certificate' for short. 
But in this particular text "domain certificate" refers to the Registrar's certificate - and the term "this certificate" refers to the pinned domain certificate.

If a different PKI hierarchy is used by the EST server (i.e. the pinned-domain-cert will *not* be in the cert chain of the cert that the EST server issues), that seems to imply that the EST server can assign the Pledge to an arbitrary domain, even the domain of another customer. 
That seems weird, since the Registrar authenticates itself to MASA as "I'm in domain X / customer X" and then the same Registrar in its EST server role assigns the Pledge to "domain / customer Y". And the MASA doesn't know about this; it logs the Pledge to "domain X".

Esko

-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: Friday, April 10, 2020 02:21
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt


Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > The new text looks good now. I was still wondering about the pg 12
    > requirement in RFC 8366 ; which amounts  to:

    > The [domain certificate supplied to the pledge separately by the
    > bootstrapping protocol] MUST have [pinned-domain-cert] somewhere in its
    > chain of certificates.

    > It looks like the "domain certificate" here is then not meant as (1)
    > the EE certificate that the EST server will hand to the Pledge later on
    > (as I thought), but rather (2) the Registrar's certificate that is
    > supplied to the Pledge in the initial handshake.

Can you explain "later on"  here?

The Registrar's TLS Server Certificate could be a different PKI hierarchy
than the resulting PKI.

    > If one interprets it like (1) then BRSKI may violate the requirement;
    > if one interprets it to be (2) then all is fine.

    > A few remaining nits found during reading:

Thanks. I have updated my copy of the XML, and I'll pass this on to the RFC-editor.
Nothing is going forward until the ACP LC ends and the IESG does it's reviews.

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