Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 01 April 2020 09:16 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 879313A089C for <anima@ietfa.amsl.com>; Wed, 1 Apr 2020 02:16:41 -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 4xxwK2AfacYC for <anima@ietfa.amsl.com>; Wed, 1 Apr 2020 02:16:39 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00126.outbound.protection.outlook.com [40.107.0.126]) (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 5C8D83A0890 for <anima@ietf.org>; Wed, 1 Apr 2020 02:16:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A5Gkp8HYq/Yco7MsIEkHRODartVYeskjs7pqQEmHUC6JJXF5otLz7sd4Rc4TGnhdvo7ra+igTnAO1Z9IKqYKqukxRqrcMVbyGimDaTJORtB+03ovQePxq3Cz28WREOwDQ1wmRZjuvc9HdYTx7W1U8liLv7gxhp6XwVKLUiOqJQbv0p87cwGISJXFZmFkzeRFV9zO4u+m+ZdNx6z+GCLHr8qxR65wFFcabRm2HDaMswlQQ3F2njyeYXB93CbJS4+NosbMwfMYSm5DmRUOdp90k8RNmTV6FoNEIK/fESNgsFrIq2I1fY1qO/7a3k4TdYxRWcZcn9lFInIaGAXIRkZitg==
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=U7hjMFG7r+OqvmD9hj0gOXUITN4+Zs1VPL2v0r14dk0=; b=VyQE1R95fsVZSIdoAr3+t3w+zl6/oIsZvZf5rOCBdJwNYfje6nAUDYArx+g78r5Wo8RTYbCYeJc8N3wKfxeGVjjrDUKG1qpAz410PTL0xA/FzLMQH5sJ2qSpN4GBFm7AEe7yj8W+8kk2H4n44yrK6apjfhazDFh7Lf0eU+wuKd+qhFGMi11iZpC/ENKFz3KuM3XlUfXt46zdrpEq8hZeXhU6hts7JDbY/ClrMPQAbyHkKndYdGsEKjjMRLY7Pawn+0/8ciuXj3nb62UwwyoMSdkJAbHtaBE0AptuMkeDgHiiuqmPNYra3qaLTkk2QdryRxk96oFTDw7UxhC8rTMQNQ==
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=U7hjMFG7r+OqvmD9hj0gOXUITN4+Zs1VPL2v0r14dk0=; b=raR9Wk3UBzxXmjo9zs38BVU4yEUTBiyfgiDjRFY5qA53x4v1n4M3jdsK9H+GTVEGpPRhcwCAbtgGVo2tCUGapOEkQNY3h2tOwT8BECpH+uwrdHrcYZ3KWdO3ucfdoq068QW6dran0nmer/+S5WymODfXWnLLqnFAuIrD2KkP7jA=
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0337.EURP190.PROD.OUTLOOK.COM (10.161.62.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 09:16:32 +0000
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f%3]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 09:16:32 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Benjamin Kaduk <kaduk@mit.edu>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
Thread-Index: AQHWBu/ZmuKBXSTnP0+1TFNY1ukEm6hh9VUAgADXdgCAAF8PAIAAzCFw
Date: Wed, 1 Apr 2020 09:16:32 +0000
Message-ID: <AM5P190MB02751866462AE590EAD2EB14FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
References: <158561301296.11367.9776561744635554098@ietfa.amsl.com> <4603.1585620652@localhost> <20200331150202.GH50174@kduck.mit.edu> <600.1585687336@localhost>
In-Reply-To: <600.1585687336@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: 287c4f38-5fff-41fa-ae7f-08d7d61d5e6e
x-ms-traffictypediagnostic: AM5P190MB0337:
x-microsoft-antispam-prvs: <AM5P190MB03371DE08B431C5156B3837DFDC90@AM5P190MB0337.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03607C04F0
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)(346002)(136003)(376002)(366004)(39830400003)(86362001)(316002)(55016002)(508600001)(66946007)(71200400001)(33656002)(26005)(44832011)(66446008)(5660300002)(2906002)(8936002)(52536014)(7696005)(110136005)(6506007)(76116006)(9686003)(81156014)(66556008)(81166006)(53546011)(186003)(66476007)(8676002)(64756008); 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: e3SQquCJCWW4BLZhJ5fLZGOmw4gMrU0yk01aBvZkbKSO77BORTcI9iSz9exRxl8AqitpRmbXGpvz9MhhhdEGzM9zAsl8JmMmInL5vUWtJ3cn2YZcv2kqO3Fgpw3uVCKv7gT81bWe3em8+Znt66tGSjmSxGLz82ooyVPClyzZmUR6BNFEyYxTkIgYSARb84Cpr59g+rCRO2pit+sC5Fx+nU47aIPlKZ2fac2caTKITGZFq4ToYJWE5A9sLjgyUAYmlEP6MQ+3zAktXKlYt8Sx7Bvc6T/4XsSYNBianTEoYNV9sQ/kqNvRjO/eICgkMXeTEBW1K0pyZ33sg/nEztpH2eodPyLcH8SRZ+iTdl1yROMtvLJ5ZryOzbMKyslHfGm1Rtm+eRKdsrBDQZ1JwYztSKMdSkz78BXHMslqUPRUMK9Bik9L3qWWeQtLkvo1ynRA
x-ms-exchange-antispam-messagedata: KMaHXkoe2x3R9HBIaUaoRLfJFmCFkYPzmgnZ7lV6pyMIa2UpI6+mjeXk4bnGAKKSwwbZAgPBWh1K6hlzxr5MlJzNav6XhsM5iJdU27/S6TZB+/7ls3YJmqwU5odSAWBDjFsU/0e9clzRuzf4czXIAw==
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: 287c4f38-5fff-41fa-ae7f-08d7d61d5e6e
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 09:16:32.2068 (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: kbQy/Mg3SHxUNB8S3TOVogPCI5ORrVwfWjf6BSsKNSivm5pG4QDjisyauPJ2yBudt+3P4+HcaxBekHB7/zu+bMjEXyDv3jwLbOoavgKJc1g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0337
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Y6HpsvMExe2NKWwjK-cMQu1FGx0>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
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, 01 Apr 2020 09:16:42 -0000

Michael, Could you clarify what you mean with "EE certificate" and "domain's EE certificate" ? Of which entity? And how can a domain have an end entity certificate - I expect this to always be a CA?

I share Ben's view that the pinned-domain-cert is a CA certificate. If not the case, then the text needs to be updated in several places. 

Based on the discussion, trying to list some practical cases we can have of the pinned-domain-cert:

1. the Registrar's certificate, which is an RA type certificate at least. (It MAY be a CA certificate instead of RA, if the Registrar itself acts as CA non-delegated. )
  This is the most narrow pinned certificate that enables the Pledge to validate the Registrar it's talking to. If we allow RA certificate pinning then the BRSKI text needs to be updated!
2. the Domain CA certificate used by the EST server (=Registrar) to sign newly created certificates. (This MAY equal the Registrar's certificate, although it typically will not be.)
  This is a wider pinned certificate that enables the Pledge to validate the Registrar it's talking to, and also validate the Domain CA that will be used later on to issue operational certificate via EST.
  It is not necessarily a root CA certificate. This case is compatible with current BRSKI text.
3. a Domain CA cert of a domain larger than the above EST CA.
  It is not necessarily a root CA certificate. This case is compatible with current BRSKI text.
4. the root CA cert of the Domain.
  This case seems compatible with current BRSKI text, although the text suggest that typically the root CA is something with wider scope, beyond the pinned-domain-cert. (But not necessarily)

Also there are use cases where full PKI is used, and other use cases where a "cheap" self-signed root CA (not using PKI) is used for e.g. a building installation - I say that both cases need to be supported by BRSKI.
In the latter case, the self-signed limited-scope root CA will typically be used as the pinned-domain-cert. And the EST server will create certificates signed by this same root CA.

Esko

-----Original Message-----
From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Tuesday, March 31, 2020 22:42
To: Benjamin Kaduk <kaduk@mit.edu>du>; The IESG <iesg@ietf.org>rg>; draft-ietf-anima-bootstrapping-keyinfra@ietf.org; anima-chairs@ietf.org; anima@ietf.org; tte+ietf@cs.fau.de
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)


Benjamin Kaduk <kaduk@mit.edu> wrote:
    > My interpretation of "pinned-domain-cert is always a CA certificate" seems
    > to have persistent support throughout the text:

I see how you might conclude that the pinned-domain-cert is always a CA
certificate from the text, rather than being a trust-anchor that the pledge
is to use to validate the chain that it got.

It certainly can be a CA certificate. That does work, because when the
pledge puts it into it's trust-anchor list, the result is that it is able to
validate the TLS Server Certificate of the provisional TLS connection.
But, it has no RFC6125 process it can follow to validate a name.

It does not have to be *the* CA root certificate, it could be some
intermediate CA if such a thing existed (such as an Enterprise CA), and in
some cases, if this was a public trust root and there were no path
constraints, that might actually be *insecure*, since that would authenticate
any TLS connection.

I think that this means that the voucher would be able to validate any
owner within that public CA's list.  It's okay if it's a private CA.

Eliot says in the call:
      The pinned-domain-cert must include sufficient chain to validate the TLS
      connection.  This certificate must only be used for this purpose.
      Longer use trust anchors are retrieved as part of the EST /cacerts request.

My implementation of the MASA puts the EE certificate in which is as narrow
as one can be.  The Siemens implementation puts in the CA certificate, and we
interoperate because of how we treat this on the pledge.  Siemens has much
stronger supply chain restrictions though.



This is the diff that I would make.
I am most concerned about the difference in the voucher:

-        <t hangText="pinned-domain-cert:">The domain CA cert. See <xref
+        <t hangText="pinned-domain-cert:">The domain's EE cert. See <xref

Because this is too narrow rather than too wide now.


diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index b800ec3..3bdf797 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -2143,11 +2143,11 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
             The registrar's certificate chain is extracted from the signature
             method.  The entire registrar certificate chain was
             included in the CMS structure, as specified in <xref target="RequestVoucherFromMASA" />.
-            This CA certificate will be used to populate the
+            The EE certificate will be used to populate the
             "pinned-domain-cert" of the voucher being issued.
           </t>
           <t>
-            If this domain CA is unknown to the MASA, then it is to be
+            If this domain's CA is unknown to the MASA, then it is to be
             considered a temporary trust anchor for the rest of the steps
             in this section.  The intention is not to authenticate the
             message as having come from a fully validated origin, but
@@ -2377,7 +2377,7 @@ INSERT_TEXT_FROM_FILE example-voucher.json END
         <t hangText="assertion:">The method used to verify the relationship
         between pledge and registrar. See <xref
           target="MASAassertion"/>.</t>
-        <t hangText="pinned-domain-cert:">The domain CA cert. See <xref
+        <t hangText="pinned-domain-cert:">The domain's EE cert. See <xref
           target="MASApinned"/>. This figure is illustrative, for an example,
         see <xref target="exampleprocess" /></t>
         <t hangText="serial-number:">The serial-number as provided in the
@@ -2454,10 +2454,12 @@ INSERT_TEXT_FROM_FILE example-voucher.json END
         </section>
         <section anchor="PledgeAuthenticationOfProvisionalTLS"
                  title="Pledge authentication of provisional TLS connection">
-          <t>The 'pinned-domain-cert' element of the voucher contains the domain
-            CA's public key. The pledge MUST use the 'pinned-domain-cert' trust
-            anchor to immediately complete authentication of the provisional TLS
-            connection.</t>
+          <t>
+            The 'pinned-domain-cert' element of the voucher contains the
+            domain CA's issued EE certificate. The pledge MUST use the
+            'pinned-domain-cert' trust anchor to immediately complete
+            authentication of the provisional TLS connection.
+          </t>
           <t>If a registrar's credentials cannot be verified using the
             pinned-domain-cert trust anchor from the voucher then the TLS
             connection is immediately

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