Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 02 October 2018 22:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136271311C0; Tue, 2 Oct 2018 15:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qQKT3yRnMO-M; Tue, 2 Oct 2018 15:53:04 -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 64E411311BD; Tue, 2 Oct 2018 15:53:04 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A7CD20090; Tue, 2 Oct 2018 18:53:02 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 4DB45230F; Tue, 2 Oct 2018 18:53:03 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4A600230C; Tue, 2 Oct 2018 18:53:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, Security Directorate <secdir@ietf.org>
In-Reply-To: <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <m2murxi8ws.wl-randy@psg.com> <b4a32733-c2df-6bea-17d2-4d45ee4d5136@cisco.com> <m2wor0h9vu.wl-randy@psg.com> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <m2d0ssh661.wl-randy@psg.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com>
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: Tue, 02 Oct 2018 18:53:03 -0400
Message-ID: <23133.1538520783@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SrSbPufyttZef81-TWsxFF4bEC0>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Oct 2018 22:53:06 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
    > If I had my wishes, the MASA would be optional, with a local voucher
    > store in the registrar as the alternative. But that wasn't the WG
    > consensus.

So you speak of non-expiring nonceless vouchers with wildcard for the domain
owner, that would come with the device?  I.e. a bearer voucher/token on a QR code.

We decided that such a thing was fraught with issues.

So we painted around it, and declared that version out of scope for now,
because we didn't think we were smart enough to figure out the security
implications of it. (We did this in RFC8366, btw)

In particular, we did not think it had a place in the medium to high-value
devices that we expect ANIMA ACP BRSKI to deal with.
[i.e. routers, VM hosts, NAS boxes... not light bulbs]

I think that there are better ways to deal with a bearer voucher,
and that a layer of intermediation would help with the issues possible
with a bearer token.  This may suit "ship and mostly forget" situation,
but I also think it's squarely an IoT application, rather than appropriate
for BFRs.

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