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

Brian E Carpenter <> Wed, 11 September 2019 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FFEF1207FF; Wed, 11 Sep 2019 13:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zMzBbWWlsXz8; Wed, 11 Sep 2019 13:57:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 257E6120289; Wed, 11 Sep 2019 13:57:54 -0700 (PDT)
Received: by with SMTP id d10so12146789pgo.5; Wed, 11 Sep 2019 13:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zBpA9dunqZc3bJgeNLynZJrv6M5YCeknE/glAa4Bscc=; b=sGC4hqEtHO9YqALwFMaPofNI5Jbcd7FU4rm+b6zCb3LhdvIQ270rJNmJBPZtYNdryr gbCbP17/xbAY1jwaYHFIWIJBdbsDiQ+cDmCg4ifL7vf9ZKXUE/1110+AZv2m64pM/kvz f1/Grw6mKPIhIrrgjJDNNmLrWgceuyOHVB1d0IwKl9P6uw946Qdhqubm7/0+YyESftVD jqkhD03oudzHD5ufMML2PIjI8PXQu2F0DtlLvYOoBSKWdZI0+czSIG7jIGLftM4oAKXE EfgamaOvW87uOjdewGGFAXF7N25uVSguJSonv1r/mFGM5LJZwNy9O8f2/2sCwmYLhw/n /SIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zBpA9dunqZc3bJgeNLynZJrv6M5YCeknE/glAa4Bscc=; b=Q1dfQGFrjl5P6WUEIYrJ2ZXvxkKczsh+SjzkaQPm2L5BvMaddaeBbCCdKzYhOU1+Kg +AzXyqYwAlJNT65+2+WOQozpsSr3Hr26A/Ytgdywg3UR+OymKU4QH+6F97p/dH5hNtIY 91qzzekZ9H/hVu+49UwxATQkGgtDP53nJpwr4edYG/BtGxUGz8/3F0RISk8Te2D7alhM cKXEibgNPBsoqZDYchz331BEMGvZVBF9GLHXdubTKflWUeAhvDd3dM1XPYSZW/Rgji7r /Vq+y1+bh7kiAXWEh0c+eWNvUPCQSUYPV1bKd8sAAV0IU6AGOVxdYdDxmJHSUFRcSnpr Is+Q==
X-Gm-Message-State: APjAAAVhEdg1sFyKBa2Up1o4g/qZjIakf/Yhq4sulEWJDjOh7umHnn7O QOeaSgKpIlYplq8kcPYXcAEVVp+i
X-Google-Smtp-Source: APXvYqx4qAAfFcXECdZmeAWuM9CYT6FgAH14rj9PwOfJJa/dO/GSQd+9spEJKacbWluer7hKfUtbfg==
X-Received: by 2002:a62:f246:: with SMTP id y6mr44572568pfl.22.1568235473422; Wed, 11 Sep 2019 13:57:53 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j7sm23048011pfi.96.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2019 13:57:52 -0700 (PDT)
To: Kent Watsen <>, Mohit Sethi M <>
Cc: Michael Richardson <>, "" <>, "" <>
References: <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 12 Sep 2019 08:57:48 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2019 20:57:56 -0000

I think it's worth adding that BRSKI was designed for a specific purpose, namely enrolling *only* a set of authorised autonomic nodes into an autonomic control plane, not for enrolling everything in sight (or do I mean "in site"?) into a data plane. It was designed as an integral part of the ANIMA framework (see BRSKI may prove to have more generality than that, but it wasn't an explicit goal.

We were always aware of SZTP while BRSKI was developed, and vice versa, but it wasn't a competition.

   Brian Carpenter

On 12-Sep-19 08:30, Kent Watsen wrote:
> 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