Re: [Anima] My comments about draft-richardson-anima-registrar-considerations-02:

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 13 March 2020 18:58 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 505FB3A0967 for <anima@ietfa.amsl.com>; Fri, 13 Mar 2020 11:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 m0yh0GE_RZXH for <anima@ietfa.amsl.com>; Fri, 13 Mar 2020 11:58:13 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A3D3A093C for <anima@ietf.org>; Fri, 13 Mar 2020 11:58:12 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 65C4A3897C; Fri, 13 Mar 2020 14:56:53 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5628D11A; Fri, 13 Mar 2020 14:58:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Xialiang \(Frank\, Network Standard & Patent Dept\)" <frank.xialiang@huawei.com>, "anima\@ietf.org" <anima@ietf.org>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13EC88B67@DGGEMM531-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13EC88B67@DGGEMM531-MBS.china.huawei.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Fri, 13 Mar 2020 14:58:05 -0400
Message-ID: <19232.1584125885@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/cQXJGMrmYCKwwCCv2atNznd7gi8>
Subject: Re: [Anima] My comments about draft-richardson-anima-registrar-considerations-02:
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: Fri, 13 Mar 2020 18:58:17 -0000

"Xialiang (Frank, Network Standard & Patent Dept)" wrote:
    > pg 6:

    > with CoAP/EDHOC, then a
    > plain CoAP interface is used, and the security (EDHOC and OSCORE)
    > lives above CoAP. For CoAP/DTLS (CoAPS) then there is DTLS layer
    > below the CoAP layer.


    > comment:
    > The first sentence can cover the last sentence.

I don't quite agree.
To an observer, either port 5683 (CoAP + EDHOC), or port 5684 (DTLS + CoAP)
is used.  This occurs through the Join Proxy.  I am rewritting.
See:
https://github.com/mcr/registrar-operational-considerations/commit/9e7461a567deb58a56d791202e8910fcd6c853bf



    > pg 6:

    > The Pledge Inteface does not require a public IP address, nor does it
    > have have to run on port 443.

    > comment:
    > use its link-local ipv6 address?how about port?

The port is announced within an ACP by GRASP AN_Proxy announcement.
When outside of an ACP context (such as with friel-anima-brski-cloud), use of
port 443 is optional as a full URL will generally be communicated.
Changes at:
https://github.com/mcr/registrar-operational-considerations/commit/26ada19df4f2178647c52fbfec537e2f2e830509


    > pg 6:

    > Outside of the ACP context, running the Pledge interface on an IP
    > address that has a FQDN that resolves to that IP address (if only
    > internally), and operating it on port 443 may have operational
    > advantages.


    > comment:
    > this paragraph is confusing, please reword

Reworded with above.


    > pg 7:

    > if the Registrar will also be providing for
    > renewal of certificates using EST, then it SHOULD announce itself
    > inside the ACP using GRASP. Unless made impossible due to loading
    > concerns, it is RECOMMENDED that all Registrar instances offer
    > certificate renewal services in this fashion.


    > comment:
    > announce itself as the EST server?

Yes.  ACP section 6.1.5.1.


    > pg 10:
    > Incidental keys for internal operations,
    > and for the BRSKI-EST server certificate can be done with this single
    > intermediate CA.



    > comment:
    > ? - I guess the question is, what are "incidental keys"

For instance, if an operator has a ticket system or a MRTG monitor,
smokeping, or other operational systems that need HTTPS certificates.
Such systems are usually not visible from the outside, and installing the
enterprise CA into desktop browsers makes sense.


    > pg 12:

    > The presentation tier
    > MUST accept all Client Certificates, many of which might it might not
    > have anchors for.


    > comment:
    > ? - I guess that more explanation is required.

I might prefer that we expand {{I-D.bdc-something-something-certificate}} to
say more!   TLS termination hardware (HTTPS Load balancers) will do the
entire TLS operation, providing HTTP to the next layer of server.  To do so,
they need to process any client side certificates.  The problem is that many
only support verifying known CAs.  In order to work in a Registrar scenario,
they need to accept any certificate chain, and to pass it onwards to the
application server.

I'm not sure how to explain this better.


    > pg 13:
    > In addition to hosting a PKI root, the Registrar needs several other
    > key pairs. They are:


    > comment:
    > It's not clear about what is the PKI root for? for MASA?

The Registrar either runs a Certificate Authority, or connects securely to one.
After onboarding, the Registrar issues an LDevID to each device from the PKI
that it runs/interfaces to.

    > pg 15:
    > The certificate used to sign the voucher-request MUST be the same as
    > the one that is used for the TLS Server Connection. This implies
    > that the signed voucher-request MUST be constructed on the same
    > machine that terminates the BRSKI-EST MASA connection.



    > comment:
    > NIT: BRSKI-EST MASA connection?

fixed.

I will post a new version after I look through some other sets of comments.


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