Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
Mohit Sethi M <mohit.m.sethi@ericsson.com> Mon, 16 September 2019 09:20 UTC
Return-Path: <mohit.m.sethi@ericsson.com>
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 0409C12002E; Mon, 16 Sep 2019 02:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9yvgAQKD4xlU; Mon, 16 Sep 2019 02:19:58 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00085.outbound.protection.outlook.com [40.107.0.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971D2120019; Mon, 16 Sep 2019 02:19:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G4Miq/1ToOFJm0aP3hBHYUXX/Dx5YLhfgbjWPttX7Mnv6YgZA011pSId0UVMgiwvqnYjU0A7HT/0437tZi55EkI5CIHVq0Dc1hIjqjj9XAlGeKJ3QyedGYIpLWe19+z1bfge+T0Vzq8BNO2usydmkzkUoSWAmPEH5Awz9Cp2rf8LcteuIzDBy8tiAwZ/JX6dIRb2ReDU/3DqjEYKW7TJZZE+saO8fKjX5nV4hcn0+Qr3QaFOPMPx/LtOLqgyMLyyYREXki6J8MhZJEbL5rKkxJOhPDZWynjeYb9AC/+RFfFpiUi+uVYm1x9ygi1nvQXU/BltsZ4uiQo8JCXDVdnnug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tAYCQh5zFzHU8prBcPb91flKv96La4kPRD6bjM8fT88=; b=Y9lH33S72ojO3r7CIBe3E/gTJvqZD8gCdWoDNCvDwSEfD7pu8Vgbk3wZl+IlXu43ofQUeiMEPgkHx5iHsoeIdYUJA+E8IN/Um4FHWGrhBo3ZQB2t/6gzZAJX5ARvCv/26BvrMUzVq+8cY9KD911V/1bdNKJNYk7cDAamAS/4cL+QA+rfIGR2vX5t5DmP8lFr0xC6qLtWI1+01pQcgTD9/rvsRrNaZ1fvNIbF+JAZvGHItMpKm6s10KrPi9OPpROC84ffNftfGkojpsiTAXl4sU5H+m50j9aq4AS7JEWpeK2E8txP7JDCJC+DG33GGwNgXzF7WPUATaXf7LYORShgMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tAYCQh5zFzHU8prBcPb91flKv96La4kPRD6bjM8fT88=; b=D1NO19SncykQ4xzrj/PzAVyL3FYQbna8X+dk6r657rb2PgVaKRWcIoKR/JXEIRYDNbOD12TTHhmcS6Ctg1vHA7y1+eiWgXQbsS9pJqQOVwcC01OLdJM1Fma1HDyr9cNUBeZN8/7jcN5pdxNlSqowDZPf9bSfFNhOhSpc8AwbopI=
Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2956.eurprd07.prod.outlook.com (10.168.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.17; Mon, 16 Sep 2019 09:19:54 +0000
Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9%10]) with mapi id 15.20.2284.009; Mon, 16 Sep 2019 09:19:54 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "mud@ietf.org" <mud@ietf.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
Thread-Topic: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
Thread-Index: AQHVaNYdpd2ivcpAw0yCVRFO+FMgJ6cm7z0AgAD66ACAAJVeAIAFjpyA
Date: Mon, 16 Sep 2019 09:19:54 +0000
Message-ID: <202e4ac0-6bdb-4140-1a84-812390667b4d@ericsson.com>
References: <19176.1567583108@dooku.sandelman.ca> <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> <8bc45173-4a00-8a00-35e9-1cad51c559ac@gmail.com> <1e9357be-a384-8663-3142-1b2dfe0a376f@ericsson.com> <86d7f560-eb45-fec1-c98d-91f92c0e1006@gmail.com>
In-Reply-To: <86d7f560-eb45-fec1-c98d-91f92c0e1006@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com;
x-originating-ip: [37.130.181.229]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 968367b3-7227-4945-4ff1-08d73a87093d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2956;
x-ms-traffictypediagnostic: HE1PR0701MB2956:|HE1PR0701MB2956:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB2956FF0FB587C2F5C918E5A1D08C0@HE1PR0701MB2956.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-forefront-prvs: 0162ACCC24
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(39860400002)(346002)(366004)(189003)(199004)(31686004)(14444005)(256004)(966005)(2501003)(606006)(486006)(58126008)(110136005)(478600001)(316002)(25786009)(3846002)(6116002)(86362001)(15650500001)(7736002)(2906002)(14454004)(8936002)(81166006)(81156014)(8676002)(229853002)(66476007)(66946007)(64756008)(66556008)(6486002)(5660300002)(66446008)(26005)(76116006)(99286004)(6306002)(54896002)(6512007)(236005)(53936002)(102836004)(71200400001)(31696002)(71190400001)(6506007)(6246003)(65956001)(53546011)(66066001)(65806001)(6436002)(76176011)(446003)(11346002)(476003)(2616005)(186003)(66574012)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2956; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: jaAK/k6/uHu9c5uGAtYE8KUVcBOWJOfR/UKTRyP5yhVcGJk2ZEqaea6mYM22uhSWcWj/jlHjRh0wppXWpQFqP5CgZSsgM2KVAMd7iVmCcskK9BhbUNTsy/H+6lp1Hch7l3GHXGX7WDiTRUd2ok8Dg4SUBToH+h59kkyUxzjQSJg9RQIyao3ia3DjNLhi200GunpsRUn4Pri/DEuPxiVzXOsdyYB/m85G6Fw1iEpp9NLiO/oJvVDGnLmo4tGcEytiItH19OoQpSE6xw8BAXp+OhYHyNSXGAQxz30krH1paRWRXTlemGto/1eEBmthRPtpUCplkqEEgkv6dvVXZZEWPR7qJcJ7jw30GkHVsSNEakby7ddJt1OLjXnG3QV1Wp7EScipmev3yppMKPN/HqTWsFyLoV55YHAIWAWSij761Y0=
Content-Type: multipart/alternative; boundary="_000_202e4ac06bdb41401a84812390667b4dericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 968367b3-7227-4945-4ff1-08d73a87093d
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2019 09:19:54.4834 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VOxRhAlsIF4T1RgKcAQoKTjKj5Zo3xSGQHlv65G5V9S/b7BSpq/KgRgaJmUyTeCMd1mCDS8UwYx4aBoa1stUANExqn/9bwVuPOhr9+upo48=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2956
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/6xe-sl7ERz5IROpqbbN34V-I3aI>
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: Mon, 16 Sep 2019 09:20:02 -0000
Hi Brian, A protocol that has many dependencies (or gaps) is not ideal from my perspective. A protocol that requires V from chip vendor, W from the device manufacturer, X from certificate authorities, Y from the network administrator, and Z from the user is not a good protocol. Note that this is a hypothetical protocol that thankfully doesn't exist. I agree with your statement that IETF should not produce standards with gaps. But the solution is not to fill those gaps. A better solution is that our protocols shouldn't have too many dependencies in the first place. --Mohit On 9/12/19 11:28 PM, Brian E Carpenter wrote: Hi Mohit, With my limited experience of IETF, I certainly don't think IETF is in the business of building ecosystems No, but the open source community that uses our standards definitely is in that business, so interoperable standards need to help such work. (and neither should it be). However, the IETF should not produce standards with gaps that encourage proprietary ecosystems that allow customer capture. That's exactly why ANIMA includes a reference model as well as specific standards. It encourages each vendor to provide a MASA and encourages network operators to mix and match products from multiple vendors. Whether the BRSKI/MASA model generalises beyond autonomic networks remains to seen, but again: it was not designed for IoT. Regards Brian Carpenter On 12-Sep-19 23:33, Mohit Sethi M wrote: Hi Brian, IETF is in the business of building tools (i.e. open specifications with running code) for developers. And these tools are best built in working groups which have the expertise on them. Most people outside the ANIMA community would not know what is a MASA. Similarly, most people outside the EMU community would not know that Session-Ids for fast re-authentication must be exported by all EAP methods. I agree with folks that there may be multiple solutions that are relevant to the bootstrapping problem. But each of those should developed in working groups where the relevant expertise is present. One could argue that that we would end up developing different solutions for the same problem in silos. However this why we have the IESG ,the directorates, and liaisons to other standards bodies. It ensures that we are aware of related work ongoing in different fora. With my limited experience of IETF, I certainly don't think IETF is in the business of building ecosystems (and neither should it be). --Mohit On 9/11/19 11:35 PM, Brian E Carpenter wrote: Hi Mohit, On 12-Sep-19 07:21, Mohit Sethi M wrote: Hi Michael, I wonder why a new working group is needed and why this work cannot be pursued in some of the existing working groups? I suppose ANIMA was recently re-chartered (and can be re-chartered again). We've been very insistent that ANIMA is scoped for professionally managed networks. That is not, IMHO, a reasonable restriction for IoT; so the ANIMA scope is narrower. Also, ANIMA is scoped for autonomic management, with bootstrap and security being only part of the requirements; in that sense, the ANIMA scope is broader. EMU is currently going over the re-charter text. I know little about EAP, but it seems to me that although it may well be a primary tool for on-boarding, it is only a tool, and not a complete ecosystem. The "Thinking through onboarding" thread scopes the wider problem nicely. Regards Brian Also, you write: adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possibly a version of EAP-NOOB), There is clearly some misunderstanding about EAP-NOOB here. EAP-NOOB is specifically intended for registering new IoT devices on a server (and associating it with a user account). The fact that it provides network-access credentials is a bonus. Please have a look at slides 3-10 here: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-nimble-out-of-band-authentication-for-eap-eap-noob-draft-aura-eap-noob-04-01 You clearly see a AAA server in the figures. So calling it AAA-less doesn't make sense. --Mohit On 9/4/19 10:45 AM, Michael Richardson wrote: I wrote this last week, and passed it around for obvious objections. https://github.com/mcr/iotwg-charter/blob/master/iotwg-charter.md You can use the crayon/edit button on github to suggest changes, or email. Charter for Working Group The words "Internet of Things" or IoT have come to mean anything and everything to a wide group of technology players. The IETF has been working on a wide variety of protocols for use by machine to machine communication. This include CoAP, CBOR, 6TISCH, ROLL, SUIT, NETCONF SZTP, T2TRG, ANIMA's BRSKI onboarding protocol, and most recently RFC8520, the Manufacturer Usage Description. The IETF has tried to focus on categories of what limited things can do, and this has resulted in a number of useful documents from the Light-Weight Implementation Guide (LWIG). RFC7228 is a key product, having provided terminology and scaling understanding to the entire industry. All of this has been about scaling the Internet technologies to small devices and constrained networks. In aggregate, these devices on small networks present a significant operational risk to the Internet as a whole, and even to individual Enterprise, simply due to their numbers, and lack of opportunity for regular human supervision. IoT devices already exist today in vast numbers. Most devices that people are personally familiar with are in the BlueTooth Connected devices, or Web-Connected devices that use WiFi to reach servers on the Internet ("the Cloud"). Increasingly, the IETF view of machine to machine communications are colinizing new greenfield situations. The IETF notion of autonomous networks of devices is still a minority view compared to the market IoT industry of cloud-only connected devices, but the transition is occuring. RFC8520 was created to bridge the gap between devices wholly controlled by a local operator (such as Enterprise IT), and devices which can not assume any infrastructure at all, and must rely entirely on cloud communications for command and control. This working group concerns itself with Operational Security of IoT systems. This includes: * factory provisioning of devices * onboarding of devices * access control of devices to network resources * administrative control of devices * asset management of devices, as it pertains to software/firmware versions * isolation/quarantine of devices * remediation of broken devices * end of life management of devices The WG is chartered explicitely to work on MUD (RFC8520) and extensions to it. The WG is chartered to work on onboarding protocols, specifically including derivaties of BRSKI (RFC-tbd), but not limited to just that protocol. The WG is not expected to pick a winner, and is encouraged to work on a multitude of use-case specific protocols: better to get one use case right, than to be too-complex jack of all trades. The WG is expected to articulate clear applicability statements for each protocol. The WG is expected to produce concise Roadmap documents that explain how a variety of IETF (and other) protocols can work together to satisfy the Operational needs of specific IoT areas. These roadmap documents needn’t result in RFCs. Neither the WG nor the IETF has exclusivity here, and an ideal document would be one that the WG helps to start, but a specific industry alliance becomes the lead editor for. There will be coordination with many other WGs beyond the list above, and this WG may accept applicability statement work from other WGs about specific ways to deploy their protocols. The WG will operate through a series of virtual interim meetings. This is driven by a need to interact regularly with other industry grouops, and due to the variety of topics which will not always be able to get quorum as a committee of the whole. {unusual, maybe not charter appropriate, but rather saag-like} During in-person meetings, the WG will deal with typical status and document progress issues during one hour (or less) of the time, and during another hour, will be open to slideware presentations and tutorials on current IETF or other-SDO IoT efforts. The goal of these presentations is to quickly communicate current IoT systems state to the rest of the IETF. It is acknowledged that part of the value is in YouTube content, and some content should be done at IAB tech plenaries rather than at the WG. The initial set of work items is included below as milestones, which only require AD approval. Milestones * adopt the constrained-voucher/constrained-BRSKI work from ANIMA. * adopt the dtsecurity-zero-touch work from 6tisch, which can not finish before a LAKE finishes. * create a list of a series of MUD extensions, and revise this milestone * adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possibly a version of EAP-NOOB), that can be used at the retail level. * negotiate with EMU WG on how to proceed with TEAP-BRSKI, and revise this milestone. * adopt a cloud-driven onboarding mechanism that can be used in completely offline situations without requiring renewals (perhaps revising RFC8366). ....
- [Iot-onboarding] some straw-man charter text for … Michael Richardson
- Re: [Iot-onboarding] some straw-man charter text … Kent Watsen
- Re: [Iot-onboarding] some straw-man charter text … Michael Richardson
- Re: [Iot-onboarding] some straw-man charter text … Kent Watsen
- Re: [Iot-onboarding] some straw-man charter text … Mohit Sethi M
- Re: [Iot-onboarding] some straw-man charter text … Mohit Sethi M
- Re: [Iot-onboarding] some straw-man charter text … Kent Watsen
- Re: [Iot-onboarding] some straw-man charter text … Brian E Carpenter
- Re: [Iot-onboarding] some straw-man charter text … Brian E Carpenter
- Re: [Iot-onboarding] some straw-man charter text … Mohit Sethi M
- Re: [Iot-onboarding] some straw-man charter text … Mohit Sethi M
- Re: [Iot-onboarding] some straw-man charter text … Michael Richardson
- Re: [Iot-onboarding] some straw-man charter text … Michael Richardson
- Re: [Iot-onboarding] some straw-man charter text … Michael Richardson
- Re: [Iot-onboarding] some straw-man charter text … Kent Watsen
- Re: [Iot-onboarding] some straw-man charter text … Brian E Carpenter
- Re: [Iot-onboarding] some straw-man charter text … Mohit Sethi M
- Re: [Iot-onboarding] some straw-man charter text … Eliot Lear