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

Kent Watsen <kent+ietf@watsen.net> Thu, 08 August 2019 21:26 UTC

Return-Path: <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@amazonses.watsen.net>
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 47A7E1200E5; Thu, 8 Aug 2019 14:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 dIud-0zDF7Ik; Thu, 8 Aug 2019 14:26:39 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2729C120098; Thu, 8 Aug 2019 14:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565299597; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=8AumYJScPhJXlNl/sxKoNYFugakiBCbGvPZQ0p3T1tw=; b=hmZAb1rZeIustsreINA1OzU7d2lOCcCiEsgWrC3BB01g/BUhH6zN9f73xdT05Rs5 KEplfQV0ryOgGFOubOY4N5q4OvYWiZWJRqRBdZR8fj9MYUp0lfO7WSz2GKWvg7xzO4R KEkuMaYzf6KxqdZLQNn/4dQwZp8xU3wrIiTK/E1Q=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F4F2115-A0C1-4F37-AF0B-416B2F6318F9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 08 Aug 2019 21:26:37 +0000
In-Reply-To: <16648.1565297443@localhost>
Cc: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "anima@ietf.org" <anima@ietf.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
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>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.08-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/BurTYVpo6A0IkUtBU9TOSwUfs30>
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: Thu, 08 Aug 2019 21:26:41 -0000


>> It's true that EST isn't used, but there is a mutually-authenticated
>> TLS connection to the SZTP bootstrap server, which is effectively the
>> same as BRSKI's Registrar.
> 
> It's not clear to me that this always occurs in the USB or DHCP cases :-)

To your smiley-face, the ultimate USB use-case entails using no network at all, so you're right that there is no mutually-authenticated TLS connection then!

For all other cases, it's actually possible that the bootstrapping event may lead to a mutually-authenticated TLS connection.  It entails the device consuming "signed data", which means it needs also an "ownership voucher" as well as an "owner certificate".   [note: terms in "quotes" are defined in RFC 8572]



>> Sounds correct, but clarifying:
> 
>> 1) the current keystore model is all about enabling a controller/NMS
>> application to configure/set/push keys and associated end-entity
>> certificates to a device.
> 
>> 2) there is a suggestion that the keystore model could/should be
>> extended to support ACME (or similar), in which case one might claim
>> that the device had "pulled" an end-entity certificate from a "securely
>> identified server" (dropping the "EST" part).
> 
>> 3) the truststore model (draft-ietf-netconf-trust-anchors) can be used
>> by a controller/NMS application to configure/set/push trust-anchor
>> certs used, e.g., to verify a remote server's end-entity certificate.
> 
> 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  ;)

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.


Kent