IETF Logo Mail Archive

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

Kent Watsen <kent@watsen.net> Thu, 12 September 2019 17:27 UTC

Return-Path: <0100016d2683dc84-89da1701-908b-4b62-bdd6-fdef27fccc12-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 525C2120869; Thu, 12 Sep 2019 10:27:22 -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 ll1MwmM7ruQd; Thu, 12 Sep 2019 10:27:20 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54869120837; Thu, 12 Sep 2019 10:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568309239; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=RpXJ8aEd1WpxyQu4IBa5sYuvYrNvYk7o3Ew2lsu4Wqc=; b=evxMhfuIQGZp4Zr1dTbZV3KT/BaTCYCN7XmJ2QLLme2cDS0rxHDrILM7yrq7cxRP lOyx5kc6ru/Lj/hnuHKLRtyhe/23WPzOf6f2kuFBVasXhM3h2YZW1AjxdqgrMkeEyir NUMYrftmv6mbKq4rmmw9KzNdwyQEFGH9S55oGCgk=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016d2683dc84-89da1701-908b-4b62-bdd6-fdef27fccc12-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7DFDE744-549B-4852-AFE1-A7698A030D5B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Sep 2019 17:27:19 +0000
In-Reply-To: <29152.1568291600@dooku.sandelman.ca>
Cc: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "mud@ietf.org" <mud@ietf.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <bb757b7b-dffc-9494-4ae0-a709d30445df@ericsson.com> <29152.1568291600@dooku.sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.12-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/RaS-JCxFZPI7KvKrkYEsp-VdpBc>
Subject: Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
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, 12 Sep 2019 17:27:29 -0000

> SZTP does not have voucher-requests.

Indeed.  The tradeoff here is that, in BRSKI, the pledge signs the request and then the local Registrar signs it again, enabling the MASA to verify both.  It's unclear to me what additional security benefits this affords beyond having the request signed by just the Registrar.


> Or at least, does not do them inband in a specific way detailed by a standard.

Correct.  SZTP does not define how the remote peer obtains vouchers.  Voucher's could be prestaged (e.g., on a USB flash drive) or obtained just-in-time via some undefined API.   The SZTP RFC leaves this northbound interaction undefined.   If it is important, an API for just-in-time voucher fetching could be defined.


Another extra thing BRSKI does is using some TLS layer information within the protocol.  I think this is called "channel binding".

Kent

v2.23.0 | Report a Bug | By Email