Re: [Mud] [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG

Kent Watsen <kent+ietf@watsen.net> Wed, 11 September 2019 20:30 UTC

Return-Path: <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@amazonses.watsen.net>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832CE1201CE; Wed, 11 Sep 2019 13:30:21 -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 Widleb_DkGZC; Wed, 11 Sep 2019 13:30:19 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9D7120227; Wed, 11 Sep 2019 13:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568233818; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=7u2eWyazOweOCfOYUgpmJoHsbzizX/KNYrth4oMcGTE=; b=j7VKl+l6ipinxvLViFoPc4KYeVfXGeK2pPkF7SVKm9dW3Pg9x/z3Z0C6bWWPL51h fyurw24LOsoVvOu2Qid2txIcvK4x3F/G4FEXN+E/qUljwJU+eMm4hZrmM7vOm6THKHD 1O/US1ZvaHAMK6BOv7kN5MmKLJ3/oRNnEX3Vhh18=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FB7F2BD-5215-4745-AD0F-445272E481C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 11 Sep 2019 20:30:18 +0000
In-Reply-To: <bb757b7b-dffc-9494-4ae0-a709d30445df@ericsson.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "mud@ietf.org" <mud@ietf.org>
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>
References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <bb757b7b-dffc-9494-4ae0-a709d30445df@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.11-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/TW5KL7wkkD6hsHpMikDDmYAwvNI>
Subject: Re: [Mud] [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2019 20:30:22 -0000

Hi Mohit,


> Could you explain the high-level differences between BRSKI and SZTP for those like me who are not extremely familiar. 
> I know there are probably many differences. For example, I see that the SZTP spec says that devices can receive initial bootstrap information over DNS or from a bootstrap server. 
> 
> What I am trying to understand is what does a device start from (shared-secret/ephemeral key pair/manufacturer certificate), and what does it end with? Do we need both SZTP and BRSKI?
> 
Top of mind.


Preconditions:
- SZTP: secure device identity certificate SHOULD (e.g., IDevID RECOMMENDED), alternate credentials possible.  Optional list of TA certs for validating SZTP servers.  Optional list of TA certs for validating vouchers.
- BRSKI: IDevID MUST.  List of TA certs for validating vouchers MUST.

Normal Operations:
- SZTP: many modes here, some doesn't require networking.  Vouchers only needed when TLS can't be used or trusted.   Vouchers, when used, are primarily long-lived, but MAY be ephemeral (e.g., nonced).  Primarily with strong ownership verification, but weaker forms are possible.
- BRSKI: singular mode (pledge looks for a Registrar).  Vouchers are always used and are primarily conceived to be ephemeral (nonced) with a MASA that maintains a log; long-lived Vouchers and strong ownership-verification are possible.

Postconditions:
- SZTP: a "payload" that could be as small as a script or as large as instructions for updating the OS image + setting an initial configuration.
- BRSKI: a domain certificate.  Additional mechanisms needed to get device into a managed state (this is what some of the other ANIMA drafts are for)


I think I got the BRSKI parts right, but hope folks will chime in if anything is misrepresented or underrepresented.

Kent