IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 15 August 2019 16:17 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 4399F1200B8; Thu, 15 Aug 2019 09:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UKOUVPGYIVt7; Thu, 15 Aug 2019 09:17:24 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFBD1200C1; Thu, 15 Aug 2019 09:17:23 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EC1E3818C; Thu, 15 Aug 2019 12:16:33 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C0566D1C; Thu, 15 Aug 2019 12:17:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG <iesg@ietf.org>, anima@ietf.org
In-Reply-To: <20190813172532.GM88236@kduck.mit.edu>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: Thu, 15 Aug 2019 12:17:22 -0400
Message-ID: <6154.1565885842@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/RIZLRuKmZ1dvDMLrGryKIgtjYBA>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (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, 15 Aug 2019 16:17:26 -0000

Benjamin Kaduk <kaduk@mit.edu> wrote:
    doc> The MASA and the registrars SHOULD be prepared to support TLS client
    doc> certificate authentication and/or HTTP Basic or Digest
    doc> authentication as described in [RFC7030] for EST clients.  This
    doc> connection MAY also have no client authentication at all (Section
    doc> 7.4)

    >> > I don't see discussion of skipping client authentication in Section
    >> 7.4.  > It would be great to have some, there!

    >> It's buried in point 2.

    > Oh, the "not verifying ownership" part?  I somehow was interpreting
    > that as "we still require client authentication, but don't have a fancy
    > database mapping owner to hardware, so any authenticated registrar can
    > get a voucher for any device".

There are multiple models on how to operate a MASA.
We think that which one is right depends a lot on the value of the device
(in the ACP space, $100K routers vs $100 CPE devices), and also at the degree
of sales channel integration.
There is value in authenticating the Registrar, even if one does not know
which device has been deployed.  In particular, this model supports the <4h
SLA on service repair that most vendors have, and which they support by
stocking spares in the local city, but not for a specific customer.

I see that I've answered the rest already.
The perils of all these CCs.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email