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

Benjamin Kaduk <kaduk@mit.edu> Thu, 02 April 2020 03:01 UTC

Return-Path: <kaduk@mit.edu>
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 9549A3A07B4; Wed, 1 Apr 2020 20:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 A-_CC2ZSUTFU; Wed, 1 Apr 2020 20:01:25 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0EB993A07B1; Wed, 1 Apr 2020 20:01:22 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03231An8021987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Apr 2020 23:01:14 -0400
Date: Wed, 1 Apr 2020 20:01:10 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, anima@ietf.org, tte+ietf@cs.fau.de
Message-ID: <20200402030110.GF50174@kduck.mit.edu>
References: <158561301296.11367.9776561744635554098@ietfa.amsl.com> <4603.1585620652@localhost> <20200331150202.GH50174@kduck.mit.edu> <19147.1585765530@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <19147.1585765530@localhost>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ZfV589P77wn0X-Q7VQElF7BYg_c>
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: Thu, 02 Apr 2020 03:01:28 -0000

On Wed, Apr 01, 2020 at 02:25:30PM -0400, Michael Richardson wrote:
> 
> Hi, I had a discussion with Max this morning.  He reminded me of the back and
> forth that we made on what thing would be pinned.
> We have come up with the following text changes.
> 
> There are three pieces: the Registrar, to the MASA, and re-inforcing the
> RFC8366 process at the Pledge as it applies to provisional TLS connection.
> 
> I haven't read the rest of this thread.
> I will do that this afternoon, and I may polish this diff based upon comments there.

Thanks, this seems like it will hit all the right spots.
A few aids to polishing inline.

> 
> https://tinyurl.com/uek8a66
> 
> @@ -2043,8 +2044,39 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
>          <t>The voucher media type "application/voucher-cms+json" is defined in
>            <xref target="RFC8366" /> and is also used for the registrar voucher-request. It is a JSON document that has been
>            signed using a CMS structure.
> -          The registrar MUST sign the registrar voucher-request. The entire registrar certificate chain,
> -          up to and including the Domain CA, MUST be included in the CMS structure.
> +          The registrar MUST sign the registrar voucher-request.
> +        </t>
> +        <t>
> +          <xref target="RFC8366" /> is quite flexible in what may be put into
> +          the 'pinned-domain-cert': it may range from the End Entity (EE)

The transition from "registrar voucher request" to "pinned-domain-cert" is
pretty abrupt; maybe something like "the voucher-request CMS object
includes some number of certificates that are input to the MASA as it
populates the "pinned-domain-cert" field of the voucher."?

> +          Certificate that the Registrar uses, to the entire private
> +          Enterprise CA certificate.
> +          More specific certificates result in a tighter binding, while less
> +          specific certificates result in more flexibility.

This leaves what exactly is tightly bound/flexible a bit vague (which may
be good!); if I did want to be more specific it might be "tigher binding of
pledge to authorized entity in the Domain", which ... doesn't exactly roll
of the tongue.

> +        </t>
> +        <t>
> +          A Registrar which is seeking a nonceless voucher for later offline use
> +          benefits from a less specific certificate, as it permits the actual
> +          keypair used by a future Registrar to be determined by the pinned
> +          certificate authority.
> +        </t>
> +        <t>
> +          A less specific certificate, such a public WebPKI certificate authority, would be

Maybe "In some cases a less specific certificate, [...], could be too
open"?
(Add "In some cases" and s/would/could/.)

> +          too open, and could permit any entity that can receive a
> +          certificate from that authority to assume ownership of a device

Maybe "any entity issued a certificate by that authority"?

> +          that has a voucher pinned.
> +          Future work may provide a solution to pin both a certificate and a
> +          name.

", that would reduce such risk of malicious ownership assertions"?

> +        </t>
> +        <t>
> +          The Registrar SHOULD request a voucher with the most specificity
> +          consistent with the mode that it is operating in.
> +          In order to do this, when the Registrar prepares the CMS structure
> +          for the signed voucher-request, it SHOULD include only certificates
> +          which are part of the chain that it wishes the MASA to pin.
> +          This MAY be as small as only the End-Entity certificate (with cmcRC set) that

Hmm, we do use a bare "cmcRC" exactly once in the -39, but id-kp-cmcRA
appears twice.  (I'm not sure whether it matters which one to write.)

> +          it uses as it's TLS Server Certificate, or it MAY be the entire
> +          chain, including the Domain CA.
>          </t>
> 
>          <t>MASA impementations SHOULD anticipate future media
> @@ -2140,19 +2172,29 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
> 
>          <section anchor="MASApinned" title="MASA pinning of registrar">
>            <t>
> -            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
> -            "pinned-domain-cert" of the voucher being issued.
> +            A certificate chain is extracted from the Registrar's signed CMS container.
> +            This chain may be as short as a single End-Entity Certificate, up
> +            to the entire registrar certificate chain, including the Domain
> +            CA certificate,
> +            as specified in <xref target="RequestVoucherFromMASA" />.
>            </t>
>            <t>
> -            If this domain CA is unknown to the MASA, then it is to be
> +            If the 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
>              to establish the consistency of the domain PKI.
>            </t>
> +          <t>
> +            The MAY use as much of the certificate chain that it received

MASA?

> +            from the Registrar as appropriate determined by MASA policy.

Maybe comma before "determined"?

> +            A MASA MAY have a local policy that it only pins the End-Entity
> +            certificate. This is consistent with <xref target="RFC8366" />.
> +            Details of the policy will typically depend upon the degree of
> +            Supply Chain Integration, the mechanism used by the Registrar to

This seems like a misplaced comma or incomplete list or something.

> +            authenticate.  Such a policy would also determine how a
> +            the MASA will respond to a request for a nonceless voucher.
> +          </t>
>          </section>
> 
>          <section anchor="revocationcheck"
> @@ -2377,9 +2419,10 @@ 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:">A certificate. See <xref
>            target="MASApinned"/>. This figure is illustrative, for an example,
> -        see <xref target="exampleprocess" /></t>
> +        see <xref target="exampleprocess" /> where an End Entity certificate
> +        is used. </t>
>          <t hangText="serial-number:">The serial-number as provided in the
>            voucher-request. Also see <xref target="MASAassertion"/>.</t>
>          <t hangText="domain-cert-revocation-checks:">Set as appropriate for the
> 
> @@ -2454,11 +2501,20 @@ 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>If a registrar's credentials cannot be verified using the
> +          <t>
> +            Following the process described in <xref target="RFC8366" />,
> +            the pledge should consider the public key from the
> +            pinned-domain-cert as the sole temporary trust anchor.
> +          </t>
> +          <t>
> +            The pledge then evaluates the TLS Server Certificate chain that it
> +            received when the TLS connection was formed using this trust
> +            anchor.
> +            It is possible that the pinned-domain-cert matches the End-Entity
> +            Certificate provided in the TLS Server.
> +          </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
>              discarded and the pledge abandons attempts to bootstrap with this

How much more polishing/comments do you want before publishing a -40?

Thanks again for putting this together!

-Ben

P.S. If the s/public key/certificate/ from my Comment would make it into
the -40, that would be greatly appreciated.