IETF Logo Mail Archive

Re: [Iot-onboarding] [Anima] Device Certificate Deployment Automation with ACME using BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 09 August 2019 15:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4921712016F; Fri, 9 Aug 2019 08:16:35 -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 7bl0Tv25Ss_m; Fri, 9 Aug 2019 08:16:33 -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 A3F62120052; Fri, 9 Aug 2019 08:16:25 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C62E3818F; Fri, 9 Aug 2019 11:15:44 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2C6D91027; Fri, 9 Aug 2019 11:16:24 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kent Watsen <kent+ietf@watsen.net>
cc: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.com>
References: <CAGL6epJRmAvDB4=M6RiQaC93wvy1XDgcbhOmuKUtqmEhBWC72w@mail.gmail.com> <DM6PR11MB3385FD834E826E25160B53AADBD50@DM6PR11MB3385.namprd11.prod.outlook.com> <DM6PR11MB33851A9026943624FC5BD478DBD50@DM6PR11MB3385.namprd11.prod.outlook.com> <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <3508.1565212944@localhost> <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> <16648.1565297443@localhost> <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.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: Fri, 09 Aug 2019 11:16:24 -0400
Message-ID: <18641.1565363784@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/w4uzvVN5rij_ALuDQAfroVIEO6c>
Subject: Re: [Iot-onboarding] [Anima] Device Certificate Deployment Automation with ACME using BRSKI
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2019 15:16:36 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
    >> But, more interestingly, it can be used to update the trust anchors, to
    >> enable a resale/transfer of ownership!

    > I think I see a smiley-face here too  ;)

Sadly, no.

    > But, seriously, no.  It's expected that decommissioning will returned a
    > device back to its factory default state.  No manufacturer will agree
    > that it is anything other than the state of the device when it was
    > manufactured.   Anything other than that could be leveraged to mount an
    > attack.  Change in ownership-assignment needs to occur through some
    > other means, of which there are many but, in the end, if the 2nd-owner
    > cares about the security (not just the convenience) of bootstrapping,
    > then they are strongly advised to purchase never before used
    > equipment.

This is indeed the tussle the BRSKI document has been dealing with
in its IESG review.  If we can't change the trust anchors used to verify
the voucher, then how can the device be onboarded after the MASA
has gone away?

I don't understand how RFC8572 slipped through the IESG without resolving this.

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

v2.23.0 | Report a Bug | By Email