From nobody Tue Sep 3 06:16:05 2019 Return-Path: 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 BE98C120826; Tue, 3 Sep 2019 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T6XXlthp1j5Z; Tue, 3 Sep 2019 06:15:55 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A91F120052; Tue, 3 Sep 2019 06:15:55 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id j5so35721000ioj.8; Tue, 03 Sep 2019 06:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SzS32ITWnQwFHqfM3CVHorqac+5SWr9ELxXdriki58s=; b=I6HZzhFnS4/0XD9Jfk7uKHeQnmnuxclT5und7Z6vkxwV9sYxpOPcMhdFTUML7ZtUqw NAyvy8DM7y8EZFM/6oEgU3lUE+Wqqmf9BQiVw3WdI2JlM76EfyicaRokUgAR0V3EhbN6 TJiokKwhmmNlcOyYhTmr3+rd863KM/CqA01993M/xHphbR9ZhCKR0curUhHJuK4/RfP7 VZghvXU33DOpL5OZJr2Sh0LJCaiGoWsVQ4RQLk9wBJRg3LmD/FCF0M6pTANNhCIrA4k0 FJzUYfQeRifo9VMaSm5+GW57MZXAUF7ElFENxcjzcevr8OoRI05BIaIXakRYDT8qC9Lz xjmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SzS32ITWnQwFHqfM3CVHorqac+5SWr9ELxXdriki58s=; b=IwRvCGiZyKk76it+Wy3K2c1EzcT5GvDTINDDs3Fnxk1w1WpFaU48Zx71TVRG32mepI dWSD4dwBGovOgsX7CY7/Hfckj/iC3ePKlxitB5NuHOCaj9jcSkxJQ9AuZmZzJNgzcZ5S 802EsN8CI5ApV7drFE89W7WKs7pTB4a9XAH3EfDXXJfQ03F3p+aZ/NpAoUUeNIg32xRz a4XJucu1Zr9ATjMpXcV4387d3h/dWDJjgWEu0dV+/2t39FkQQm74pim91BeizjKv98qW ajv+EXJJS9yZNyVc4AFFvqCInrflcUoCEQW16wTAyLURI2pGWkzKSxjh8blCFvEO8xBA +xHQ== X-Gm-Message-State: APjAAAVObfiuv867rT3H3Axq2JDTyY0FgdFvx5adnnAQibkK++CFjzzP drhzYQxDAxqF2ILdVjPuvPJK89FiHU0OLGifQot1oD0A X-Google-Smtp-Source: APXvYqz6FtSitlw7hBoEakm3AopwpYoww/Jy/7Gejgd3+LuQH62BirGzZBec3iwAsH+7WfTCY5J3TxrKea1NoOoW9A8= X-Received: by 2002:a5e:8b06:: with SMTP id g6mr3227061iok.242.1567516554058; Tue, 03 Sep 2019 06:15:54 -0700 (PDT) MIME-Version: 1.0 References: <156750742337.9752.15749363710921341398.idtracker@ietfa.amsl.com> In-Reply-To: <156750742337.9752.15749363710921341398.idtracker@ietfa.amsl.com> From: tirumal reddy Date: Tue, 3 Sep 2019 18:45:40 +0530 Message-ID: To: opsawg@ietf.org, mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000006260510591a5e33b" Archived-At: Subject: [Mud] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 13:16:04 -0000 --0000000000006260510591a5e33b Content-Type: text/plain; charset="UTF-8" Hi all, This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01 updates the MUD (D)TLS profile to include grease extension, visibility into TLS 1.3 parameters, pre-shared key exchange modes and Encrypted SNI. We observed several IoT devices are already using Grease extension. Comments and suggestions are more than welcome. Cheers, -Tiru ---------- Forwarded message --------- From: Date: Tue, 3 Sep 2019 at 16:13 Subject: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt To: Tirumaleswar Reddy , Dan Wing A new version of I-D, draft-reddy-opsawg-mud-tls-01.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-opsawg-mud-tls Revision: 01 Title: MUD (D)TLS profiles for IoT devices Document date: 2019-09-03 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-01.txt Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/ Htmlized: https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls Diff: https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-01 Abstract: This memo extends Manufacturer Usage Description (MUD) to model DTLS and TLS usage. This allows a network element to notice abnormal DTLS or TLS usage which has been strong indicator of other software running on the endpoint, typically malware. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000006260510591a5e33b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This revision https://tools.ietf.org/html/draft-= reddy-opsawg-mud-tls-01 updates the MUD (D)TLS profile to include greas= e extension, visibility into
TLS 1.3 parameters,=C2=A0 pre-shared key exchange modes=C2=A0and = Encrypted SNI.

We observed several IoT devices are already using Gre= ase extension.

Comments and suggestions are more than welcome.
Cheers,
-Tiru

---------- Forwarded message ---------
From: <internet-drafts@i= etf.org>
Date: Tue, 3 Sep 2019 at 16:13
Subject: New Ve= rsion Notification for draft-reddy-opsawg-mud-tls-01.txt
To: Tirumaleswa= r Reddy <kondtir@gmail.com>,= Dan Wing <danwing@gmail.com>= ;



A new version of I-D, draft-reddy-opsawg-mud-tls-01.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-opsawg-mud-tls Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUD (D)TLS profiles for IoT device= s
Document date:=C2=A0 2019-09-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud= -tls-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-opsawg-mud-tls-= 01

Abstract:
=C2=A0 =C2=A0This memo extends Manufacturer Usage Description (MUD) to mode= l DTLS
=C2=A0 =C2=A0and TLS usage.=C2=A0 This allows a network element to notice a= bnormal DTLS
=C2=A0 =C2=A0or TLS usage which has been strong indicator of other software=
=C2=A0 =C2=A0running on the endpoint, typically malware.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--0000000000006260510591a5e33b-- From nobody Wed Sep 4 00:44:50 2019 Return-Path: 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 69CB51200CE; Wed, 4 Sep 2019 00:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MlUIaCdz6jbh; Wed, 4 Sep 2019 00:44:38 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7044C1200F1; Wed, 4 Sep 2019 00:44:38 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [89.248.140.11]) by relay.sandelman.ca (Postfix) with ESMTPS id 6920D1F45A; Wed, 4 Sep 2019 07:44:36 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 031A1167E; Wed, 4 Sep 2019 03:45:09 -0400 (EDT) From: Michael Richardson To: mud@ietf.org, iot-onboarding@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 04 Sep 2019 03:45:08 -0400 Message-ID: <19176.1567583108@dooku.sandelman.ca> Archived-At: Subject: [Mud] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 07:44:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.=20 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 h= as been about scaling the Internet technologies to small devices and constrain= ed networks. In aggregate, these devices on small networks present a significa= nt 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.=20 IoT devices already exist today in vast numbers. Most devices that people a= re 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 a= re 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.=20 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.=20 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.=20 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=E2=80=99t result in RFCs.=20 Neither the WG nor the IETF has exclusivity here, and an ideal document wou= ld be one that the WG helps to start, but a specific industry alliance becomes the lead editor for.=20 There will be coordination with many other WGs beyond the list above, and this WG may accept applicability statement work from other WGs about specif= ic ways to deploy their protocols.=20 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.=20 {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.=20 The initial set of work items is included below as milestones, which only require AD approval.=20 Milestones * adopt the constrained-voucher/constrained-BRSKI work from ANIMA. * adopt the dtsecurity-zero-touch work from 6tisch, which can not finish be= fore 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). ... =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1va4QACgkQlUzhVv38 QpA3ywf/dZj5kIluxgVRs1SYPOKhDxmDCA5Bv6g+WdwvbcOblgsC8lDkG/bPeX67 GZsm58vn9AuokpAET2/E9dmYtoiMkHp/AFAV3f2+2VHyLc40YVsSC9Yi7D8+B27J L+J/6Uw7R1yAcEkSfdlgz1Ae1QyuZIxGZeeE5Fy2PkvIX+xDpf7wd3ZS0Q4ICRv9 3wyFp9HtS+2IKa84V4AvM1Ec0fxUK7mZV10f121QvsEx1kpJlywJQy+BMC4SespU rJdVL8bLKFso14ZG0q9VO64PtxP6tTySD+svZTaRZ+YkG906UmaIyypQ8aHhI5dN kwrJ5N5s+NKQe5p04e0utnWnG4knFQ== =yEEd -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 4 06:47:39 2019 Return-Path: <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-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 33737120106; Wed, 4 Sep 2019 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 ffuerLEuhkbB; Wed, 4 Sep 2019 06:47:12 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C0B120100; Wed, 4 Sep 2019 06:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567604831; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=wPSnHLnOJ8JRtT9bA6Y2IvAP1UVqeBCgjiJzuEWCbdM=; b=ic0XcznTwq89djUZaeGKjrGf+n52/GGjS1zjGgBRDmr3/BabX7zNp3HqiAsGh/pG uCIxZyc836RuShg2bP4Nvzedjnd9XDG+9bYQnCQWp2oseFqQPXgXiJnJ4eRp2EFR6VC bExc0xjsdWCEKZtYXblawmI/lG5fa16JwEdknS2o= From: Kent Watsen Message-ID: <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CB9C3083-C01E-4B02-BCBB-EBE7F22CD12F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Sep 2019 13:47:10 +0000 In-Reply-To: <19176.1567583108@dooku.sandelman.ca> Cc: mud@ietf.org, iot-onboarding@ietf.org To: Michael Richardson References: <19176.1567583108@dooku.sandelman.ca> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.04-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 13:47:15 -0000 --Apple-Mail=_CB9C3083-C01E-4B02-BCBB-EBE7F22CD12F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I'm still not 100% sure if this working group is needed but, if such a = working group is to be formed, I object to it being BRSKI-oriented, as = already there is ANIMA for that. I appreciate that the first paragraph = enumerates a number of efforts (BTW, it should be just "SZTP", without = the NETCONF qualifier), and later the text says that it's "not limited = to just that protocol" (being BRSKI), but the general tone, and = specifically the Milestones, are very BRSKI-specific. To be clear, if = such a working group were formed, I would like to submit a document = entitled something like "SZTP for IoT and other Constrained Devices". = In this document I could show how SZTP could be extended to use DTLS, = CBOR, and CoAP and further, that it achieves bootstrap state with fewer = message exchanges and greater flexibility, not to mention that it = already supports the offline/cloudless use-case and a peusdo-NOOB = approach (already implemented by Juniper). SZTP-TEAP could also be = provided for. Thanks, Kent > On Sep 4, 2019, at 3:45 AM, Michael Richardson = wrote: >=20 >=20 > 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. >=20 >=20 > Charter for Working Group >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > This working group concerns itself with Operational Security of IoT = systems. >=20 > This includes: >=20 > * 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 >=20 > The WG is chartered explicitely to work on MUD (RFC8520) and = extensions to it. >=20 > The WG is chartered to work on onboarding protocols, specifically = including > derivaties of BRSKI (RFC-tbd), but not limited to just that protocol. >=20 > 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.=20 >=20 > 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=E2=80=99t result in RFCs.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > {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. >=20 > 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.=20 >=20 > The initial set of work items is included below as milestones, which = only > require AD approval.=20 >=20 > Milestones >=20 > * 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). > .... >=20 >=20 >=20 >=20 > --=20 > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > --=20 > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding --Apple-Mail=_CB9C3083-C01E-4B02-BCBB-EBE7F22CD12F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I'm still not 100% sure if this working group is needed but, = if such a working group is to be formed, I object to it being = BRSKI-oriented, as already there is ANIMA for that.  I appreciate = that the first paragraph enumerates a number of efforts (BTW, it should = be just "SZTP", without the NETCONF qualifier), and later the text says = that it's "not limited to just that protocol" (being BRSKI), but the = general tone, and specifically the Milestones, are very BRSKI-specific. =  To be clear, if such a working group were formed, I would like to = submit a document entitled something like "SZTP for IoT and other = Constrained Devices".  In this document I could show how SZTP could = be extended to use DTLS, CBOR, and CoAP and further, that it achieves = bootstrap state with fewer message exchanges and greater flexibility, = not to mention that it already supports the offline/cloudless use-case = and a peusdo-NOOB approach (already implemented by Juniper). =  SZTP-TEAP could also be provided for.

Thanks,
Kent





On Sep 4, 2019, at 3:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> 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=E2=80=99t 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).
....




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-


--
Iot-onboarding mailing = list
Iot-onboarding@ietf.org
https://www.ietf.org/mailman/listinfo/iot-onboarding

= --Apple-Mail=_CB9C3083-C01E-4B02-BCBB-EBE7F22CD12F-- From nobody Wed Sep 4 08:12:33 2019 Return-Path: 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 6AE19120132; Wed, 4 Sep 2019 08:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OfezaM5nSTbE; Wed, 4 Sep 2019 08:12:12 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FF012011D; Wed, 4 Sep 2019 08:12:11 -0700 (PDT) Received: from dooku.sandelman.ca (85-76-97-167-nat.elisa-mobile.fi [85.76.97.167]) by relay.sandelman.ca (Postfix) with ESMTPS id 9A0271F45A; Wed, 4 Sep 2019 15:12:09 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B539E2BFB; Wed, 4 Sep 2019 11:12:12 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: mud@ietf.org, iot-onboarding@ietf.org In-reply-to: <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> Comments: In-reply-to Kent Watsen message dated "Wed, 04 Sep 2019 13:47:10 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 04 Sep 2019 18:12:12 +0300 Message-ID: <30978.1567609932@dooku.sandelman.ca> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 15:12:16 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Kent: I am feeling a bit of "my protocol vs your protocol" in your reply. It is not my intention to do that. I think that we did an awesome job getting to the commonalities with 8366. I'm not sure that this is as visible to others. Kent Watsen wrote: > I'm still not 100% sure if this working group is needed but, if such a > working group is to be formed, I object to it being BRSKI-oriented, as > already there is ANIMA for that. Yes, but is that really appropriate? Are the right people there in ANIMA, and is it actually disruptive to the ANIMA effort beyond onboarding? In particular the constrained document is not getting enough attention. > I appreciate that the first paragraph > enumerates a number of efforts (BTW, it should be just "SZTP", without > the NETCONF qualifier), Sure. I put it there so that people could find it. > and later the text says that it's "not limited > to just that protocol" (being BRSKI), but the general tone, and > specifically the Milestones, are very BRSKI-specific. I would very much like to have more, but I don't know what the next steps f= or SZTP are. > To be clear, if > such a working group were formed, I would like to submit a document > entitled something like "SZTP for IoT and other Constrained > Devices". > In this document I could show how SZTP could be extended to > use DTLS, CBOR, and CoAP and further, that it achieves bootstrap state > with fewer message exchanges and greater flexibility, not to mention > that it already supports the offline/cloudless use-case and a > peusdo-NOOB approach (already implemented by Juniper). =20=20=20=20 I actually rather believe that SZTP is probably a better starting point for= a cloudless solution. If SZTP can do a better job for constrained environments, it is *precisely* this kind of stuff that I'd like to have in this group. I'm okay with the WG producing 3 or 4 mechanisms, (and then, of course, an n+1th in four years to converge them, applying https://www.explainxkcd.com/wiki/index.php/927:_Standards) Some have attributed this method to Scott Bradner, imaging a meadow of many wild flowers. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1v1EwACgkQlUzhVv38 QpDr8QgAg50CyYov4uNJTuclb4e6ZLlVOfKMSCQcK2siFqj+2Qs+agXDQy6ar1Lv hUfSl0OJGpx+xuvDG6HkCH22lSX+VRQVY9GhspgajtpJxUYkZR9Wqta+yQzQM7Nc czqrzGlV8fEAVcNF+FAwUCOqW7VRUdH63UcipVFp+W3SZhBd6oLDjlM0BY0vRHTE +JgINxgV4YQwmR9LjtpRFcbuAn3MBGpCyReExfBkIfu9728zyJQdrLZXa8XpBuz4 C2xutvfDsvaRxGCW+LlXRC9cF0OVKcZ36jhCunOr9eARUspbudOcRdxds1fUxMeO KEbxtoku9afDBmWRXV1MNem8oEJjdA== =5Vs/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 4 09:18:36 2019 Return-Path: <0100016cfd11fc06-cacd955b-653b-4b31-996a-275c83b63dce-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 EFC721200B9; Wed, 4 Sep 2019 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 ZxPbbc5xLtGx; Wed, 4 Sep 2019 09:18:32 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90685120912; Wed, 4 Sep 2019 09:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567613910; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=pOJpy6xK2PpZ5rwoXmTz+U+lgFlomcHLF6sqzn8e3P0=; b=XNyLHfSCoS9DcdgNnlFrtyqZlIc9Co9HkMDEMMCA/lduRwotNt1rJLP2faWRm3Qn PXPwXudeRQj7KUvmsoFzQMc4KyBXDeGNUPMQf228VgaT7z7aqEUkJOooCgju8WDSwGu O1Ke4J54RUN4xYC6rrJboc2TXjLJopxvPcp0M9A4= From: Kent Watsen Message-ID: <0100016cfd11fc06-cacd955b-653b-4b31-996a-275c83b63dce-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_562AB405-328D-4ACF-B980-170526FC1774" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Sep 2019 16:18:30 +0000 In-Reply-To: <30978.1567609932@dooku.sandelman.ca> Cc: iot-onboarding@ietf.org, mud@ietf.org To: Michael Richardson References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <30978.1567609932@dooku.sandelman.ca> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.04-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 16:18:34 -0000 --Apple-Mail=_562AB405-328D-4ACF-B980-170526FC1774 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Kent: I am feeling a bit of "my protocol vs your protocol" in your = reply. Fair point. I just want to ensure what you say at bottom... > It is not my intention to do that. I think that we did an = awesome > job getting to the commonalities with 8366. I'm not sure that = this > is as visible to others. Indeed, as witnessed by the plethora of activity brought forth since. = :thumbs-up: > Yes, but is that really appropriate? Are the right people there in = ANIMA, > and is it actually disruptive to the ANIMA effort beyond onboarding? > In particular the constrained document is not getting enough = attention. Unsure. It's a blurred line to me where ANIMA stops and this might = begin... > Sure. I put it there so that people could find it. Okay, but folks should know that, while produced by NETCONF WG, it = really has nothing to do with NETCONF protocol. >> and later the text says that it's "not limited >> to just that protocol" (being BRSKI), but the general tone, and >> specifically the Milestones, are very BRSKI-specific. >=20 > I would very much like to have more, but I don't know what the next = steps for > SZTP are. Mapping to DTLS, CBOR, CoAP, and MUD would be a good milestones. Unsure = how many drafts that might entail. Each topic is likely a small = document, since it's mostly mapping onto other existing work. > I actually rather believe that SZTP is probably a better starting = point for a > cloudless solution. > If SZTP can do a better job for constrained environments, it is = *precisely* > this kind of stuff that I'd like to have in this group. Yes, it would be good if this group could cast a wide net. > I'm okay with the WG producing 3 or 4 mechanisms Perfect. Importantly, some of these mechanisms can be run in parallel, = as they offer similar level of security, and hence a DoS doesn't result = in a degradation attack. > (and then, of course, an > n+1th in four years to converge them, applying > https://www.explainxkcd.com/wiki/index.php/927:_Standards) > Some have attributed this method to Scott Bradner, imaging a meadow of > many wild flowers. Never heard the meadow part before, but the "wild" part seems apt. ;) Kent --Apple-Mail=_562AB405-328D-4ACF-B980-170526FC1774 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Kent: I am feeling a bit of "my protocol vs your protocol" in = your reply.

Fair point. =  I just want to ensure what you say at bottom...


     It is not my = intention to do that.  I think that we did an awesome
=      job getting to the commonalities with = 8366.  I'm not sure that this
=      is as visible to others.

Indeed,= as witnessed by the plethora of activity brought forth since. =  :thumbs-up:


Yes, but is that really appropriate?  Are the right = people there in ANIMA,
and is it actually disruptive to = the ANIMA effort beyond onboarding?
In particular the = constrained document is not getting enough attention.

Unsure.=  It's a blurred line to me where ANIMA stops and this might = begin...



Sure.  I put it there so that people could find it.

Okay, = but folks should know that, while produced by NETCONF WG, it really has = nothing to do with NETCONF protocol.


and later the text says = that it's "not limited
to just that protocol" (being = BRSKI), but the general tone, and
specifically the = Milestones, are very BRSKI-specific.

I would very much like to have more, but I don't know what = the next steps for
SZTP are.

Mapping= to DTLS, CBOR, CoAP, and MUD would be a good milestones.  Unsure = how many drafts that might entail.  Each topic is likely a small = document, since it's mostly mapping onto other existing = work.



I actually rather believe that SZTP is probably a better = starting point for a
cloudless solution.
If = SZTP can do a better job for constrained environments, it is = *precisely*
this kind of stuff that I'd like to have in = this group.

Yes, it would be good if this group could cast a = wide net.



I'm okay with the WG producing 3 or 4 = mechanisms

Perfect.=   Importantly, some of these mechanisms can be run in parallel, as = they offer similar level of security, and hence a DoS doesn't result in = a degradation attack.


(and then, of course, an
n+1th in four years to = converge them, applying
https://www.explainxkcd.com/wiki/index.php/927:_Standards)<= br class=3D"">Some have attributed this method to Scott Bradner, imaging = a meadow of
many wild flowers.

Never heard the meadow part before, but the "wild" part seems = apt.  ;)


Kent







= --Apple-Mail=_562AB405-328D-4ACF-B980-170526FC1774-- From nobody Fri Sep 6 16:17:51 2019 Return-Path: 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 D81EE120E0E for ; Fri, 6 Sep 2019 16:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=flowtools-net.20150623.gappssmtp.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 pOd4ppR-ijEn for ; Fri, 6 Sep 2019 16:17:43 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97601208EE for ; Fri, 6 Sep 2019 16:17:43 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id j4so16502642iog.11 for ; Fri, 06 Sep 2019 16:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowtools-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=XVKr/CL08wZIjs+BvOZMhFG/RbzgUcFO3gQpENnxdJk=; b=hTRgtRY+sQl3WyjlzeXPjfoI37sYf31dlgzw2O7Z051dWf+C8hgKvN/JJGE5Gr53nV B2+6Qj+eO7nI9k3XTkNOUCbZEud0ezkqrD5p8rLTTxEdg7KqFYXJaACO9CprxotaEIqm X1DvzIRV249bW3kK8Wf75p7HxI2yyspWpymSNha8nyYes+1NLpAaJeubSnVnzNj0HxLd rHoctJ6O0Md3ABJxiC2VIrW0v+N/GqrL8bOkIwhlkQ6uwj7W/ObKmtOD3dmdj1ZCwwVs yubya8ACKBe49Qc//rSL14+ATtS1oHM5W8oRyDffFskLxxdk6fWWzVlS52PFEM+x1pw1 0hEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=XVKr/CL08wZIjs+BvOZMhFG/RbzgUcFO3gQpENnxdJk=; b=crnyoiWYxGm016P6eXwyD0cGVZKMpWWhN7eJFB5qDPODarOkI8jc7J7z6XUsb7F2SS H49G1H1FCA1bWL0/XnEZ3bJOdXfy54fyHckVJP4zT/XXZbnrW9UCs7FdkgZWq6ySHVkb bI+md3A44gJoVuUGUlB6gkO4Bak7U3yrLAV3cUQYsequL8UT136j1TCEfWn57DoTzwV6 9zb1r684Vhe+RWp+t+D5Oz1GijKyIEi3ZP7mnrGwH51SvobtUO4iN3376cy1zlLuXOws 6rrJh0tWtfM+5f+6R5TABTCPci5aJZhdG057+ZtaQvjyox4wrZGY1ACbCd5WvIX8Uw0a qh+A== X-Gm-Message-State: APjAAAUBpdOv6cGMJLtI6TxJHjd1A3AISsFOiPoTdwzSdLIBmdPV8KLC fGtuQ4loaCPrHg34AvNllXDpPS2mCWk= X-Google-Smtp-Source: APXvYqxRZUo/BgjJE6yZZaY9vK4iAInfrNTmmTke4Q7T/QBoABkK/ao1NgOuiXZUmy6f4vFO3MMy4Q== X-Received: by 2002:a6b:7109:: with SMTP id q9mr14024563iog.239.1567811862689; Fri, 06 Sep 2019 16:17:42 -0700 (PDT) Received: from [192.168.1.17] (71-211-190-133.hlrn.qwest.net. [71.211.190.133]) by smtp.googlemail.com with ESMTPSA id g4sm16476753iof.56.2019.09.06.16.17.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Sep 2019 16:17:42 -0700 (PDT) To: mud@ietf.org References: <156750742337.9752.15749363710921341398.idtracker@ietfa.amsl.com> From: John Schiel Message-ID: <4f295e57-6266-bd93-0b0f-488086ea3775@flowtools.net> Date: Fri, 6 Sep 2019 17:17:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8696BAB19FBF0DFB9AEE97F5" Content-Language: en-US Archived-At: Subject: Re: [Mud] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 23:17:46 -0000 This is a multi-part message in MIME format. --------------8696BAB19FBF0DFB9AEE97F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The coded link has one too many periods between ietf and org. Here's the correct one. https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01 --John On 9/3/19 7:15 AM, tirumal reddy wrote: > Hi all, > > This revision > https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01 > updates > the MUD (D)TLS profile to include grease extension, visibility into > TLS 1.3 parameters, pre-shared key exchange modes and Encrypted SNI. > > We observed several IoT devices are already using Grease extension. > > Comments and suggestions are more than welcome. > > Cheers, > -Tiru > > ---------- Forwarded message --------- > From: > > Date: Tue, 3 Sep 2019 at 16:13 > Subject: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt > To: Tirumaleswar Reddy >, > Dan Wing > > > > > A new version of I-D, draft-reddy-opsawg-mud-tls-01.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name:           draft-reddy-opsawg-mud-tls > Revision:       01 > Title:          MUD (D)TLS profiles for IoT devices > Document date:  2019-09-03 > Group:          Individual Submission > Pages:          17 > URL: > https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-01.txt > Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/ > Htmlized: https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls > Diff: https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-01 > > Abstract: >    This memo extends Manufacturer Usage Description (MUD) to model DTLS >    and TLS usage.  This allows a network element to notice abnormal DTLS >    or TLS usage which has been strong indicator of other software >    running on the endpoint, typically malware. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > --------------8696BAB19FBF0DFB9AEE97F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The coded link has one too many periods between ietf and org.  Here's the correct one.

https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01


--John

On 9/3/19 7:15 AM, tirumal reddy wrote:
Hi all,

This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01 updates the MUD (D)TLS profile to include grease extension, visibility into
TLS 1.3 parameters,  pre-shared key exchange modes and Encrypted SNI.

We observed several IoT devices are already using Grease extension.

Comments and suggestions are more than welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, 3 Sep 2019 at 16:13
Subject: New Version Notification for draft-reddy-opsawg-mud-tls-01.txt
To: Tirumaleswar Reddy <kondtir@gmail.com>, Dan Wing <danwing@gmail.com>



A new version of I-D, draft-reddy-opsawg-mud-tls-01.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-opsawg-mud-tls
Revision:       01
Title:          MUD (D)TLS profiles for IoT devices
Document date:  2019-09-03
Group:          Individual Submission
Pages:          17
URL:            https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-01.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:       https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-01

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to model DTLS
   and TLS usage.  This allows a network element to notice abnormal DTLS
   or TLS usage which has been strong indicator of other software
   running on the endpoint, typically malware.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--------------8696BAB19FBF0DFB9AEE97F5-- From nobody Sun Sep 8 02:19:05 2019 Return-Path: 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 25CF3120033 for ; Sun, 8 Sep 2019 02:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 QywXUWoA3lwz for ; Sun, 8 Sep 2019 02:19:01 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D0E12002E for ; Sun, 8 Sep 2019 02:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1194; q=dns/txt; s=iport; t=1567934341; x=1569143941; h=from:mime-version:subject:message-id:date:to; bh=tbR+IdIl2lVyZPY/JTS0mX/mp5cP9zzTV6SD6EkStQc=; b=IC2YW+GCpjhdiJuj97YoNyOrjOEmk03obo9q7KuyB4RXmn6J0yaYN6N0 +zukdKQfIKmdnd2MO3gOSlJI0xTOVkuYSSgNYuUDQh6qraWemc8enxULn lILHV5SlJylvd2K4xt4ZdJdq3ddaYMQ/ZYCxUizuN/BqJSUjTppgjaNc6 M=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAAAmx3Rd/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGDBCQvIBIqhCGIfKE8FIFnAgcBAQEJAwEBGxQ?= =?us-ascii?q?BAYcbNgcOAgMJAQEEAQEBAgEGBG2FLgyFdIEzAoQUAYIKlhyOf4EyijwQgTQ?= =?us-ascii?q?BgVCKP4F/gTgfhzZlgj4ygiYElVyWZIIrgiyBEYNCjXUbgiQBD2+GTYN6ixi?= =?us-ascii?q?EO58dgxECBAYFAhWBWQgpgVgzGggbFWUBgkEJNYJUiDaFQT4DMJE3AQE?= X-IronPort-AV: E=Sophos;i="5.64,481,1559520000"; d="asc'?scan'208";a="16458318" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Sep 2019 09:18:57 +0000 Received: from [10.61.209.152] ([10.61.209.152]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x889IuWO016108 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 8 Sep 2019 09:18:56 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_5B9657EC-352D-4205-BDBC-9456B6EE6783"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sun, 8 Sep 2019 11:18:54 +0200 To: mud@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.209.152, [10.61.209.152] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Mud] mudmaker.org maintenance X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2019 09:19:03 -0000 --Apple-Mail=_5B9657EC-352D-4205-BDBC-9456B6EE6783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Overnight, I was informed by Amazon that one of the mudmaker instances = may have become unstable. I=E2=80=99ve removed that instance from the = pool of hosts, and added a new one. Please let me know if you spot any = problems. --Apple-Mail=_5B9657EC-352D-4205-BDBC-9456B6EE6783 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl10x38ACgkQh7ZrRtnS ejNNtgf+IJhyC75mnEVUSOfxz5ulQbnczpLk+EjkemShmuSixxdbfqzECv9qWPEd OyBk/DSE2vlOBlUht9iV60sJOZJ33T5bedCeeveq7JmU63+CvOMhKNQEHwCymLMr tEyk7vR78aUD3AkiG3szMpcFSECl19Twyqzf62oEYDclPLEpTAOwsT09j/g1T1Bo gqkJzODFJ8RG6NG1tYWoQcEU8JqAm7FzocQiBtCRSoRiYTYaldZu5eHgA1Ln+1sI ZU1H56UHouajmN/EH+h3iIModYWtcNRHYCxy+3Fou3mUFt3lO9K5RicAPr0s+qfm smub8lLvA7Futlk7DccCi4rqKmQZRQ== =cwGd -----END PGP SIGNATURE----- --Apple-Mail=_5B9657EC-352D-4205-BDBC-9456B6EE6783-- From nobody Tue Sep 10 00:09:06 2019 Return-Path: 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 D534A120089 for ; Tue, 10 Sep 2019 00:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ntop.org 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 ErFzaKGQ_5Bv for ; Tue, 10 Sep 2019 00:09:02 -0700 (PDT) Received: from mail.ntop.org (mail-digitalocean.ntop.org [167.99.215.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F02812004E for ; Tue, 10 Sep 2019 00:08:59 -0700 (PDT) Received: from [192.168.1.100] (host212-206-dynamic.22-79-r.retail.telecomitalia.it [79.22.206.212]) by mail.ntop.org (Postfix) with ESMTPSA id 185E23FACD for ; Tue, 10 Sep 2019 09:08:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ntop.org; s=mail; t=1568099337; bh=YIKG3I0a+qlXQGT1PoLMbQNhShK6rKlBC0YrIjP2JRM=; h=From:Subject:Date:To:From; b=pQqiy5qk0hUsdzH3hMRBbiewLyoRaZvngyDiQhJgbXfHJH5SV32UzKjeL0y3kVDn5 HW8odBN/rBXjbWEFaZlIWIp7NXq9hZXvgoVPwcpIJgwvYDoQqrdf5E9xQld6iS3r3a +MnRInJAIm1QiC4dNvsAp062c4axMqLW4q07YLzs= From: Luca Deri Content-Type: multipart/alternative; boundary="Apple-Mail=_FBDEC435-4813-4DD9-87E1-5698D18E4D8A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 10 Sep 2019 09:08:55 +0200 To: Mud@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Mud] Using MUD to enforce network traffic policies X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 07:09:05 -0000 --Apple-Mail=_FBDEC435-4813-4DD9-87E1-5698D18E4D8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I am the developer of an open source network traffic monitoring = application named ntopng (https://github.com/ntop/ntopng). I have = started to use MUD to enhance ntopng to planned for MUD enhancements to = make it suitable not jus for IoT devices but also for generic devices as = tablets and laptops. In my view MUD is a great starting point to create = a =E2=80=9Cportable=E2=80=9D device network behaviour that could be used = in cybersecurity and traffic monitoring to spot unexpected traffic = flows. I have written a short blog post = https://www.ntop.org/ntopng/using-rfc8520-mud-to-enforce-hosts-traffic-pol= icies-in-ntopng/ = that explains this in detail and highlights the = ongoing developments. I would be glad to receive some feedback in particular related to MUD = extensions that are IMHO necessary to make it more general than the = original idea. Regards Luca= --Apple-Mail=_FBDEC435-4813-4DD9-87E1-5698D18E4D8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,
I am the developer of an open source network traffic = monitoring application named ntopng (https://github.com/ntop/ntopng). I have started to use = MUD to enhance ntopng to planned for MUD enhancements to make it = suitable not jus for IoT devices but also for generic devices as tablets = and laptops. In my view MUD is a great starting point to create a = =E2=80=9Cportable=E2=80=9D device network behaviour that could be used = in cybersecurity and traffic monitoring to spot unexpected traffic = flows. I have written a short blog post https://www.ntop.org/ntopng/using-rfc8520-mud-to-enforce-hosts-= traffic-policies-in-ntopng/ that explains this in detail and = highlights the ongoing developments.

I would be glad to receive some = feedback in particular related to MUD extensions that are IMHO necessary = to make it more general than the original idea.

Regards Luca
= --Apple-Mail=_FBDEC435-4813-4DD9-87E1-5698D18E4D8A-- From nobody Tue Sep 10 07:39:37 2019 Return-Path: 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 3D0F812013C for ; Tue, 10 Sep 2019 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Z86Z0izEE2Rm for ; Tue, 10 Sep 2019 07:39:34 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B2012008A for ; Tue, 10 Sep 2019 07:39:34 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id b136so38082293iof.3 for ; Tue, 10 Sep 2019 07:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yWqPfPqChZH+bLoln6Xut03K5VrmycRkDtPIwjCcElM=; b=bgbJmKFOT/JsP2x0jRBMRCiCT5VgYMdn9YSkq+Pi1idDYFusj2JqjIN3BF2BYrRD09 EJVziiVxFgrUUHO7z1UH/Pk/WSOdScIAO0Ap3d3/iL+Zfpw9B9FnfB2B/yDgvZfY2api YtY0/b3B8H5YdUpPrE6ZLT8p6mYLpoYvgZw7ntAFJzluqoNDutGXXQGGvy4ytWNPmLH6 wHBXWDDyYFcfcCCyiskMy5OKpBhJHOLgcZy0V2ujlGr6c5oPzEUZJH4UpJTNth0dHHwP sa7xchQMACF3vG9qIP5tntnmHz8+no978PzXbakpVKGrxSg7r0cCYhp7X1aa1s+wiP2P 4uiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yWqPfPqChZH+bLoln6Xut03K5VrmycRkDtPIwjCcElM=; b=aMjAGiROH3DkSwH5oSaaySJVNy/4PG1zTVXneFEsfaxclRgjeS54GDqXG48B967KGI oSUDzAeFc5PkdN9MXzetiisv5twwpXwCjUClsLRsEj8g6t2iZhUcFzSwOPgZTzgfTSrA 21N1tjuJ5pl6hh4T3Fwbk6HvKlx5ocS8AJEHttjjGC6Vr+9ZMX23SaLlNU6SblwphPTG Tuw5Lh7zB/rpSE7RpOtV1+zWaHrGT7MnFS2yvQHKCdD/ziMwcBTFIrUPD8kdP4mjMTwD 2aXSUblNWZ+F0p2JUPoiV4OS3dJGx4roELroWHNkidogRK0EGjoH6A9duJ5SpIdzW/D4 dkxQ== X-Gm-Message-State: APjAAAXQlmHmrH04vWysQPYR5tqdnwbUFK+b/xtjtEEM9mD9al0uSCww KDlA5Dt8UCGK496laHSbyfxruI3k/foIdALly3J8FQoo7ug= X-Google-Smtp-Source: APXvYqz0r9Z3MzT34wg16BXf2MOSf/IiEA2yYkNkETIaMZNp/dqQIH7dmD+kOKUm1g9fuVObLOAOwdkUCj2GXMSwnmA= X-Received: by 2002:a5d:81d9:: with SMTP id t25mr4165652iol.102.1568126373060; Tue, 10 Sep 2019 07:39:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "M. Ranganathan" Date: Tue, 10 Sep 2019 10:38:56 -0400 Message-ID: To: Luca Deri Cc: Mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000006de592059233df84" Archived-At: Subject: Re: [Mud] Using MUD to enforce network traffic policies X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 14:39:36 -0000 --0000000000006de592059233df84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, interesting development. On Tue, Sep 10, 2019 at 3:09 AM Luca Deri wrote: > Hi all, > I am the developer of an open source network traffic monitoring > application named ntopng (https://github.com/ntop/ntopng). I have started > to use MUD to enhance ntopng to planned for MUD enhancements to make it > suitable not jus for IoT devices but also for generic devices as tablets > and laptops. In my view MUD is a great starting point to create a > =E2=80=9Cportable=E2=80=9D device network behaviour that could be used in= cybersecurity and > traffic monitoring to spot unexpected traffic flows. I have written a sho= rt > blog post > https://www.ntop.org/ntopng/using-rfc8520-mud-to-enforce-hosts-traffic-po= licies-in-ntopng/ that > explains this in detail and highlights the ongoing developments. > > I would be glad to receive some feedback in particular related to MUD > extensions that are IMHO necessary to make it more general than the > original idea. > > The following mud-reporter MUD extension could be of interest in your event reporting mechanism. https://github.com/iot-onboarding/mud-reporter/tree/master It would be interesting to get some feedback from you on the applicability of this extension to your work. > Regards Luca > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > --=20 M. Ranganathan --0000000000006de592059233df84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

inte= resting development.

On Tue, Sep 10, 2019 at 3:09 AM Luca Deri <= ;deri@ntop.org> wrote:
Hi all,
I am the developer of an open source network traf= fic monitoring application named ntopng (https://github.com/ntop/ntopng). I have star= ted to use MUD to enhance ntopng to planned for MUD enhancements to make it= suitable not jus for IoT devices but also for generic devices as tablets a= nd laptops. In my view MUD is a great starting point to create a =E2=80=9Cp= ortable=E2=80=9D device network behaviour that could be used in cybersecuri= ty and traffic monitoring to spot unexpected traffic flows. I have written = a short blog post=C2=A0https:= //www.ntop.org/ntopng/using-rfc8520-mud-to-enforce-hosts-traffic-policies-i= n-ntopng/=C2=A0that explains this in detail and highlights the ongoing = developments.

I would be glad to receive some feed= back in particular related to MUD extensions that are IMHO necessary to mak= e it more general than the original idea.


The following mud-reporter MUD extension could be= of interest in your event reporting mechanism.

h= ttps://github.com/iot-onboarding/mud-reporter/tree/master
It would be interesting to get some feedback from you on the ap= plicability of this extension to your work.

= =C2=A0
Regards Luca



=C2=A0
--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud


--
M. Ranganathan

<= /div>
--0000000000006de592059233df84-- From nobody Wed Sep 11 06:49:35 2019 Return-Path: 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 58ECC1208BE for ; Wed, 11 Sep 2019 06:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ntop.org 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 zqhd9llzPjxX for ; Wed, 11 Sep 2019 06:49:31 -0700 (PDT) Received: from mail.ntop.org (mail-digitalocean.ntop.org [167.99.215.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0416E12011B for ; Wed, 11 Sep 2019 06:49:30 -0700 (PDT) Received: from [10.129.96.235] (unknown [37.160.165.195]) by mail.ntop.org (Postfix) with ESMTPSA id 00EAE401BC; Wed, 11 Sep 2019 15:49:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ntop.org; s=mail; t=1568209768; bh=CV7XVb7D0qa4EhBlRDocgRNXBdsr8jajjT2l85S5kFE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=KDPvFgvr2MiZx2SVulJxtgcIcHPAPqLtNOI6bs9sPaOiXAX+y9KzNl+b8zqI+Nw6/ utHH1NMfdYMp1Uqs0cTO42t3tQxL/eSRuxIZ4ZPfMxE+3/JqcrJXJLEPg0VHiEcTmW QPi+mreWyEnle6spCr8kWr7ttTpO5A60wMZVEuug= Content-Type: multipart/alternative; boundary=Apple-Mail-9E4C9290-8AF6-4FA0-8A0A-5F74A2DC3DA6 Mime-Version: 1.0 (1.0) From: Luca Deri X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Wed, 11 Sep 2019 15:49:24 +0200 Cc: Mud@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: To: "M. Ranganathan" Archived-At: Subject: Re: [Mud] Using MUD to enforce network traffic policies X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 13:49:34 -0000 --Apple-Mail-9E4C9290-8AF6-4FA0-8A0A-5F74A2DC3DA6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thanks for your feedback. I have looked at your work and I think it fits wit= h what I a trying to do. With some changes it can be used to report about tr= affic/match etc stats. My main concern are - as this format is pretty verbose, how can it cope with high or rich measur= ements (I am focusing on efficiency)? - there are several other formats to report data. Yours has a simple yet eff= ective structure, but on the other hand I am wondering (from the standardiza= tion standpoint) if this could be a problem to promote it to RFC as this mig= ht overlap in scope with other monitoring standards/formats.=20 Finally I have seen that your text has a few English typos. Can you fix them= or do you want me to send you a pull request? Regards Luca > On 10 Sep 2019, at 16:38, M. Ranganathan wrote: >=20 > Hello, >=20 > interesting development. >=20 >> On Tue, Sep 10, 2019 at 3:09 AM Luca Deri wrote: >> Hi all, >> I am the developer of an open source network traffic monitoring applicati= on named ntopng (https://github.com/ntop/ntopng). I have started to use MUD t= o enhance ntopng to planned for MUD enhancements to make it suitable not jus= for IoT devices but also for generic devices as tablets and laptops. In my v= iew MUD is a great starting point to create a =E2=80=9Cportable=E2=80=9D dev= ice network behaviour that could be used in cybersecurity and traffic monito= ring to spot unexpected traffic flows. I have written a short blog post http= s://www.ntop.org/ntopng/using-rfc8520-mud-to-enforce-hosts-traffic-policies-= in-ntopng/ that explains this in detail and highlights the ongoing developme= nts. >>=20 >> I would be glad to receive some feedback in particular related to MUD ext= ensions that are IMHO necessary to make it more general than the original id= ea. >>=20 >=20 > The following mud-reporter MUD extension could be of interest in your even= t reporting mechanism.=20 >=20 > https://github.com/iot-onboarding/mud-reporter/tree/master >=20 > It would be interesting to get some feedback from you on the applicability= of this extension to your work.=20 >=20 > =20 >> Regards Luca >=20 >=20 >=20 > =20 >> --=20 >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud >=20 >=20 > --=20 > M. Ranganathan=20 >=20 --Apple-Mail-9E4C9290-8AF6-4FA0-8A0A-5F74A2DC3DA6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi<= /div>
Thanks for your feedback. I have looked at your work a= nd I think it fits with what I a trying to do. With some changes it can be u= sed to report about traffic/match etc stats. My main concern are
- as this format is pretty verbose, how can it cope with high or r= ich measurements (I am focusing on efficiency)?
- ther= e are several other formats to report data. Yours has a simple yet effective= structure, but on the other hand I am wondering (from the standardization s= tandpoint) if this could be a problem to promote it to RFC as this might ove= rlap in scope with other monitoring standards/formats. 

Finally I have seen that your text has a fe= w English typos. Can you fix them or do you want me to send you a pull reque= st?

Regards Luca

On 10 Sep 2019, at 16:38, M. Ranganathan <mranga@gmail.com> wrote:

Hello= ,

interesting development.

On Tue, Sep 10, 2= 019 at 3:09 AM Luca Deri <deri@ntop.org<= /a>> wrote:
Hi all,
I am the developer of an o= pen source network traffic monitoring application named ntopng (https://github.com/ntop/nto= png). I have started to use MUD to enhance ntopng to planned for MUD enh= ancements to make it suitable not jus for IoT devices but also for generic d= evices as tablets and laptops. In my view MUD is a great starting point to c= reate a =E2=80=9Cportable=E2=80=9D device network behaviour that could be us= ed in cybersecurity and traffic monitoring to spot unexpected traffic flows.= I have written a short blog post https://www.ntop.org/ntopng/using-rfc8520-mud-to-enforce-hosts-traff= ic-policies-in-ntopng/ that explains this in detail and highlights t= he ongoing developments.

I would be glad to receive= some feedback in particular related to MUD extensions that are IMHO necessa= ry to make it more general than the original idea.


The following mud-reporter MUD extension c= ould be of interest in your event reporting mechanism.
It would be interesting to get some feedback from you on the= applicability of this extension to your work.

 
Regards Luca



 
--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud


--
=
M. Ranganathan

= --Apple-Mail-9E4C9290-8AF6-4FA0-8A0A-5F74A2DC3DA6-- From nobody Wed Sep 11 13:30:30 2019 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 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: Cc: Michael Richardson , "iot-onboarding@ietf.org" , "mud@ietf.org" To: Mohit Sethi M References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 20:30:22 -0000 --Apple-Mail=_3FB7F2BD-5215-4745-AD0F-445272E481C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mohit, > Could you explain the high-level differences between BRSKI and SZTP = for those like me who are not extremely familiar.=20 > 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.=20 >=20 > 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? >=20 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= --Apple-Mail=_3FB7F2BD-5215-4745-AD0F-445272E481C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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
= --Apple-Mail=_3FB7F2BD-5215-4745-AD0F-445272E481C1-- From nobody Thu Sep 12 05:39:24 2019 Return-Path: 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 EC3411200D8; Thu, 12 Sep 2019 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EprhG3ucBRRr; Thu, 12 Sep 2019 05:39:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3351200A3; Thu, 12 Sep 2019 05:39:13 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [104.244.9.242]) by relay.sandelman.ca (Postfix) with ESMTPS id 6A58A1F480; Thu, 12 Sep 2019 12:39:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id A7CB3491B; Thu, 12 Sep 2019 13:30:35 +0100 (WEST) From: Michael Richardson To: "mud\@ietf.org" , "iot-onboarding\@ietf.org" In-reply-to: <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> References: <19176.1567583108@dooku.sandelman.ca> <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> Comments: In-reply-to Mohit Sethi M message dated "Wed, 11 Sep 2019 19:21:30 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 12 Sep 2019 13:30:35 +0100 Message-ID: <29106.1568291435@dooku.sandelman.ca> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 12:39:15 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mohit Sethi M wrote: > adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possib= ly > 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 ... > You clearly see a AAA server in the figures. So calling it AAA-less > doesn't make sense. Thus, why it says, a *version*, but maybe it should have said "variation" of EAP-NOOB. I would ask for your help on getting this text correct, but it seems that you'd rather IoT work was fragmented among many groups?=20 My impression is that this makes it very difficult to involve people from other organizations, and it also results in very uneven reviews. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl16OmsACgkQlUzhVv38 QpALSwf9HWqCvimLxmgO+CInMWN1D39pPk2+SE1UoxBgNzh/tntTWTxM0hWW2vOR WHn0gldj/XLwJXzKf+70dt66+iCEb1NJ0b2SOnR6rgGASh7gzokj4+tqdTsdzWRz vSxRuIs0zso4tuXJI7sKLfi55Q8Gt2vWKBMlcXSH4RZWnlvAfkNYGzK/ItlMRDK+ 8pMMghXPi98i8GcnhtV/Z96Xi8v/85Z3hBAIUaFnOk8Dab8x4NjoIJ3pPN8SZmNd mvKHAg+HmPvYTIbLE44zkIRxEx1KYMuDccO0MJdlM/Op6JXhYNcVw3wl1d3l5rYN fq5eXKIWa7ucKp/zHvarwfnPOyyshQ== =KICw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 12 05:39:31 2019 Return-Path: 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 DB7CF1200D8; Thu, 12 Sep 2019 05:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1AmOQ-yB331z; Thu, 12 Sep 2019 05:39:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E554120052; Thu, 12 Sep 2019 05:39:12 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [104.244.9.242]) by relay.sandelman.ca (Postfix) with ESMTPS id 71B1E1F481; Thu, 12 Sep 2019 12:39:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6033F49EA; Thu, 12 Sep 2019 13:34:29 +0100 (WEST) From: Michael Richardson To: "iot-onboarding\@ietf.org" , "mud\@ietf.org" In-reply-to: <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.com> References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.com> Comments: In-reply-to Kent Watsen message dated "Wed, 11 Sep 2019 20:30:18 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 12 Sep 2019 13:34:29 +0100 Message-ID: <29185.1568291669@dooku.sandelman.ca> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 12:39:16 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > I think I got the BRSKI parts right, but hope folks will chime in if > anything is misrepresented or underrepresented. =20=20=20=20 I think you are exactly on. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl16O1UACgkQlUzhVv38 QpDInwgAkXZVkQj7n3TKq21kqPd/2VoIRBMWk6tTlDytWkDzdshBofpOvrNSe+ID Xj7s1w4uF7TAO6ql7LRAjTR3FoJt3sZRARClTdzzNsq/Kdnl00OXPLz+l1Mak2zR M9wQuXpSsiIKs0SMzXV6NVanOo6lltBChxYSTxlhzEoEyAg0lurI8ds5zB2+MBsu TEotuN8DI3AiSdPJj+lgMFPjeq2WaCwLXP8pruNpBUYFb0rBKIi2lALywWRXbaht 7Mnhad773EJVwLiuibbg/W4C7y7iwfdZduon2l7F1adGC/UlClpxLVEbv+ox2epn ESRXHeEk7sOZ+zqn8swQloOCw7jZEQ== =58gU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 12 05:39:51 2019 Return-Path: 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 9062E1201EF; Thu, 12 Sep 2019 05:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dofUAwgcKIuB; Thu, 12 Sep 2019 05:39:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE2B120041; Thu, 12 Sep 2019 05:39:12 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [104.244.9.242]) by relay.sandelman.ca (Postfix) with ESMTPS id 5C4D01F459; Thu, 12 Sep 2019 12:39:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B5E3449E7; Thu, 12 Sep 2019 13:33:20 +0100 (WEST) From: Michael Richardson To: "iot-onboarding\@ietf.org" , "mud\@ietf.org" In-reply-to: References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> Comments: In-reply-to Mohit Sethi M message dated "Wed, 11 Sep 2019 19:26:52 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 12 Sep 2019 13:33:20 +0100 Message-ID: <29152.1568291600@dooku.sandelman.ca> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 12:39:21 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mohit Sethi M wrote: > I know there are probably many differences. For example, I see that t= he > SZTP spec says that devices can receive initial bootstrap information > over DNS or from a bootstrap server. SZTP does not have voucher-requests. Or at least, does not do them inband in a specific way detailed by a standa= rd. Both use RFC8366 vouchers to convey ownership. > 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? They serve different parts of the ecosystem. SZTP does not mandate an IDevID, but many ways of using it would seem to benefit from having one. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl16OxAACgkQlUzhVv38 QpCcQgf+J5hnjpI6LP4oNgDVvRgHs+6QzRNWGs4Iu16CPAbxQJm26VDQ/nl/wKNW wFxofyEXUmjSXPOhayENOA2I/r0qX3s+GaukuPoLlgva8AibQiTJPstnkecrlqrn piy/pJnFcqWXlEJPZSMlU/WgM0oiKStUWIFK8HefxrekYhZISAVLD+X1nf88q2oH 2f5YV2kg3nY71rQQ9FKfktPQgqHyKs0ur7HDpQg8Xmd8K95wBq1BTE/KSYlyuXfU iAXFoingVxRk1WmQsCmf1+31l2WyjyS/grqISaqDPYSslrEVumqQR1G214yuxk4p C3szW2ldbGY1x5v8zAEUFRnhnVWCHg== =8BP+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 12 08:08:27 2019 Return-Path: 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 582BA120865; Wed, 11 Sep 2019 12:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 X4iRpMN4AiJh; Wed, 11 Sep 2019 12:21:34 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (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 AF1D312006E; Wed, 11 Sep 2019 12:21:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fae3eeCQ6N5Kr6rjHeBYUxVIHIvwr4IJfHBKT5ky9/bzxI9ISG/SqjxTXB529oQMXJELVeb4VsxAxelM8DvIhdgIsi45iisE02p0+fVuv1NQrxLyCXCa6erq8Q7F7+9bSliudMGVD0pFwbymWlhZvmw/YfdmTquJL67JqDGBjaJQtBdpxpSyeQjYjZ/nfNcKuQCmhPOoFMNuIscRyYp5Y4lruN0Wfe9/DmgC+7z2ZIs5gGSiPUI1saq1o71gA1uIt7x64SwHHvdTGyttiTPEKYwyVfBfqrF+u6Fo9Ps3mihBFz8wxa0pRuywwPHoW3WnhG6IIx9WLFs1Mzgytm+XHw== 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=fUgsXObVg6ufyGbcRLbNeiUAbx6pM9Zxq27J2FXqc2E=; b=eL+nS1Cq3g2vY4jfxwEv5836t/WKz/qt2A79UcObVPVjv9wfF9pjxk94XWBKd5ZHgryMvUYrE5O/4Auh/QjmirwSZCAVZZymlk/KP06mu85HPxoIjcXvdKKXYFW7TbaAWktpTDiwQ5wWxMGJiffn8h8XbyKHSaIhvNw1xc32vVRGBeuB6u3YfeemGQKtIFL1NmxULk5oZ9o3UFLh/hVtUjywbzR68x7+iS7WKOuVZcS4UylzRUjYlfcSN5lu+vyVSM/aD1XHyk2kYJ4jScWMnfE6Va9QqcFVXGsAfWymSt5fZrnKuof3bvm3IZsE0jNG8xtJPsW6Fyl5oO+tTv0FCw== 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=fUgsXObVg6ufyGbcRLbNeiUAbx6pM9Zxq27J2FXqc2E=; b=E1fbyYTEceYHxG0rpkN1C3jU0bz0b8SEzElqub5zk4d/YNPp97i8gboEWDekMOp1eoIDbz+Th/AFLUR6Vt2CAamIwcxs3WpFTujKXy4r+JN1VI87ofyywm9tTWpRgDSN/QJMnAlQ2nJG8vnJwYQMUnzDq+mdijC2wVYWBfexMrQ= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2604.eurprd07.prod.outlook.com (10.168.187.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.7; Wed, 11 Sep 2019 19:21:30 +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.2263.015; Wed, 11 Sep 2019 19:21:30 +0000 From: Mohit Sethi M To: Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG Thread-Index: AQHVaNYdpd2ivcpAw0yCVRFO+FMgJw== Date: Wed, 11 Sep 2019 19:21:30 +0000 Message-ID: <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> References: <19176.1567583108@dooku.sandelman.ca> In-Reply-To: <19176.1567583108@dooku.sandelman.ca> 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: [87.93.24.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1b0e5370-4c11-4cd7-8c46-08d736ed402c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2604; x-ms-traffictypediagnostic: HE1PR0701MB2604: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2512; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(199004)(189003)(64756008)(66476007)(66446008)(66556008)(7736002)(26005)(606006)(478600001)(76116006)(14444005)(186003)(66574012)(66946007)(2906002)(256004)(3846002)(81156014)(81166006)(99286004)(8676002)(36756003)(6116002)(6246003)(65806001)(53936002)(66066001)(65956001)(446003)(6506007)(14454004)(316002)(86362001)(53546011)(8936002)(31696002)(6512007)(31686004)(229853002)(15650500001)(5660300002)(76176011)(102836004)(2501003)(25786009)(486006)(966005)(236005)(11346002)(6436002)(110136005)(476003)(6486002)(54896002)(6306002)(71190400001)(71200400001)(58126008)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2604; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 1BJzYxdd9eymzYf6tOH8RRMRUo3rEunr51jHwPgwT68P0pExZ1slRq57h73ppyDL5rWLDqNe9A+wGuYUcnsBIpOf+leNgW9INRMhtqt9dRhUeR5BJ8RZuU63eJznssY6/aRpVE6L/vtXys5m+C8wlSqgAc54YLZ/l9+6Bbd43tp5QQTzVZehqu3YHvNLYFHAavkIxuBuJFEbMMgKiQLh9JjAf62rCGsHCSJLudjKZVzciEUgMfxZDSpZdTHRJchaldVbBrrv8DSlat3smfWHVeD+afn6U67K2DIQxfIPYyvRQRtBJ5v4/CBjXSj6oMg3BoHnx6Xj5EHWC3BMOtXkQRqpEx/hvyr0UwrxLkpAB5ctzK4x1o1ihDgyQmL+kMs3aLb5wHyhyzSfxMFi1evcpC3YTmSnovfaauxwMxuYZeQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_30e9de9068b07b45a94e165bb6fabbb5ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b0e5370-4c11-4cd7-8c46-08d736ed402c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2019 19:21:30.7215 (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: TuFm7w+/2YDdBEXuW1YJF6j6urZvzIMfrdaWYMzbXV9DjZ88o8PouwkbnVx5X2Gu7db6T91nQkILd89jOXzkEwis2wMqsmgVLdEWftc496s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2604 Archived-At: X-Mailman-Approved-At: Thu, 12 Sep 2019 08:08:25 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 19:21:37 -0000 --_000_30e9de9068b07b45a94e165bb6fabbb5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KSSB3b25kZXIgd2h5IGEgbmV3IHdvcmtpbmcgZ3JvdXAgaXMgbmVlZGVk IGFuZCB3aHkgdGhpcyB3b3JrIGNhbm5vdCBiZSBwdXJzdWVkIGluIHNvbWUgb2YgdGhlIGV4aXN0 aW5nIHdvcmtpbmcgZ3JvdXBzPw0KDQpJIHN1cHBvc2UgQU5JTUEgd2FzIHJlY2VudGx5IHJlLWNo YXJ0ZXJlZCAoYW5kIGNhbiBiZSByZS1jaGFydGVyZWQgYWdhaW4pLiBFTVUgaXMgY3VycmVudGx5 IGdvaW5nIG92ZXIgdGhlIHJlLWNoYXJ0ZXIgdGV4dC4NCg0KQWxzbywgeW91IHdyaXRlOg0KDQph ZG9wdCBhIGNsb3VkLWxlc3MgKE1BU0EtbGVzcywgQUFBLWxlc3MpIG9uYm9hcmRpbmcgbWVjaGFu aXNtIChwb3NzaWJseSBhIHZlcnNpb24gb2YgRUFQLU5PT0IpLA0KDQpUaGVyZSBpcyBjbGVhcmx5 IHNvbWUgbWlzdW5kZXJzdGFuZGluZyBhYm91dCBFQVAtTk9PQiBoZXJlLiBFQVAtTk9PQiBpcyBz cGVjaWZpY2FsbHkgaW50ZW5kZWQgZm9yIHJlZ2lzdGVyaW5nIG5ldyBJb1QgZGV2aWNlcyBvbiBh IHNlcnZlciAoYW5kIGFzc29jaWF0aW5nIGl0IHdpdGggYSB1c2VyIGFjY291bnQpLiBUaGUgZmFj dCB0aGF0IGl0IHByb3ZpZGVzIG5ldHdvcmstYWNjZXNzIGNyZWRlbnRpYWxzIGlzIGEgYm9udXMu IFBsZWFzZSBoYXZlIGEgbG9vayBhdCBzbGlkZXMgMy0xMCBoZXJlOiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLXNlY2Rpc3BhdGNo LW5pbWJsZS1vdXQtb2YtYmFuZC1hdXRoZW50aWNhdGlvbi1mb3ItZWFwLWVhcC1ub29iLWRyYWZ0 LWF1cmEtZWFwLW5vb2ItMDQtMDENCg0KWW91IGNsZWFybHkgc2VlIGEgQUFBIHNlcnZlciBpbiB0 aGUgZmlndXJlcy4gU28gY2FsbGluZyBpdCBBQUEtbGVzcyBkb2Vzbid0IG1ha2Ugc2Vuc2UuDQoN Ci0tTW9oaXQNCg0KT24gOS80LzE5IDEwOjQ1IEFNLCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6 DQoNCg0KSSB3cm90ZSB0aGlzIGxhc3Qgd2VlaywgYW5kIHBhc3NlZCBpdCBhcm91bmQgZm9yIG9i dmlvdXMgb2JqZWN0aW9ucy4NCiAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tY3IvaW90d2ctY2hhcnRl ci9ibG9iL21hc3Rlci9pb3R3Zy1jaGFydGVyLm1kDQpZb3UgY2FuIHVzZSB0aGUgY3JheW9uL2Vk aXQgYnV0dG9uIG9uIGdpdGh1YiB0byBzdWdnZXN0IGNoYW5nZXMsIG9yIGVtYWlsLg0KDQoNCkNo YXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXANCg0KVGhlIHdvcmRzICJJbnRlcm5ldCBvZiBUaGluZ3Mi IG9yIElvVCBoYXZlIGNvbWUgdG8gbWVhbiBhbnl0aGluZyBhbmQNCmV2ZXJ5dGhpbmcgdG8gYSB3 aWRlIGdyb3VwIG9mIHRlY2hub2xvZ3kgcGxheWVycy4gVGhlIElFVEYgaGFzIGJlZW4gd29ya2lu Zw0Kb24gYSB3aWRlIHZhcmlldHkgb2YgcHJvdG9jb2xzIGZvciB1c2UgYnkgbWFjaGluZSB0byBt YWNoaW5lDQpjb21tdW5pY2F0aW9uLiBUaGlzIGluY2x1ZGUgQ29BUCwgQ0JPUiwgNlRJU0NILCBS T0xMLCBTVUlULCBORVRDT05GIFNaVFAsDQpUMlRSRywgQU5JTUEncyBCUlNLSSBvbmJvYXJkaW5n IHByb3RvY29sLCBhbmQgbW9zdCByZWNlbnRseSBSRkM4NTIwLCB0aGUNCk1hbnVmYWN0dXJlciBV c2FnZSBEZXNjcmlwdGlvbi4NCg0KVGhlIElFVEYgaGFzIHRyaWVkIHRvIGZvY3VzIG9uIGNhdGVn b3JpZXMgb2Ygd2hhdCBsaW1pdGVkIHRoaW5ncyBjYW4gZG8sIGFuZA0KdGhpcyBoYXMgcmVzdWx0 ZWQgaW4gYSBudW1iZXIgb2YgdXNlZnVsIGRvY3VtZW50cyBmcm9tIHRoZSBMaWdodC1XZWlnaHQN CkltcGxlbWVudGF0aW9uIEd1aWRlIChMV0lHKS4gUkZDNzIyOCBpcyBhIGtleSBwcm9kdWN0LCBo YXZpbmcgcHJvdmlkZWQNCnRlcm1pbm9sb2d5IGFuZCBzY2FsaW5nIHVuZGVyc3RhbmRpbmcgdG8g dGhlIGVudGlyZSBpbmR1c3RyeS4gQWxsIG9mIHRoaXMgaGFzDQpiZWVuIGFib3V0IHNjYWxpbmcg dGhlIEludGVybmV0IHRlY2hub2xvZ2llcyB0byBzbWFsbCBkZXZpY2VzIGFuZCBjb25zdHJhaW5l ZA0KbmV0d29ya3MuIEluIGFnZ3JlZ2F0ZSwgdGhlc2UgZGV2aWNlcyBvbiBzbWFsbCBuZXR3b3Jr cyBwcmVzZW50IGEgc2lnbmlmaWNhbnQNCm9wZXJhdGlvbmFsIHJpc2sgdG8gdGhlIEludGVybmV0 IGFzIGEgd2hvbGUsIGFuZCBldmVuIHRvIGluZGl2aWR1YWwNCkVudGVycHJpc2UsIHNpbXBseSBk dWUgdG8gdGhlaXIgbnVtYmVycywgYW5kIGxhY2sgb2Ygb3Bwb3J0dW5pdHkgZm9yIHJlZ3VsYXIN Cmh1bWFuIHN1cGVydmlzaW9uLg0KDQpJb1QgZGV2aWNlcyBhbHJlYWR5IGV4aXN0IHRvZGF5IGlu IHZhc3QgbnVtYmVycy4gTW9zdCBkZXZpY2VzIHRoYXQgcGVvcGxlIGFyZQ0KcGVyc29uYWxseSBm YW1pbGlhciB3aXRoIGFyZSBpbiB0aGUgQmx1ZVRvb3RoIENvbm5lY3RlZCBkZXZpY2VzLCBvcg0K V2ViLUNvbm5lY3RlZCBkZXZpY2VzIHRoYXQgdXNlIFdpRmkgdG8gcmVhY2ggc2VydmVycyBvbiB0 aGUgSW50ZXJuZXQgKCJ0aGUNCkNsb3VkIikuIEluY3JlYXNpbmdseSwgdGhlIElFVEYgdmlldyBv ZiBtYWNoaW5lIHRvIG1hY2hpbmUgY29tbXVuaWNhdGlvbnMgYXJlDQpjb2xpbml6aW5nIG5ldyBn cmVlbmZpZWxkIHNpdHVhdGlvbnMuIFRoZSBJRVRGIG5vdGlvbiBvZiBhdXRvbm9tb3VzIG5ldHdv cmtzDQpvZiBkZXZpY2VzIGlzIHN0aWxsIGEgbWlub3JpdHkgdmlldyBjb21wYXJlZCB0byB0aGUg bWFya2V0IElvVCBpbmR1c3RyeSBvZg0KY2xvdWQtb25seSBjb25uZWN0ZWQgZGV2aWNlcywgYnV0 IHRoZSB0cmFuc2l0aW9uIGlzIG9jY3VyaW5nLg0KDQpSRkM4NTIwIHdhcyBjcmVhdGVkIHRvIGJy aWRnZSB0aGUgZ2FwIGJldHdlZW4gZGV2aWNlcyB3aG9sbHkgY29udHJvbGxlZCBieSBhDQpsb2Nh bCBvcGVyYXRvciAoc3VjaCBhcyBFbnRlcnByaXNlIElUKSwgYW5kIGRldmljZXMgd2hpY2ggY2Fu IG5vdCBhc3N1bWUgYW55DQppbmZyYXN0cnVjdHVyZSBhdCBhbGwsIGFuZCBtdXN0IHJlbHkgZW50 aXJlbHkgb24gY2xvdWQgY29tbXVuaWNhdGlvbnMgZm9yDQpjb21tYW5kIGFuZCBjb250cm9sLg0K DQpUaGlzIHdvcmtpbmcgZ3JvdXAgY29uY2VybnMgaXRzZWxmIHdpdGggT3BlcmF0aW9uYWwgU2Vj dXJpdHkgb2YgSW9UIHN5c3RlbXMuDQoNClRoaXMgaW5jbHVkZXM6DQoNCiogZmFjdG9yeSBwcm92 aXNpb25pbmcgb2YgZGV2aWNlcw0KKiBvbmJvYXJkaW5nIG9mIGRldmljZXMNCiogYWNjZXNzIGNv bnRyb2wgb2YgZGV2aWNlcyB0byBuZXR3b3JrIHJlc291cmNlcw0KKiBhZG1pbmlzdHJhdGl2ZSBj b250cm9sIG9mIGRldmljZXMNCiogYXNzZXQgbWFuYWdlbWVudCBvZiBkZXZpY2VzLCBhcyBpdCBw ZXJ0YWlucyB0byBzb2Z0d2FyZS9maXJtd2FyZSB2ZXJzaW9ucw0KKiBpc29sYXRpb24vcXVhcmFu dGluZSBvZiBkZXZpY2VzDQoqIHJlbWVkaWF0aW9uIG9mIGJyb2tlbiBkZXZpY2VzDQoqIGVuZCBv ZiBsaWZlIG1hbmFnZW1lbnQgb2YgZGV2aWNlcw0KDQpUaGUgV0cgaXMgY2hhcnRlcmVkIGV4cGxp Y2l0ZWx5IHRvIHdvcmsgb24gTVVEIChSRkM4NTIwKSBhbmQgZXh0ZW5zaW9ucyB0byBpdC4NCg0K VGhlIFdHIGlzIGNoYXJ0ZXJlZCB0byB3b3JrIG9uIG9uYm9hcmRpbmcgcHJvdG9jb2xzLCBzcGVj aWZpY2FsbHkgaW5jbHVkaW5nDQpkZXJpdmF0aWVzIG9mIEJSU0tJIChSRkMtdGJkKSwgYnV0IG5v dCBsaW1pdGVkIHRvIGp1c3QgdGhhdCBwcm90b2NvbC4NCg0KVGhlIFdHIGlzIG5vdCBleHBlY3Rl ZCB0byBwaWNrIGEgd2lubmVyLCBhbmQgaXMgZW5jb3VyYWdlZCB0byB3b3JrIG9uIGENCm11bHRp dHVkZSBvZiB1c2UtY2FzZSBzcGVjaWZpYyBwcm90b2NvbHM6IGJldHRlciB0byBnZXQgb25lIHVz ZSBjYXNlIHJpZ2h0LA0KdGhhbiB0byBiZSB0b28tY29tcGxleCBqYWNrIG9mIGFsbCB0cmFkZXMu DQoNClRoZSBXRyBpcyBleHBlY3RlZCB0byBhcnRpY3VsYXRlIGNsZWFyIGFwcGxpY2FiaWxpdHkg c3RhdGVtZW50cyBmb3IgZWFjaA0KcHJvdG9jb2wuIFRoZSBXRyBpcyBleHBlY3RlZCB0byBwcm9k dWNlIGNvbmNpc2UgUm9hZG1hcCBkb2N1bWVudHMgdGhhdA0KZXhwbGFpbiBob3cgYSB2YXJpZXR5 IG9mIElFVEYgKGFuZCBvdGhlcikgcHJvdG9jb2xzIGNhbiB3b3JrIHRvZ2V0aGVyIHRvDQpzYXRp c2Z5IHRoZSBPcGVyYXRpb25hbCBuZWVkcyBvZiBzcGVjaWZpYyBJb1QgYXJlYXMuIFRoZXNlIHJv YWRtYXAgZG9jdW1lbnRzDQpuZWVkbuKAmXQgcmVzdWx0IGluIFJGQ3MuDQoNCk5laXRoZXIgdGhl IFdHIG5vciB0aGUgSUVURiBoYXMgZXhjbHVzaXZpdHkgaGVyZSwgYW5kIGFuIGlkZWFsIGRvY3Vt ZW50IHdvdWxkDQpiZSBvbmUgdGhhdCB0aGUgV0cgaGVscHMgdG8gc3RhcnQsIGJ1dCBhIHNwZWNp ZmljIGluZHVzdHJ5IGFsbGlhbmNlIGJlY29tZXMNCnRoZSBsZWFkIGVkaXRvciBmb3IuDQoNClRo ZXJlIHdpbGwgYmUgY29vcmRpbmF0aW9uIHdpdGggbWFueSBvdGhlciBXR3MgYmV5b25kIHRoZSBs aXN0IGFib3ZlLCBhbmQNCnRoaXMgV0cgbWF5IGFjY2VwdCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dCB3b3JrIGZyb20gb3RoZXIgV0dzIGFib3V0IHNwZWNpZmljDQp3YXlzIHRvIGRlcGxveSB0aGVp ciBwcm90b2NvbHMuDQoNClRoZSBXRyB3aWxsIG9wZXJhdGUgdGhyb3VnaCBhIHNlcmllcyBvZiB2 aXJ0dWFsIGludGVyaW0gbWVldGluZ3MuIFRoaXMgaXMNCmRyaXZlbiBieSBhIG5lZWQgdG8gaW50 ZXJhY3QgcmVndWxhcmx5IHdpdGggb3RoZXIgaW5kdXN0cnkgZ3JvdW9wcywgYW5kIGR1ZQ0KdG8g dGhlIHZhcmlldHkgb2YgdG9waWNzIHdoaWNoIHdpbGwgbm90IGFsd2F5cyBiZSBhYmxlIHRvIGdl dCBxdW9ydW0gYXMgYQ0KY29tbWl0dGVlIG9mIHRoZSB3aG9sZS4NCg0Ke3VudXN1YWwsIG1heWJl IG5vdCBjaGFydGVyIGFwcHJvcHJpYXRlLCBidXQgcmF0aGVyIHNhYWctbGlrZX0NCkR1cmluZyBp bi1wZXJzb24gbWVldGluZ3MsIHRoZSBXRyB3aWxsIGRlYWwgd2l0aCB0eXBpY2FsIHN0YXR1cyBh bmQgZG9jdW1lbnQNCnByb2dyZXNzIGlzc3VlcyBkdXJpbmcgb25lIGhvdXIgKG9yIGxlc3MpIG9m IHRoZSB0aW1lLCBhbmQgZHVyaW5nIGFub3RoZXINCmhvdXIsIHdpbGwgYmUgb3BlbiB0byBzbGlk ZXdhcmUgcHJlc2VudGF0aW9ucyBhbmQgdHV0b3JpYWxzIG9uIGN1cnJlbnQgSUVURg0Kb3Igb3Ro ZXItU0RPIElvVCBlZmZvcnRzLiBUaGUgZ29hbCBvZiB0aGVzZSBwcmVzZW50YXRpb25zIGlzIHRv IHF1aWNrbHkNCmNvbW11bmljYXRlIGN1cnJlbnQgSW9UIHN5c3RlbXMgc3RhdGUgdG8gdGhlIHJl c3Qgb2YgdGhlIElFVEYuDQoNCkl0IGlzIGFja25vd2xlZGdlZCB0aGF0IHBhcnQgb2YgdGhlIHZh bHVlIGlzIGluIFlvdVR1YmUgY29udGVudCwgYW5kIHNvbWUNCmNvbnRlbnQgc2hvdWxkIGJlIGRv bmUgYXQgSUFCIHRlY2ggcGxlbmFyaWVzIHJhdGhlciB0aGFuIGF0IHRoZSBXRy4NCg0KVGhlIGlu aXRpYWwgc2V0IG9mIHdvcmsgaXRlbXMgaXMgaW5jbHVkZWQgYmVsb3cgYXMgbWlsZXN0b25lcywg d2hpY2ggb25seQ0KcmVxdWlyZSBBRCBhcHByb3ZhbC4NCg0KTWlsZXN0b25lcw0KDQoqIGFkb3B0 IHRoZSBjb25zdHJhaW5lZC12b3VjaGVyL2NvbnN0cmFpbmVkLUJSU0tJIHdvcmsgZnJvbSBBTklN QS4NCiogYWRvcHQgdGhlIGR0c2VjdXJpdHktemVyby10b3VjaCB3b3JrIGZyb20gNnRpc2NoLCB3 aGljaCBjYW4gbm90IGZpbmlzaCBiZWZvcmUgYSBMQUtFIGZpbmlzaGVzLg0KKiBjcmVhdGUgYSBs aXN0IG9mIGEgc2VyaWVzIG9mIE1VRCBleHRlbnNpb25zLCBhbmQgcmV2aXNlIHRoaXMgbWlsZXN0 b25lDQoqIGFkb3B0IGEgY2xvdWQtbGVzcyAoTUFTQS1sZXNzLCBBQUEtbGVzcykgb25ib2FyZGlu ZyBtZWNoYW5pc20gKHBvc3NpYmx5IGEgdmVyc2lvbiBvZiBFQVAtTk9PQiksIHRoYXQgY2FuIGJl IHVzZWQgYXQgdGhlIHJldGFpbCBsZXZlbC4NCiogbmVnb3RpYXRlIHdpdGggRU1VIFdHIG9uIGhv dyB0byBwcm9jZWVkIHdpdGggVEVBUC1CUlNLSSwgYW5kIHJldmlzZSB0aGlzIG1pbGVzdG9uZS4N CiogYWRvcHQgYSBjbG91ZC1kcml2ZW4gb25ib2FyZGluZyBtZWNoYW5pc20gdGhhdCBjYW4gYmUg dXNlZCBpbiBjb21wbGV0ZWx5IG9mZmxpbmUgc2l0dWF0aW9ucyB3aXRob3V0IHJlcXVpcmluZyBy ZW5ld2FscyAocGVyaGFwcyByZXZpc2luZyBSRkM4MzY2KS4NCi4uLi4NCg0KDQoNCg0KDQoNCg0K --_000_30e9de9068b07b45a94e165bb6fabbb5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4891255FA3413F42BA08855370D214D8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgTWljaGFlbCw8L3A+DQo8cD5JIHdvbmRlciB3aHkg YSBuZXcgd29ya2luZyBncm91cCBpcyBuZWVkZWQgYW5kIHdoeSB0aGlzIHdvcmsgY2Fubm90IGJl IHB1cnN1ZWQgaW4gc29tZSBvZiB0aGUgZXhpc3Rpbmcgd29ya2luZyBncm91cHM/DQo8YnI+DQo8 L3A+DQo8cD5JIHN1cHBvc2UgQU5JTUEgd2FzIHJlY2VudGx5IHJlLWNoYXJ0ZXJlZCAoYW5kIGNh biBiZSByZS1jaGFydGVyZWQgYWdhaW4pLiBFTVUgaXMgY3VycmVudGx5IGdvaW5nIG92ZXIgdGhl IHJlLWNoYXJ0ZXIgdGV4dC4mbmJzcDs8L3A+DQo8cD5BbHNvLCB5b3Ugd3JpdGU6IDxicj4NCjwv cD4NCjxwPjwvcD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96LXF1 b3RlLXByZSIgd3JhcD0iIj5hZG9wdCBhIGNsb3VkLWxlc3MgKE1BU0EtbGVzcywgQUFBLWxlc3Mp IG9uYm9hcmRpbmcgbWVjaGFuaXNtIChwb3NzaWJseSBhIHZlcnNpb24gb2YgRUFQLU5PT0IpLDwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KVGhlcmUgaXMgY2xlYXJseSBzb21lIG1pc3VuZGVyc3RhbmRp bmcgYWJvdXQgRUFQLU5PT0IgaGVyZS4gRUFQLU5PT0IgaXMgc3BlY2lmaWNhbGx5IGludGVuZGVk IGZvciByZWdpc3RlcmluZyBuZXcgSW9UIGRldmljZXMgb24gYSBzZXJ2ZXIgKGFuZCBhc3NvY2lh dGluZyBpdCB3aXRoIGEgdXNlciBhY2NvdW50KS4gVGhlIGZhY3QgdGhhdCBpdCBwcm92aWRlcyBu ZXR3b3JrLWFjY2VzcyBjcmVkZW50aWFscyBpcyBhIGJvbnVzLiBQbGVhc2UgaGF2ZQ0KIGEgbG9v ayBhdCBzbGlkZXMgMy0xMCBoZXJlOiA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0x MDMtc2VjZGlzcGF0Y2gtbmltYmxlLW91dC1vZi1iYW5kLWF1dGhlbnRpY2F0aW9uLWZvci1lYXAt ZWFwLW5vb2ItZHJhZnQtYXVyYS1lYXAtbm9vYi0wNC0wMSI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLXNlY2Rpc3BhdGNoLW5p bWJsZS1vdXQtb2YtYmFuZC1hdXRoZW50aWNhdGlvbi1mb3ItZWFwLWVhcC1ub29iLWRyYWZ0LWF1 cmEtZWFwLW5vb2ItMDQtMDE8L2E+PGJyPg0KPHA+PC9wPg0KPHA+WW91IGNsZWFybHkgc2VlIGEg QUFBIHNlcnZlciBpbiB0aGUgZmlndXJlcy4gU28gY2FsbGluZyBpdCBBQUEtbGVzcyBkb2Vzbid0 IG1ha2Ugc2Vuc2UuDQo8YnI+DQo8L3A+DQo8cD4tLU1vaGl0PGJyPg0KPC9wPg0KPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5PbiA5LzQvMTkgMTA6NDUgQU0sIE1pY2hhZWwgUmljaGFyZHNv biB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDox OTE3Ni4xNTY3NTgzMTA4QGRvb2t1LnNhbmRlbG1hbi5jYSI+DQo8cHJlIGNsYXNzPSJtb3otcXVv dGUtcHJlIiB3cmFwPSIiPg0KSSB3cm90ZSB0aGlzIGxhc3Qgd2VlaywgYW5kIHBhc3NlZCBpdCBh cm91bmQgZm9yIG9idmlvdXMgb2JqZWN0aW9ucy4NCiAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmst ZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tY3IvaW90d2ctY2hhcnRlci9ibG9i L21hc3Rlci9pb3R3Zy1jaGFydGVyLm1kIj5odHRwczovL2dpdGh1Yi5jb20vbWNyL2lvdHdnLWNo YXJ0ZXIvYmxvYi9tYXN0ZXIvaW90d2ctY2hhcnRlci5tZDwvYT4NCllvdSBjYW4gdXNlIHRoZSBj cmF5b24vZWRpdCBidXR0b24gb24gZ2l0aHViIHRvIHN1Z2dlc3QgY2hhbmdlcywgb3IgZW1haWwu DQoNCg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cA0KDQpUaGUgd29yZHMgJnF1b3Q7SW50ZXJu ZXQgb2YgVGhpbmdzJnF1b3Q7IG9yIElvVCBoYXZlIGNvbWUgdG8gbWVhbiBhbnl0aGluZyBhbmQN CmV2ZXJ5dGhpbmcgdG8gYSB3aWRlIGdyb3VwIG9mIHRlY2hub2xvZ3kgcGxheWVycy4gVGhlIElF VEYgaGFzIGJlZW4gd29ya2luZw0Kb24gYSB3aWRlIHZhcmlldHkgb2YgcHJvdG9jb2xzIGZvciB1 c2UgYnkgbWFjaGluZSB0byBtYWNoaW5lDQpjb21tdW5pY2F0aW9uLiBUaGlzIGluY2x1ZGUgQ29B UCwgQ0JPUiwgNlRJU0NILCBST0xMLCBTVUlULCBORVRDT05GIFNaVFAsDQpUMlRSRywgQU5JTUEn cyBCUlNLSSBvbmJvYXJkaW5nIHByb3RvY29sLCBhbmQgbW9zdCByZWNlbnRseSBSRkM4NTIwLCB0 aGUNCk1hbnVmYWN0dXJlciBVc2FnZSBEZXNjcmlwdGlvbi4gDQoNClRoZSBJRVRGIGhhcyB0cmll ZCB0byBmb2N1cyBvbiBjYXRlZ29yaWVzIG9mIHdoYXQgbGltaXRlZCB0aGluZ3MgY2FuIGRvLCBh bmQNCnRoaXMgaGFzIHJlc3VsdGVkIGluIGEgbnVtYmVyIG9mIHVzZWZ1bCBkb2N1bWVudHMgZnJv bSB0aGUgTGlnaHQtV2VpZ2h0DQpJbXBsZW1lbnRhdGlvbiBHdWlkZSAoTFdJRykuIFJGQzcyMjgg aXMgYSBrZXkgcHJvZHVjdCwgaGF2aW5nIHByb3ZpZGVkDQp0ZXJtaW5vbG9neSBhbmQgc2NhbGlu ZyB1bmRlcnN0YW5kaW5nIHRvIHRoZSBlbnRpcmUgaW5kdXN0cnkuIEFsbCBvZiB0aGlzIGhhcw0K YmVlbiBhYm91dCBzY2FsaW5nIHRoZSBJbnRlcm5ldCB0ZWNobm9sb2dpZXMgdG8gc21hbGwgZGV2 aWNlcyBhbmQgY29uc3RyYWluZWQNCm5ldHdvcmtzLiBJbiBhZ2dyZWdhdGUsIHRoZXNlIGRldmlj ZXMgb24gc21hbGwgbmV0d29ya3MgcHJlc2VudCBhIHNpZ25pZmljYW50DQpvcGVyYXRpb25hbCBy aXNrIHRvIHRoZSBJbnRlcm5ldCBhcyBhIHdob2xlLCBhbmQgZXZlbiB0byBpbmRpdmlkdWFsDQpF bnRlcnByaXNlLCBzaW1wbHkgZHVlIHRvIHRoZWlyIG51bWJlcnMsIGFuZCBsYWNrIG9mIG9wcG9y dHVuaXR5IGZvciByZWd1bGFyDQpodW1hbiBzdXBlcnZpc2lvbi4gDQoNCklvVCBkZXZpY2VzIGFs cmVhZHkgZXhpc3QgdG9kYXkgaW4gdmFzdCBudW1iZXJzLiBNb3N0IGRldmljZXMgdGhhdCBwZW9w bGUgYXJlDQpwZXJzb25hbGx5IGZhbWlsaWFyIHdpdGggYXJlIGluIHRoZSBCbHVlVG9vdGggQ29u bmVjdGVkIGRldmljZXMsIG9yDQpXZWItQ29ubmVjdGVkIGRldmljZXMgdGhhdCB1c2UgV2lGaSB0 byByZWFjaCBzZXJ2ZXJzIG9uIHRoZSBJbnRlcm5ldCAoJnF1b3Q7dGhlDQpDbG91ZCZxdW90Oyku IEluY3JlYXNpbmdseSwgdGhlIElFVEYgdmlldyBvZiBtYWNoaW5lIHRvIG1hY2hpbmUgY29tbXVu aWNhdGlvbnMgYXJlDQpjb2xpbml6aW5nIG5ldyBncmVlbmZpZWxkIHNpdHVhdGlvbnMuIFRoZSBJ RVRGIG5vdGlvbiBvZiBhdXRvbm9tb3VzIG5ldHdvcmtzDQpvZiBkZXZpY2VzIGlzIHN0aWxsIGEg bWlub3JpdHkgdmlldyBjb21wYXJlZCB0byB0aGUgbWFya2V0IElvVCBpbmR1c3RyeSBvZg0KY2xv dWQtb25seSBjb25uZWN0ZWQgZGV2aWNlcywgYnV0IHRoZSB0cmFuc2l0aW9uIGlzIG9jY3VyaW5n LiANCg0KUkZDODUyMCB3YXMgY3JlYXRlZCB0byBicmlkZ2UgdGhlIGdhcCBiZXR3ZWVuIGRldmlj ZXMgd2hvbGx5IGNvbnRyb2xsZWQgYnkgYQ0KbG9jYWwgb3BlcmF0b3IgKHN1Y2ggYXMgRW50ZXJw cmlzZSBJVCksIGFuZCBkZXZpY2VzIHdoaWNoIGNhbiBub3QgYXNzdW1lIGFueQ0KaW5mcmFzdHJ1 Y3R1cmUgYXQgYWxsLCBhbmQgbXVzdCByZWx5IGVudGlyZWx5IG9uIGNsb3VkIGNvbW11bmljYXRp b25zIGZvcg0KY29tbWFuZCBhbmQgY29udHJvbC4gDQoNClRoaXMgd29ya2luZyBncm91cCBjb25j ZXJucyBpdHNlbGYgd2l0aCBPcGVyYXRpb25hbCBTZWN1cml0eSBvZiBJb1Qgc3lzdGVtcy4NCg0K VGhpcyBpbmNsdWRlczoNCg0KKiBmYWN0b3J5IHByb3Zpc2lvbmluZyBvZiBkZXZpY2VzDQoqIG9u Ym9hcmRpbmcgb2YgZGV2aWNlcw0KKiBhY2Nlc3MgY29udHJvbCBvZiBkZXZpY2VzIHRvIG5ldHdv cmsgcmVzb3VyY2VzDQoqIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wgb2YgZGV2aWNlcw0KKiBhc3Nl dCBtYW5hZ2VtZW50IG9mIGRldmljZXMsIGFzIGl0IHBlcnRhaW5zIHRvIHNvZnR3YXJlL2Zpcm13 YXJlIHZlcnNpb25zDQoqIGlzb2xhdGlvbi9xdWFyYW50aW5lIG9mIGRldmljZXMNCiogcmVtZWRp YXRpb24gb2YgYnJva2VuIGRldmljZXMNCiogZW5kIG9mIGxpZmUgbWFuYWdlbWVudCBvZiBkZXZp Y2VzDQoNClRoZSBXRyBpcyBjaGFydGVyZWQgZXhwbGljaXRlbHkgdG8gd29yayBvbiBNVUQgKFJG Qzg1MjApIGFuZCBleHRlbnNpb25zIHRvIGl0Lg0KDQpUaGUgV0cgaXMgY2hhcnRlcmVkIHRvIHdv cmsgb24gb25ib2FyZGluZyBwcm90b2NvbHMsIHNwZWNpZmljYWxseSBpbmNsdWRpbmcNCmRlcml2 YXRpZXMgb2YgQlJTS0kgKFJGQy10YmQpLCBidXQgbm90IGxpbWl0ZWQgdG8ganVzdCB0aGF0IHBy b3RvY29sLg0KDQpUaGUgV0cgaXMgbm90IGV4cGVjdGVkIHRvIHBpY2sgYSB3aW5uZXIsIGFuZCBp cyBlbmNvdXJhZ2VkIHRvIHdvcmsgb24gYQ0KbXVsdGl0dWRlIG9mIHVzZS1jYXNlIHNwZWNpZmlj IHByb3RvY29sczogYmV0dGVyIHRvIGdldCBvbmUgdXNlIGNhc2UgcmlnaHQsDQp0aGFuIHRvIGJl IHRvby1jb21wbGV4IGphY2sgb2YgYWxsIHRyYWRlcy4gDQoNClRoZSBXRyBpcyBleHBlY3RlZCB0 byBhcnRpY3VsYXRlIGNsZWFyIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50cyBmb3IgZWFjaA0KcHJv dG9jb2wuIFRoZSBXRyBpcyBleHBlY3RlZCB0byBwcm9kdWNlIGNvbmNpc2UgUm9hZG1hcCBkb2N1 bWVudHMgdGhhdA0KZXhwbGFpbiBob3cgYSB2YXJpZXR5IG9mIElFVEYgKGFuZCBvdGhlcikgcHJv dG9jb2xzIGNhbiB3b3JrIHRvZ2V0aGVyIHRvDQpzYXRpc2Z5IHRoZSBPcGVyYXRpb25hbCBuZWVk cyBvZiBzcGVjaWZpYyBJb1QgYXJlYXMuIFRoZXNlIHJvYWRtYXAgZG9jdW1lbnRzDQpuZWVkbuKA mXQgcmVzdWx0IGluIFJGQ3MuIA0KDQpOZWl0aGVyIHRoZSBXRyBub3IgdGhlIElFVEYgaGFzIGV4 Y2x1c2l2aXR5IGhlcmUsIGFuZCBhbiBpZGVhbCBkb2N1bWVudCB3b3VsZA0KYmUgb25lIHRoYXQg dGhlIFdHIGhlbHBzIHRvIHN0YXJ0LCBidXQgYSBzcGVjaWZpYyBpbmR1c3RyeSBhbGxpYW5jZSBi ZWNvbWVzDQp0aGUgbGVhZCBlZGl0b3IgZm9yLiANCg0KVGhlcmUgd2lsbCBiZSBjb29yZGluYXRp b24gd2l0aCBtYW55IG90aGVyIFdHcyBiZXlvbmQgdGhlIGxpc3QgYWJvdmUsIGFuZA0KdGhpcyBX RyBtYXkgYWNjZXB0IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHdvcmsgZnJvbSBvdGhlciBXR3Mg YWJvdXQgc3BlY2lmaWMNCndheXMgdG8gZGVwbG95IHRoZWlyIHByb3RvY29scy4gDQoNClRoZSBX RyB3aWxsIG9wZXJhdGUgdGhyb3VnaCBhIHNlcmllcyBvZiB2aXJ0dWFsIGludGVyaW0gbWVldGlu Z3MuIFRoaXMgaXMNCmRyaXZlbiBieSBhIG5lZWQgdG8gaW50ZXJhY3QgcmVndWxhcmx5IHdpdGgg b3RoZXIgaW5kdXN0cnkgZ3JvdW9wcywgYW5kIGR1ZQ0KdG8gdGhlIHZhcmlldHkgb2YgdG9waWNz IHdoaWNoIHdpbGwgbm90IGFsd2F5cyBiZSBhYmxlIHRvIGdldCBxdW9ydW0gYXMgYQ0KY29tbWl0 dGVlIG9mIHRoZSB3aG9sZS4gDQoNCnt1bnVzdWFsLCBtYXliZSBub3QgY2hhcnRlciBhcHByb3By aWF0ZSwgYnV0IHJhdGhlciBzYWFnLWxpa2V9DQpEdXJpbmcgaW4tcGVyc29uIG1lZXRpbmdzLCB0 aGUgV0cgd2lsbCBkZWFsIHdpdGggdHlwaWNhbCBzdGF0dXMgYW5kIGRvY3VtZW50DQpwcm9ncmVz cyBpc3N1ZXMgZHVyaW5nIG9uZSBob3VyIChvciBsZXNzKSBvZiB0aGUgdGltZSwgYW5kIGR1cmlu ZyBhbm90aGVyDQpob3VyLCB3aWxsIGJlIG9wZW4gdG8gc2xpZGV3YXJlIHByZXNlbnRhdGlvbnMg YW5kIHR1dG9yaWFscyBvbiBjdXJyZW50IElFVEYNCm9yIG90aGVyLVNETyBJb1QgZWZmb3J0cy4g VGhlIGdvYWwgb2YgdGhlc2UgcHJlc2VudGF0aW9ucyBpcyB0byBxdWlja2x5DQpjb21tdW5pY2F0 ZSBjdXJyZW50IElvVCBzeXN0ZW1zIHN0YXRlIHRvIHRoZSByZXN0IG9mIHRoZSBJRVRGLg0KDQpJ dCBpcyBhY2tub3dsZWRnZWQgdGhhdCBwYXJ0IG9mIHRoZSB2YWx1ZSBpcyBpbiBZb3VUdWJlIGNv bnRlbnQsIGFuZCBzb21lDQpjb250ZW50IHNob3VsZCBiZSBkb25lIGF0IElBQiB0ZWNoIHBsZW5h cmllcyByYXRoZXIgdGhhbiBhdCB0aGUgV0cuIA0KDQpUaGUgaW5pdGlhbCBzZXQgb2Ygd29yayBp dGVtcyBpcyBpbmNsdWRlZCBiZWxvdyBhcyBtaWxlc3RvbmVzLCB3aGljaCBvbmx5DQpyZXF1aXJl IEFEIGFwcHJvdmFsLiANCg0KTWlsZXN0b25lcw0KDQoqIGFkb3B0IHRoZSBjb25zdHJhaW5lZC12 b3VjaGVyL2NvbnN0cmFpbmVkLUJSU0tJIHdvcmsgZnJvbSBBTklNQS4NCiogYWRvcHQgdGhlIGR0 c2VjdXJpdHktemVyby10b3VjaCB3b3JrIGZyb20gNnRpc2NoLCB3aGljaCBjYW4gbm90IGZpbmlz aCBiZWZvcmUgYSBMQUtFIGZpbmlzaGVzLg0KKiBjcmVhdGUgYSBsaXN0IG9mIGEgc2VyaWVzIG9m IE1VRCBleHRlbnNpb25zLCBhbmQgcmV2aXNlIHRoaXMgbWlsZXN0b25lDQoqIGFkb3B0IGEgY2xv dWQtbGVzcyAoTUFTQS1sZXNzLCBBQUEtbGVzcykgb25ib2FyZGluZyBtZWNoYW5pc20gKHBvc3Np Ymx5IGEgdmVyc2lvbiBvZiBFQVAtTk9PQiksIHRoYXQgY2FuIGJlIHVzZWQgYXQgdGhlIHJldGFp bCBsZXZlbC4NCiogbmVnb3RpYXRlIHdpdGggRU1VIFdHIG9uIGhvdyB0byBwcm9jZWVkIHdpdGgg VEVBUC1CUlNLSSwgYW5kIHJldmlzZSB0aGlzIG1pbGVzdG9uZS4NCiogYWRvcHQgYSBjbG91ZC1k cml2ZW4gb25ib2FyZGluZyBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZCBpbiBjb21wbGV0ZWx5 IG9mZmxpbmUgc2l0dWF0aW9ucyB3aXRob3V0IHJlcXVpcmluZyByZW5ld2FscyAocGVyaGFwcyBy ZXZpc2luZyBSRkM4MzY2KS4NCi4uLi4NCg0KDQoNCg0KPC9wcmU+DQo8YnI+DQo8ZmllbGRzZXQg Y2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PiA8L2Jsb2NrcXVvdGU+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_30e9de9068b07b45a94e165bb6fabbb5ericssoncom_-- From nobody Thu Sep 12 08:08:35 2019 Return-Path: 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 72889120821; Wed, 11 Sep 2019 12:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 BX7kMliHedFg; Wed, 11 Sep 2019 12:26:55 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on061e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::61e]) (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 0E994120834; Wed, 11 Sep 2019 12:26:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kpo8MWE4bVCXMImLh3mW098d67J+h8eJ14MPr3VU9rkKe9cmx0wApDYCKQgjQLkk/CTZcGv6GmkabMJz32DCyhrOeOSsqP7Xllc4L86d8gwFPP6rrZ/gMjw+SHjmuiCZLojOEzEV9Pmb+VQWxqsSt+udumseeS/ZaAZXROfCLdslL5J0HMiHYfU+iIwWhEU8agTZ8WWcD9319Q+mbzuBYa2EPj0Ecem7SDwx3kXdTqR1Tzv4ECpIjljdqmLmXvr5wWR0kRFygUPeN37Z5aIRHL+lbK3UbzCya5XgrTF7vap5G54gC9r9jGE43pz2OuzjQh2J57LYPD4z+Xzr9GKSTQ== 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=Ym5vx1FmTPP1JrnJpJnBZPsMaZDIyd4r+fM6UNTETzc=; b=IWWJNZao7KYZ2APirmLB9cmN+UHlTPdLsURQB81EcULKgDxUa+4TIRtETXq55HnlKgkpHTKnF2DJQcs6RG2h0Xtg6h+x/kRHmQifAkLm6+iegWJsN1mrZt6GaaH0zloCIGgY4uSCaZz4TQ4xowvqaPmeKJbDb5gPgmSMBgtxXojEQLpW4T4YFjEwAcNlPC92fOSFEQbOGFk09EUdNX7v7pfs6Q0YzEuu7gnbJONBRFON6pD5F/ygsIfsuxXFs85fNs9wrv1wWmGkdaU970oq4RvgAjTsqIrJ5tTjl4YSilN39eWINr48riBh4Fw+tAUAOpOWEAtKenKIO505u+yEUA== 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=Ym5vx1FmTPP1JrnJpJnBZPsMaZDIyd4r+fM6UNTETzc=; b=Xb/cGO2YaYVLmhVqNzu6GIVQzlvVTEG033yHZ/CO2ek58St12/ugr9eiaZH7Uxm3laZ2kA0TJcceIGJ6rmfUw+ZLkOejTHWn2K/Zq0NC4NWskwN241mZIblSUwFN8B/uf0kobJiM39Ad9D1BS5EJyHDhTXx/ZtV0CRZmB4I9ATI= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2604.eurprd07.prod.outlook.com (10.168.187.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.7; Wed, 11 Sep 2019 19:26:52 +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.2263.015; Wed, 11 Sep 2019 19:26:52 +0000 From: Mohit Sethi M To: Kent Watsen , Michael Richardson CC: "iot-onboarding@ietf.org" , "mud@ietf.org" Thread-Topic: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG Thread-Index: AQHVaNbcpd2ivcpAw0yCVRFO+FMgJw== Date: Wed, 11 Sep 2019 19:26:52 +0000 Message-ID: References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> In-Reply-To: <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.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: [87.93.24.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f1971aa-5f4b-47e8-f9db-08d736edfff5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2604; x-ms-traffictypediagnostic: HE1PR0701MB2604: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(199004)(189003)(64756008)(66476007)(66446008)(66556008)(7736002)(26005)(606006)(478600001)(76116006)(14444005)(186003)(66574012)(66946007)(2906002)(256004)(3846002)(81156014)(81166006)(99286004)(8676002)(36756003)(6116002)(6246003)(65806001)(53936002)(66066001)(65956001)(446003)(6506007)(14454004)(316002)(86362001)(53546011)(8936002)(31696002)(4326008)(6512007)(31686004)(229853002)(15650500001)(5660300002)(76176011)(102836004)(25786009)(486006)(966005)(236005)(11346002)(54906003)(6436002)(110136005)(476003)(6486002)(54896002)(6306002)(71190400001)(71200400001)(58126008)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2604; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: IiESqffBF2U+gaDzxG0eZxu/XOCAaL1SCspXGfUV3wCglUV2ppLOUD8y6RiFUxiyF4B6WF1B8NQ25kSobNL86KlBPdnLSu97EHpDSxBAb5dLnfqTk+olEd5lB4nd4jGNV0/8iMRwazt90psmnL1n+qU1BeZnh7OUQae9tyHSFVsRAGMP8qawTWIxCJzsLoUBYEYJ+ORqVOejx1znybYx0y72T9/PMJKytZyydFoGNqSiIasEeDzIXlsL7BD9oi/pdqHjd+x1S1X0AZfdKPbJHI29GwxaHajgj/IRZZkDKAg/Fd9Qlr36XitVCsoe0yZjujPPQSgw4D3kf7Lr3Qshb+MhpwxRtLIP4hyz1MBNWSL4p1OPeWWDf0mWAha7C4/WDJ5xEivlb+R+fpaCSP4JQoLTqSG+zQcbgba7G+5HBvE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_bb757b7bdffc94944ae0a709d30445dfericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f1971aa-5f4b-47e8-f9db-08d736edfff5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2019 19:26:52.4034 (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: rQuSSS5ToVrVvNFXHHCzKFu4ynCFWOJe10QpmjaYog6ldkh1hqUG5M/NM8DL8hnXKu/F6K3Jmk6qpxT19eyhHruTUtpxv+wXDmfx/AUq3C8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2604 Archived-At: X-Mailman-Approved-At: Thu, 12 Sep 2019 08:08:25 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 19:26:59 -0000 --_000_bb757b7bdffc94944ae0a709d30445dfericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KQ291bGQgeW91IGV4cGxhaW4gdGhlIGhpZ2gtbGV2ZWwgZGlmZmVyZW5jZXMg YmV0d2VlbiBCUlNLSSBhbmQgU1pUUCBmb3IgdGhvc2UgbGlrZSBtZSB3aG8gYXJlIG5vdCBleHRy ZW1lbHkgZmFtaWxpYXIuDQoNCkkga25vdyB0aGVyZSBhcmUgcHJvYmFibHkgbWFueSBkaWZmZXJl bmNlcy4gRm9yIGV4YW1wbGUsIEkgc2VlIHRoYXQgdGhlIFNaVFAgc3BlYyBzYXlzIHRoYXQgZGV2 aWNlcyBjYW4gcmVjZWl2ZSBpbml0aWFsIGJvb3RzdHJhcCBpbmZvcm1hdGlvbiBvdmVyIEROUyBv ciBmcm9tIGEgYm9vdHN0cmFwIHNlcnZlci4NCg0KV2hhdCBJIGFtIHRyeWluZyB0byB1bmRlcnN0 YW5kIGlzIHdoYXQgZG9lcyBhIGRldmljZSBzdGFydCBmcm9tIChzaGFyZWQtc2VjcmV0L2VwaGVt ZXJhbCBrZXkgcGFpci9tYW51ZmFjdHVyZXIgY2VydGlmaWNhdGUpLCBhbmQgd2hhdCBkb2VzIGl0 IGVuZCB3aXRoPyBEbyB3ZSBuZWVkIGJvdGggU1pUUCBhbmQgQlJTS0k/DQoNCi0tTW9oaXQNCg0K T24gOS80LzE5IDQ6NDcgUE0sIEtlbnQgV2F0c2VuIHdyb3RlOg0KSSdtIHN0aWxsIG5vdCAxMDAl IHN1cmUgaWYgdGhpcyB3b3JraW5nIGdyb3VwIGlzIG5lZWRlZCBidXQsIGlmIHN1Y2ggYSB3b3Jr aW5nIGdyb3VwIGlzIHRvIGJlIGZvcm1lZCwgSSBvYmplY3QgdG8gaXQgYmVpbmcgQlJTS0ktb3Jp ZW50ZWQsIGFzIGFscmVhZHkgdGhlcmUgaXMgQU5JTUEgZm9yIHRoYXQuICBJIGFwcHJlY2lhdGUg dGhhdCB0aGUgZmlyc3QgcGFyYWdyYXBoIGVudW1lcmF0ZXMgYSBudW1iZXIgb2YgZWZmb3J0cyAo QlRXLCBpdCBzaG91bGQgYmUganVzdCAiU1pUUCIsIHdpdGhvdXQgdGhlIE5FVENPTkYgcXVhbGlm aWVyKSwgYW5kIGxhdGVyIHRoZSB0ZXh0IHNheXMgdGhhdCBpdCdzICJub3QgbGltaXRlZCB0byBq dXN0IHRoYXQgcHJvdG9jb2wiIChiZWluZyBCUlNLSSksIGJ1dCB0aGUgZ2VuZXJhbCB0b25lLCBh bmQgc3BlY2lmaWNhbGx5IHRoZSBNaWxlc3RvbmVzLCBhcmUgdmVyeSBCUlNLSS1zcGVjaWZpYy4g IFRvIGJlIGNsZWFyLCBpZiBzdWNoIGEgd29ya2luZyBncm91cCB3ZXJlIGZvcm1lZCwgSSB3b3Vs ZCBsaWtlIHRvIHN1Ym1pdCBhIGRvY3VtZW50IGVudGl0bGVkIHNvbWV0aGluZyBsaWtlICJTWlRQ IGZvciBJb1QgYW5kIG90aGVyIENvbnN0cmFpbmVkIERldmljZXMiLiAgSW4gdGhpcyBkb2N1bWVu dCBJIGNvdWxkIHNob3cgaG93IFNaVFAgY291bGQgYmUgZXh0ZW5kZWQgdG8gdXNlIERUTFMsIENC T1IsIGFuZCBDb0FQIGFuZCBmdXJ0aGVyLCB0aGF0IGl0IGFjaGlldmVzIGJvb3RzdHJhcCBzdGF0 ZSB3aXRoIGZld2VyIG1lc3NhZ2UgZXhjaGFuZ2VzIGFuZCBncmVhdGVyIGZsZXhpYmlsaXR5LCBu b3QgdG8gbWVudGlvbiB0aGF0IGl0IGFscmVhZHkgc3VwcG9ydHMgdGhlIG9mZmxpbmUvY2xvdWRs ZXNzIHVzZS1jYXNlIGFuZCBhIHBldXNkby1OT09CIGFwcHJvYWNoIChhbHJlYWR5IGltcGxlbWVu dGVkIGJ5IEp1bmlwZXIpLiAgU1pUUC1URUFQIGNvdWxkIGFsc28gYmUgcHJvdmlkZWQgZm9yLg0K DQpUaGFua3MsDQpLZW50DQoNCg0KDQoNCg0KT24gU2VwIDQsIDIwMTksIGF0IDM6NDUgQU0sIE1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBz YW5kZWxtYW4uY2E+PiB3cm90ZToNCg0KDQpJIHdyb3RlIHRoaXMgbGFzdCB3ZWVrLCBhbmQgcGFz c2VkIGl0IGFyb3VuZCBmb3Igb2J2aW91cyBvYmplY3Rpb25zLg0KICBodHRwczovL2dpdGh1Yi5j b20vbWNyL2lvdHdnLWNoYXJ0ZXIvYmxvYi9tYXN0ZXIvaW90d2ctY2hhcnRlci5tZA0KWW91IGNh biB1c2UgdGhlIGNyYXlvbi9lZGl0IGJ1dHRvbiBvbiBnaXRodWIgdG8gc3VnZ2VzdCBjaGFuZ2Vz LCBvciBlbWFpbC4NCg0KDQpDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwDQoNClRoZSB3b3JkcyAi SW50ZXJuZXQgb2YgVGhpbmdzIiBvciBJb1QgaGF2ZSBjb21lIHRvIG1lYW4gYW55dGhpbmcgYW5k DQpldmVyeXRoaW5nIHRvIGEgd2lkZSBncm91cCBvZiB0ZWNobm9sb2d5IHBsYXllcnMuIFRoZSBJ RVRGIGhhcyBiZWVuIHdvcmtpbmcNCm9uIGEgd2lkZSB2YXJpZXR5IG9mIHByb3RvY29scyBmb3Ig dXNlIGJ5IG1hY2hpbmUgdG8gbWFjaGluZQ0KY29tbXVuaWNhdGlvbi4gVGhpcyBpbmNsdWRlIENv QVAsIENCT1IsIDZUSVNDSCwgUk9MTCwgU1VJVCwgTkVUQ09ORiBTWlRQLA0KVDJUUkcsIEFOSU1B J3MgQlJTS0kgb25ib2FyZGluZyBwcm90b2NvbCwgYW5kIG1vc3QgcmVjZW50bHkgUkZDODUyMCwg dGhlDQpNYW51ZmFjdHVyZXIgVXNhZ2UgRGVzY3JpcHRpb24uDQoNClRoZSBJRVRGIGhhcyB0cmll ZCB0byBmb2N1cyBvbiBjYXRlZ29yaWVzIG9mIHdoYXQgbGltaXRlZCB0aGluZ3MgY2FuIGRvLCBh bmQNCnRoaXMgaGFzIHJlc3VsdGVkIGluIGEgbnVtYmVyIG9mIHVzZWZ1bCBkb2N1bWVudHMgZnJv bSB0aGUgTGlnaHQtV2VpZ2h0DQpJbXBsZW1lbnRhdGlvbiBHdWlkZSAoTFdJRykuIFJGQzcyMjgg aXMgYSBrZXkgcHJvZHVjdCwgaGF2aW5nIHByb3ZpZGVkDQp0ZXJtaW5vbG9neSBhbmQgc2NhbGlu ZyB1bmRlcnN0YW5kaW5nIHRvIHRoZSBlbnRpcmUgaW5kdXN0cnkuIEFsbCBvZiB0aGlzIGhhcw0K YmVlbiBhYm91dCBzY2FsaW5nIHRoZSBJbnRlcm5ldCB0ZWNobm9sb2dpZXMgdG8gc21hbGwgZGV2 aWNlcyBhbmQgY29uc3RyYWluZWQNCm5ldHdvcmtzLiBJbiBhZ2dyZWdhdGUsIHRoZXNlIGRldmlj ZXMgb24gc21hbGwgbmV0d29ya3MgcHJlc2VudCBhIHNpZ25pZmljYW50DQpvcGVyYXRpb25hbCBy aXNrIHRvIHRoZSBJbnRlcm5ldCBhcyBhIHdob2xlLCBhbmQgZXZlbiB0byBpbmRpdmlkdWFsDQpF bnRlcnByaXNlLCBzaW1wbHkgZHVlIHRvIHRoZWlyIG51bWJlcnMsIGFuZCBsYWNrIG9mIG9wcG9y dHVuaXR5IGZvciByZWd1bGFyDQpodW1hbiBzdXBlcnZpc2lvbi4NCg0KSW9UIGRldmljZXMgYWxy ZWFkeSBleGlzdCB0b2RheSBpbiB2YXN0IG51bWJlcnMuIE1vc3QgZGV2aWNlcyB0aGF0IHBlb3Bs ZSBhcmUNCnBlcnNvbmFsbHkgZmFtaWxpYXIgd2l0aCBhcmUgaW4gdGhlIEJsdWVUb290aCBDb25u ZWN0ZWQgZGV2aWNlcywgb3INCldlYi1Db25uZWN0ZWQgZGV2aWNlcyB0aGF0IHVzZSBXaUZpIHRv IHJlYWNoIHNlcnZlcnMgb24gdGhlIEludGVybmV0ICgidGhlDQpDbG91ZCIpLiBJbmNyZWFzaW5n bHksIHRoZSBJRVRGIHZpZXcgb2YgbWFjaGluZSB0byBtYWNoaW5lIGNvbW11bmljYXRpb25zIGFy ZQ0KY29saW5pemluZyBuZXcgZ3JlZW5maWVsZCBzaXR1YXRpb25zLiBUaGUgSUVURiBub3Rpb24g b2YgYXV0b25vbW91cyBuZXR3b3Jrcw0Kb2YgZGV2aWNlcyBpcyBzdGlsbCBhIG1pbm9yaXR5IHZp ZXcgY29tcGFyZWQgdG8gdGhlIG1hcmtldCBJb1QgaW5kdXN0cnkgb2YNCmNsb3VkLW9ubHkgY29u bmVjdGVkIGRldmljZXMsIGJ1dCB0aGUgdHJhbnNpdGlvbiBpcyBvY2N1cmluZy4NCg0KUkZDODUy MCB3YXMgY3JlYXRlZCB0byBicmlkZ2UgdGhlIGdhcCBiZXR3ZWVuIGRldmljZXMgd2hvbGx5IGNv bnRyb2xsZWQgYnkgYQ0KbG9jYWwgb3BlcmF0b3IgKHN1Y2ggYXMgRW50ZXJwcmlzZSBJVCksIGFu ZCBkZXZpY2VzIHdoaWNoIGNhbiBub3QgYXNzdW1lIGFueQ0KaW5mcmFzdHJ1Y3R1cmUgYXQgYWxs LCBhbmQgbXVzdCByZWx5IGVudGlyZWx5IG9uIGNsb3VkIGNvbW11bmljYXRpb25zIGZvcg0KY29t bWFuZCBhbmQgY29udHJvbC4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIGNvbmNlcm5zIGl0c2VsZiB3 aXRoIE9wZXJhdGlvbmFsIFNlY3VyaXR5IG9mIElvVCBzeXN0ZW1zLg0KDQpUaGlzIGluY2x1ZGVz Og0KDQoqIGZhY3RvcnkgcHJvdmlzaW9uaW5nIG9mIGRldmljZXMNCiogb25ib2FyZGluZyBvZiBk ZXZpY2VzDQoqIGFjY2VzcyBjb250cm9sIG9mIGRldmljZXMgdG8gbmV0d29yayByZXNvdXJjZXMN CiogYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvZiBkZXZpY2VzDQoqIGFzc2V0IG1hbmFnZW1lbnQg b2YgZGV2aWNlcywgYXMgaXQgcGVydGFpbnMgdG8gc29mdHdhcmUvZmlybXdhcmUgdmVyc2lvbnMN CiogaXNvbGF0aW9uL3F1YXJhbnRpbmUgb2YgZGV2aWNlcw0KKiByZW1lZGlhdGlvbiBvZiBicm9r ZW4gZGV2aWNlcw0KKiBlbmQgb2YgbGlmZSBtYW5hZ2VtZW50IG9mIGRldmljZXMNCg0KVGhlIFdH IGlzIGNoYXJ0ZXJlZCBleHBsaWNpdGVseSB0byB3b3JrIG9uIE1VRCAoUkZDODUyMCkgYW5kIGV4 dGVuc2lvbnMgdG8gaXQuDQoNClRoZSBXRyBpcyBjaGFydGVyZWQgdG8gd29yayBvbiBvbmJvYXJk aW5nIHByb3RvY29scywgc3BlY2lmaWNhbGx5IGluY2x1ZGluZw0KZGVyaXZhdGllcyBvZiBCUlNL SSAoUkZDLXRiZCksIGJ1dCBub3QgbGltaXRlZCB0byBqdXN0IHRoYXQgcHJvdG9jb2wuDQoNClRo ZSBXRyBpcyBub3QgZXhwZWN0ZWQgdG8gcGljayBhIHdpbm5lciwgYW5kIGlzIGVuY291cmFnZWQg dG8gd29yayBvbiBhDQptdWx0aXR1ZGUgb2YgdXNlLWNhc2Ugc3BlY2lmaWMgcHJvdG9jb2xzOiBi ZXR0ZXIgdG8gZ2V0IG9uZSB1c2UgY2FzZSByaWdodCwNCnRoYW4gdG8gYmUgdG9vLWNvbXBsZXgg amFjayBvZiBhbGwgdHJhZGVzLg0KDQpUaGUgV0cgaXMgZXhwZWN0ZWQgdG8gYXJ0aWN1bGF0ZSBj bGVhciBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMgZm9yIGVhY2gNCnByb3RvY29sLiBUaGUgV0cg aXMgZXhwZWN0ZWQgdG8gcHJvZHVjZSBjb25jaXNlIFJvYWRtYXAgZG9jdW1lbnRzIHRoYXQNCmV4 cGxhaW4gaG93IGEgdmFyaWV0eSBvZiBJRVRGIChhbmQgb3RoZXIpIHByb3RvY29scyBjYW4gd29y ayB0b2dldGhlciB0bw0Kc2F0aXNmeSB0aGUgT3BlcmF0aW9uYWwgbmVlZHMgb2Ygc3BlY2lmaWMg SW9UIGFyZWFzLiBUaGVzZSByb2FkbWFwIGRvY3VtZW50cw0KbmVlZG7igJl0IHJlc3VsdCBpbiBS RkNzLg0KDQpOZWl0aGVyIHRoZSBXRyBub3IgdGhlIElFVEYgaGFzIGV4Y2x1c2l2aXR5IGhlcmUs IGFuZCBhbiBpZGVhbCBkb2N1bWVudCB3b3VsZA0KYmUgb25lIHRoYXQgdGhlIFdHIGhlbHBzIHRv IHN0YXJ0LCBidXQgYSBzcGVjaWZpYyBpbmR1c3RyeSBhbGxpYW5jZSBiZWNvbWVzDQp0aGUgbGVh ZCBlZGl0b3IgZm9yLg0KDQpUaGVyZSB3aWxsIGJlIGNvb3JkaW5hdGlvbiB3aXRoIG1hbnkgb3Ro ZXIgV0dzIGJleW9uZCB0aGUgbGlzdCBhYm92ZSwgYW5kDQp0aGlzIFdHIG1heSBhY2NlcHQgYXBw bGljYWJpbGl0eSBzdGF0ZW1lbnQgd29yayBmcm9tIG90aGVyIFdHcyBhYm91dCBzcGVjaWZpYw0K d2F5cyB0byBkZXBsb3kgdGhlaXIgcHJvdG9jb2xzLg0KDQpUaGUgV0cgd2lsbCBvcGVyYXRlIHRo cm91Z2ggYSBzZXJpZXMgb2YgdmlydHVhbCBpbnRlcmltIG1lZXRpbmdzLiBUaGlzIGlzDQpkcml2 ZW4gYnkgYSBuZWVkIHRvIGludGVyYWN0IHJlZ3VsYXJseSB3aXRoIG90aGVyIGluZHVzdHJ5IGdy b3VvcHMsIGFuZCBkdWUNCnRvIHRoZSB2YXJpZXR5IG9mIHRvcGljcyB3aGljaCB3aWxsIG5vdCBh bHdheXMgYmUgYWJsZSB0byBnZXQgcXVvcnVtIGFzIGENCmNvbW1pdHRlZSBvZiB0aGUgd2hvbGUu DQoNCnt1bnVzdWFsLCBtYXliZSBub3QgY2hhcnRlciBhcHByb3ByaWF0ZSwgYnV0IHJhdGhlciBz YWFnLWxpa2V9DQpEdXJpbmcgaW4tcGVyc29uIG1lZXRpbmdzLCB0aGUgV0cgd2lsbCBkZWFsIHdp dGggdHlwaWNhbCBzdGF0dXMgYW5kIGRvY3VtZW50DQpwcm9ncmVzcyBpc3N1ZXMgZHVyaW5nIG9u ZSBob3VyIChvciBsZXNzKSBvZiB0aGUgdGltZSwgYW5kIGR1cmluZyBhbm90aGVyDQpob3VyLCB3 aWxsIGJlIG9wZW4gdG8gc2xpZGV3YXJlIHByZXNlbnRhdGlvbnMgYW5kIHR1dG9yaWFscyBvbiBj dXJyZW50IElFVEYNCm9yIG90aGVyLVNETyBJb1QgZWZmb3J0cy4gVGhlIGdvYWwgb2YgdGhlc2Ug cHJlc2VudGF0aW9ucyBpcyB0byBxdWlja2x5DQpjb21tdW5pY2F0ZSBjdXJyZW50IElvVCBzeXN0 ZW1zIHN0YXRlIHRvIHRoZSByZXN0IG9mIHRoZSBJRVRGLg0KDQpJdCBpcyBhY2tub3dsZWRnZWQg dGhhdCBwYXJ0IG9mIHRoZSB2YWx1ZSBpcyBpbiBZb3VUdWJlIGNvbnRlbnQsIGFuZCBzb21lDQpj b250ZW50IHNob3VsZCBiZSBkb25lIGF0IElBQiB0ZWNoIHBsZW5hcmllcyByYXRoZXIgdGhhbiBh dCB0aGUgV0cuDQoNClRoZSBpbml0aWFsIHNldCBvZiB3b3JrIGl0ZW1zIGlzIGluY2x1ZGVkIGJl bG93IGFzIG1pbGVzdG9uZXMsIHdoaWNoIG9ubHkNCnJlcXVpcmUgQUQgYXBwcm92YWwuDQoNCk1p bGVzdG9uZXMNCg0KKiBhZG9wdCB0aGUgY29uc3RyYWluZWQtdm91Y2hlci9jb25zdHJhaW5lZC1C UlNLSSB3b3JrIGZyb20gQU5JTUEuDQoqIGFkb3B0IHRoZSBkdHNlY3VyaXR5LXplcm8tdG91Y2gg d29yayBmcm9tIDZ0aXNjaCwgd2hpY2ggY2FuIG5vdCBmaW5pc2ggYmVmb3JlIGEgTEFLRSBmaW5p c2hlcy4NCiogY3JlYXRlIGEgbGlzdCBvZiBhIHNlcmllcyBvZiBNVUQgZXh0ZW5zaW9ucywgYW5k IHJldmlzZSB0aGlzIG1pbGVzdG9uZQ0KKiBhZG9wdCBhIGNsb3VkLWxlc3MgKE1BU0EtbGVzcywg QUFBLWxlc3MpIG9uYm9hcmRpbmcgbWVjaGFuaXNtIChwb3NzaWJseSBhIHZlcnNpb24gb2YgRUFQ LU5PT0IpLCB0aGF0IGNhbiBiZSB1c2VkIGF0IHRoZSByZXRhaWwgbGV2ZWwuDQoqIG5lZ290aWF0 ZSB3aXRoIEVNVSBXRyBvbiBob3cgdG8gcHJvY2VlZCB3aXRoIFRFQVAtQlJTS0ksIGFuZCByZXZp c2UgdGhpcyBtaWxlc3RvbmUuDQoqIGFkb3B0IGEgY2xvdWQtZHJpdmVuIG9uYm9hcmRpbmcgbWVj aGFuaXNtIHRoYXQgY2FuIGJlIHVzZWQgaW4gY29tcGxldGVseSBvZmZsaW5lIHNpdHVhdGlvbnMg d2l0aG91dCByZXF1aXJpbmcgcmVuZXdhbHMgKHBlcmhhcHMgcmV2aXNpbmcgUkZDODM2NikuDQou Li4uDQoNCg0KDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YTxtYWlsdG86bWNyK0lFVEZAc2FuZGVsbWFuLmNhPj4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jr cw0KLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KDQoNCg0KLS0NCklvdC1vbmJvYXJkaW5nIG1h aWxpbmcgbGlzdA0KSW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc8bWFpbHRvOklvdC1vbmJvYXJkaW5n QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3Qtb25i b2FyZGluZw0KDQoNCg0K --_000_bb757b7bdffc94944ae0a709d30445dfericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <156C473033DE3F4AAF37D0A566AF6229@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgS2VudCw8L3A+DQo8cD5Db3VsZCB5b3UgZXhwbGFp biB0aGUgaGlnaC1sZXZlbCBkaWZmZXJlbmNlcyBiZXR3ZWVuIEJSU0tJIGFuZCBTWlRQIGZvciB0 aG9zZSBsaWtlIG1lIHdobyBhcmUgbm90IGV4dHJlbWVseSBmYW1pbGlhci4NCjxicj4NCjwvcD4N CjxwPkkga25vdyB0aGVyZSBhcmUgcHJvYmFibHkgbWFueSBkaWZmZXJlbmNlcy4gRm9yIGV4YW1w bGUsIEkgc2VlIHRoYXQgdGhlIFNaVFAgc3BlYyBzYXlzIHRoYXQgZGV2aWNlcyBjYW4gcmVjZWl2 ZSBpbml0aWFsIGJvb3RzdHJhcCBpbmZvcm1hdGlvbiBvdmVyIEROUyBvciBmcm9tIGEgYm9vdHN0 cmFwIHNlcnZlci4NCjxicj4NCjwvcD4NCjxwPldoYXQgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFu ZCBpcyB3aGF0IGRvZXMgYSBkZXZpY2Ugc3RhcnQgZnJvbSAoc2hhcmVkLXNlY3JldC9lcGhlbWVy YWwga2V5IHBhaXIvbWFudWZhY3R1cmVyIGNlcnRpZmljYXRlKSwgYW5kIHdoYXQgZG9lcyBpdCBl bmQgd2l0aD8gRG8gd2UgbmVlZCBib3RoIFNaVFAgYW5kIEJSU0tJPzxicj4NCjwvcD4NCjxwPi0t TW9oaXQ8YnI+DQo8L3A+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDkvNC8xOSA0 OjQ3IFBNLCBLZW50IFdhdHNlbiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNpdGU9Im1pZDowMTAwMDE2Y2ZjODc3Mjg3LWMyMTk4YWVlLWZmZTYtNGMyOC05NGEx LWNiMTQxYjkyNzQxZi0wMDAwMDBAZW1haWwuYW1hem9uc2VzLmNvbSI+DQo8ZGl2IGNsYXNzPSIi PkknbSBzdGlsbCBub3QgMTAwJSBzdXJlIGlmIHRoaXMgd29ya2luZyBncm91cCBpcyBuZWVkZWQg YnV0LCBpZiBzdWNoIGEgd29ya2luZyBncm91cCBpcyB0byBiZSBmb3JtZWQsIEkgb2JqZWN0IHRv IGl0IGJlaW5nIEJSU0tJLW9yaWVudGVkLCBhcyBhbHJlYWR5IHRoZXJlIGlzIEFOSU1BIGZvciB0 aGF0LiAmbmJzcDtJIGFwcHJlY2lhdGUgdGhhdCB0aGUgZmlyc3QgcGFyYWdyYXBoIGVudW1lcmF0 ZXMgYSBudW1iZXIgb2YgZWZmb3J0cw0KIChCVFcsIGl0IHNob3VsZCBiZSBqdXN0ICZxdW90O1Na VFAmcXVvdDssIHdpdGhvdXQgdGhlIE5FVENPTkYgcXVhbGlmaWVyKSwgYW5kIGxhdGVyIHRoZSB0 ZXh0IHNheXMgdGhhdCBpdCdzICZxdW90O25vdCBsaW1pdGVkIHRvIGp1c3QgdGhhdCBwcm90b2Nv bCZxdW90OyAoYmVpbmcgQlJTS0kpLCBidXQgdGhlIGdlbmVyYWwgdG9uZSwgYW5kIHNwZWNpZmlj YWxseSB0aGUgTWlsZXN0b25lcywgYXJlIHZlcnkgQlJTS0ktc3BlY2lmaWMuICZuYnNwO1RvIGJl IGNsZWFyLCBpZiBzdWNoIGEgd29ya2luZw0KIGdyb3VwIHdlcmUgZm9ybWVkLCBJIHdvdWxkIGxp a2UgdG8gc3VibWl0IGEgZG9jdW1lbnQgZW50aXRsZWQgc29tZXRoaW5nIGxpa2UgJnF1b3Q7U1pU UCBmb3IgSW9UIGFuZCBvdGhlciBDb25zdHJhaW5lZCBEZXZpY2VzJnF1b3Q7LiAmbmJzcDtJbiB0 aGlzIGRvY3VtZW50IEkgY291bGQgc2hvdyBob3cgU1pUUCBjb3VsZCBiZSBleHRlbmRlZCB0byB1 c2UgRFRMUywgQ0JPUiwgYW5kIENvQVAgYW5kIGZ1cnRoZXIsIHRoYXQgaXQgYWNoaWV2ZXMgYm9v dHN0cmFwIHN0YXRlIHdpdGgNCiBmZXdlciBtZXNzYWdlIGV4Y2hhbmdlcyBhbmQgZ3JlYXRlciBm bGV4aWJpbGl0eSwgbm90IHRvIG1lbnRpb24gdGhhdCBpdCBhbHJlYWR5IHN1cHBvcnRzIHRoZSBv ZmZsaW5lL2Nsb3VkbGVzcyB1c2UtY2FzZSBhbmQgYSBwZXVzZG8tTk9PQiBhcHByb2FjaCAoYWxy ZWFkeSBpbXBsZW1lbnRlZCBieSBKdW5pcGVyKS4gJm5ic3A7U1pUUC1URUFQIGNvdWxkIGFsc28g YmUgcHJvdmlkZWQgZm9yLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5LZW50PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgNCwgMjAxOSwgYXQgMzo0NSBBTSwgTWlj aGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1h bi5jYSIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5tY3ImIzQzO2lldGZAc2FuZGVs bWFuLmNhPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K SSB3cm90ZSB0aGlzIGxhc3Qgd2VlaywgYW5kIHBhc3NlZCBpdCBhcm91bmQgZm9yIG9idmlvdXMg b2JqZWN0aW9ucy48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vbWNyL2lvdHdnLWNoYXJ0ZXIvYmxvYi9tYXN0ZXIvaW90d2ctY2hhcnRlci5tZCIg Y2xhc3M9IiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL2dpdGh1Yi5jb20vbWNyL2lv dHdnLWNoYXJ0ZXIvYmxvYi9tYXN0ZXIvaW90d2ctY2hhcnRlci5tZDwvYT48YnIgY2xhc3M9IiI+ DQpZb3UgY2FuIHVzZSB0aGUgY3JheW9uL2VkaXQgYnV0dG9uIG9uIGdpdGh1YiB0byBzdWdnZXN0 IGNoYW5nZXMsIG9yIGVtYWlsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkNoYXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGUgd29yZHMgJnF1b3Q7SW50ZXJuZXQgb2YgVGhpbmdzJnF1b3Q7IG9yIElvVCBoYXZl IGNvbWUgdG8gbWVhbiBhbnl0aGluZyBhbmQ8YnIgY2xhc3M9IiI+DQpldmVyeXRoaW5nIHRvIGEg d2lkZSBncm91cCBvZiB0ZWNobm9sb2d5IHBsYXllcnMuIFRoZSBJRVRGIGhhcyBiZWVuIHdvcmtp bmc8YnIgY2xhc3M9IiI+DQpvbiBhIHdpZGUgdmFyaWV0eSBvZiBwcm90b2NvbHMgZm9yIHVzZSBi eSBtYWNoaW5lIHRvIG1hY2hpbmU8YnIgY2xhc3M9IiI+DQpjb21tdW5pY2F0aW9uLiBUaGlzIGlu Y2x1ZGUgQ29BUCwgQ0JPUiwgNlRJU0NILCBST0xMLCBTVUlULCBORVRDT05GIFNaVFAsPGJyIGNs YXNzPSIiPg0KVDJUUkcsIEFOSU1BJ3MgQlJTS0kgb25ib2FyZGluZyBwcm90b2NvbCwgYW5kIG1v c3QgcmVjZW50bHkgUkZDODUyMCwgdGhlPGJyIGNsYXNzPSIiPg0KTWFudWZhY3R1cmVyIFVzYWdl IERlc2NyaXB0aW9uLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBoYXMg dHJpZWQgdG8gZm9jdXMgb24gY2F0ZWdvcmllcyBvZiB3aGF0IGxpbWl0ZWQgdGhpbmdzIGNhbiBk bywgYW5kPGJyIGNsYXNzPSIiPg0KdGhpcyBoYXMgcmVzdWx0ZWQgaW4gYSBudW1iZXIgb2YgdXNl ZnVsIGRvY3VtZW50cyBmcm9tIHRoZSBMaWdodC1XZWlnaHQ8YnIgY2xhc3M9IiI+DQpJbXBsZW1l bnRhdGlvbiBHdWlkZSAoTFdJRykuIFJGQzcyMjggaXMgYSBrZXkgcHJvZHVjdCwgaGF2aW5nIHBy b3ZpZGVkPGJyIGNsYXNzPSIiPg0KdGVybWlub2xvZ3kgYW5kIHNjYWxpbmcgdW5kZXJzdGFuZGlu ZyB0byB0aGUgZW50aXJlIGluZHVzdHJ5LiBBbGwgb2YgdGhpcyBoYXM8YnIgY2xhc3M9IiI+DQpi ZWVuIGFib3V0IHNjYWxpbmcgdGhlIEludGVybmV0IHRlY2hub2xvZ2llcyB0byBzbWFsbCBkZXZp Y2VzIGFuZCBjb25zdHJhaW5lZDxiciBjbGFzcz0iIj4NCm5ldHdvcmtzLiBJbiBhZ2dyZWdhdGUs IHRoZXNlIGRldmljZXMgb24gc21hbGwgbmV0d29ya3MgcHJlc2VudCBhIHNpZ25pZmljYW50PGJy IGNsYXNzPSIiPg0Kb3BlcmF0aW9uYWwgcmlzayB0byB0aGUgSW50ZXJuZXQgYXMgYSB3aG9sZSwg YW5kIGV2ZW4gdG8gaW5kaXZpZHVhbDxiciBjbGFzcz0iIj4NCkVudGVycHJpc2UsIHNpbXBseSBk dWUgdG8gdGhlaXIgbnVtYmVycywgYW5kIGxhY2sgb2Ygb3Bwb3J0dW5pdHkgZm9yIHJlZ3VsYXI8 YnIgY2xhc3M9IiI+DQpodW1hbiBzdXBlcnZpc2lvbi4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KSW9UIGRldmljZXMgYWxyZWFkeSBleGlzdCB0b2RheSBpbiB2YXN0IG51bWJlcnMuIE1v c3QgZGV2aWNlcyB0aGF0IHBlb3BsZSBhcmU8YnIgY2xhc3M9IiI+DQpwZXJzb25hbGx5IGZhbWls aWFyIHdpdGggYXJlIGluIHRoZSBCbHVlVG9vdGggQ29ubmVjdGVkIGRldmljZXMsIG9yPGJyIGNs YXNzPSIiPg0KV2ViLUNvbm5lY3RlZCBkZXZpY2VzIHRoYXQgdXNlIFdpRmkgdG8gcmVhY2ggc2Vy dmVycyBvbiB0aGUgSW50ZXJuZXQgKCZxdW90O3RoZTxiciBjbGFzcz0iIj4NCkNsb3VkJnF1b3Q7 KS4gSW5jcmVhc2luZ2x5LCB0aGUgSUVURiB2aWV3IG9mIG1hY2hpbmUgdG8gbWFjaGluZSBjb21t dW5pY2F0aW9ucyBhcmU8YnIgY2xhc3M9IiI+DQpjb2xpbml6aW5nIG5ldyBncmVlbmZpZWxkIHNp dHVhdGlvbnMuIFRoZSBJRVRGIG5vdGlvbiBvZiBhdXRvbm9tb3VzIG5ldHdvcmtzPGJyIGNsYXNz PSIiPg0Kb2YgZGV2aWNlcyBpcyBzdGlsbCBhIG1pbm9yaXR5IHZpZXcgY29tcGFyZWQgdG8gdGhl IG1hcmtldCBJb1QgaW5kdXN0cnkgb2Y8YnIgY2xhc3M9IiI+DQpjbG91ZC1vbmx5IGNvbm5lY3Rl ZCBkZXZpY2VzLCBidXQgdGhlIHRyYW5zaXRpb24gaXMgb2NjdXJpbmcuIDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClJGQzg1MjAgd2FzIGNyZWF0ZWQgdG8gYnJpZGdlIHRoZSBnYXAgYmV0 d2VlbiBkZXZpY2VzIHdob2xseSBjb250cm9sbGVkIGJ5IGE8YnIgY2xhc3M9IiI+DQpsb2NhbCBv cGVyYXRvciAoc3VjaCBhcyBFbnRlcnByaXNlIElUKSwgYW5kIGRldmljZXMgd2hpY2ggY2FuIG5v dCBhc3N1bWUgYW55PGJyIGNsYXNzPSIiPg0KaW5mcmFzdHJ1Y3R1cmUgYXQgYWxsLCBhbmQgbXVz dCByZWx5IGVudGlyZWx5IG9uIGNsb3VkIGNvbW11bmljYXRpb25zIGZvcjxiciBjbGFzcz0iIj4N CmNvbW1hbmQgYW5kIGNvbnRyb2wuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMg d29ya2luZyBncm91cCBjb25jZXJucyBpdHNlbGYgd2l0aCBPcGVyYXRpb25hbCBTZWN1cml0eSBv ZiBJb1Qgc3lzdGVtcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGluY2x1ZGVz OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiogZmFjdG9yeSBwcm92aXNpb25pbmcgb2Yg ZGV2aWNlczxiciBjbGFzcz0iIj4NCiogb25ib2FyZGluZyBvZiBkZXZpY2VzPGJyIGNsYXNzPSIi Pg0KKiBhY2Nlc3MgY29udHJvbCBvZiBkZXZpY2VzIHRvIG5ldHdvcmsgcmVzb3VyY2VzPGJyIGNs YXNzPSIiPg0KKiBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9mIGRldmljZXM8YnIgY2xhc3M9IiI+ DQoqIGFzc2V0IG1hbmFnZW1lbnQgb2YgZGV2aWNlcywgYXMgaXQgcGVydGFpbnMgdG8gc29mdHdh cmUvZmlybXdhcmUgdmVyc2lvbnM8YnIgY2xhc3M9IiI+DQoqIGlzb2xhdGlvbi9xdWFyYW50aW5l IG9mIGRldmljZXM8YnIgY2xhc3M9IiI+DQoqIHJlbWVkaWF0aW9uIG9mIGJyb2tlbiBkZXZpY2Vz PGJyIGNsYXNzPSIiPg0KKiBlbmQgb2YgbGlmZSBtYW5hZ2VtZW50IG9mIGRldmljZXM8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgV0cgaXMgY2hhcnRlcmVkIGV4cGxpY2l0ZWx5IHRv IHdvcmsgb24gTVVEIChSRkM4NTIwKSBhbmQgZXh0ZW5zaW9ucyB0byBpdC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGUgV0cgaXMgY2hhcnRlcmVkIHRvIHdvcmsgb24gb25ib2FyZGlu ZyBwcm90b2NvbHMsIHNwZWNpZmljYWxseSBpbmNsdWRpbmc8YnIgY2xhc3M9IiI+DQpkZXJpdmF0 aWVzIG9mIEJSU0tJIChSRkMtdGJkKSwgYnV0IG5vdCBsaW1pdGVkIHRvIGp1c3QgdGhhdCBwcm90 b2NvbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgV0cgaXMgbm90IGV4cGVjdGVk IHRvIHBpY2sgYSB3aW5uZXIsIGFuZCBpcyBlbmNvdXJhZ2VkIHRvIHdvcmsgb24gYTxiciBjbGFz cz0iIj4NCm11bHRpdHVkZSBvZiB1c2UtY2FzZSBzcGVjaWZpYyBwcm90b2NvbHM6IGJldHRlciB0 byBnZXQgb25lIHVzZSBjYXNlIHJpZ2h0LDxiciBjbGFzcz0iIj4NCnRoYW4gdG8gYmUgdG9vLWNv bXBsZXggamFjayBvZiBhbGwgdHJhZGVzLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGUgV0cgaXMgZXhwZWN0ZWQgdG8gYXJ0aWN1bGF0ZSBjbGVhciBhcHBsaWNhYmlsaXR5IHN0YXRl bWVudHMgZm9yIGVhY2g8YnIgY2xhc3M9IiI+DQpwcm90b2NvbC4gVGhlIFdHIGlzIGV4cGVjdGVk IHRvIHByb2R1Y2UgY29uY2lzZSBSb2FkbWFwIGRvY3VtZW50cyB0aGF0PGJyIGNsYXNzPSIiPg0K ZXhwbGFpbiBob3cgYSB2YXJpZXR5IG9mIElFVEYgKGFuZCBvdGhlcikgcHJvdG9jb2xzIGNhbiB3 b3JrIHRvZ2V0aGVyIHRvPGJyIGNsYXNzPSIiPg0Kc2F0aXNmeSB0aGUgT3BlcmF0aW9uYWwgbmVl ZHMgb2Ygc3BlY2lmaWMgSW9UIGFyZWFzLiBUaGVzZSByb2FkbWFwIGRvY3VtZW50czxiciBjbGFz cz0iIj4NCm5lZWRu4oCZdCByZXN1bHQgaW4gUkZDcy4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KTmVpdGhlciB0aGUgV0cgbm9yIHRoZSBJRVRGIGhhcyBleGNsdXNpdml0eSBoZXJlLCBh bmQgYW4gaWRlYWwgZG9jdW1lbnQgd291bGQ8YnIgY2xhc3M9IiI+DQpiZSBvbmUgdGhhdCB0aGUg V0cgaGVscHMgdG8gc3RhcnQsIGJ1dCBhIHNwZWNpZmljIGluZHVzdHJ5IGFsbGlhbmNlIGJlY29t ZXM8YnIgY2xhc3M9IiI+DQp0aGUgbGVhZCBlZGl0b3IgZm9yLiA8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGVyZSB3aWxsIGJlIGNvb3JkaW5hdGlvbiB3aXRoIG1hbnkgb3RoZXIgV0dz IGJleW9uZCB0aGUgbGlzdCBhYm92ZSwgYW5kPGJyIGNsYXNzPSIiPg0KdGhpcyBXRyBtYXkgYWNj ZXB0IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHdvcmsgZnJvbSBvdGhlciBXR3MgYWJvdXQgc3Bl Y2lmaWM8YnIgY2xhc3M9IiI+DQp3YXlzIHRvIGRlcGxveSB0aGVpciBwcm90b2NvbHMuIDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBXRyB3aWxsIG9wZXJhdGUgdGhyb3VnaCBhIHNl cmllcyBvZiB2aXJ0dWFsIGludGVyaW0gbWVldGluZ3MuIFRoaXMgaXM8YnIgY2xhc3M9IiI+DQpk cml2ZW4gYnkgYSBuZWVkIHRvIGludGVyYWN0IHJlZ3VsYXJseSB3aXRoIG90aGVyIGluZHVzdHJ5 IGdyb3VvcHMsIGFuZCBkdWU8YnIgY2xhc3M9IiI+DQp0byB0aGUgdmFyaWV0eSBvZiB0b3BpY3Mg d2hpY2ggd2lsbCBub3QgYWx3YXlzIGJlIGFibGUgdG8gZ2V0IHF1b3J1bSBhcyBhPGJyIGNsYXNz PSIiPg0KY29tbWl0dGVlIG9mIHRoZSB3aG9sZS4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0Ke3VudXN1YWwsIG1heWJlIG5vdCBjaGFydGVyIGFwcHJvcHJpYXRlLCBidXQgcmF0aGVyIHNh YWctbGlrZX08YnIgY2xhc3M9IiI+DQpEdXJpbmcgaW4tcGVyc29uIG1lZXRpbmdzLCB0aGUgV0cg d2lsbCBkZWFsIHdpdGggdHlwaWNhbCBzdGF0dXMgYW5kIGRvY3VtZW50PGJyIGNsYXNzPSIiPg0K cHJvZ3Jlc3MgaXNzdWVzIGR1cmluZyBvbmUgaG91ciAob3IgbGVzcykgb2YgdGhlIHRpbWUsIGFu ZCBkdXJpbmcgYW5vdGhlcjxiciBjbGFzcz0iIj4NCmhvdXIsIHdpbGwgYmUgb3BlbiB0byBzbGlk ZXdhcmUgcHJlc2VudGF0aW9ucyBhbmQgdHV0b3JpYWxzIG9uIGN1cnJlbnQgSUVURjxiciBjbGFz cz0iIj4NCm9yIG90aGVyLVNETyBJb1QgZWZmb3J0cy4gVGhlIGdvYWwgb2YgdGhlc2UgcHJlc2Vu dGF0aW9ucyBpcyB0byBxdWlja2x5PGJyIGNsYXNzPSIiPg0KY29tbXVuaWNhdGUgY3VycmVudCBJ b1Qgc3lzdGVtcyBzdGF0ZSB0byB0aGUgcmVzdCBvZiB0aGUgSUVURi48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpJdCBpcyBhY2tub3dsZWRnZWQgdGhhdCBwYXJ0IG9mIHRoZSB2YWx1ZSBp cyBpbiBZb3VUdWJlIGNvbnRlbnQsIGFuZCBzb21lPGJyIGNsYXNzPSIiPg0KY29udGVudCBzaG91 bGQgYmUgZG9uZSBhdCBJQUIgdGVjaCBwbGVuYXJpZXMgcmF0aGVyIHRoYW4gYXQgdGhlIFdHLiA8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgaW5pdGlhbCBzZXQgb2Ygd29yayBpdGVt cyBpcyBpbmNsdWRlZCBiZWxvdyBhcyBtaWxlc3RvbmVzLCB3aGljaCBvbmx5PGJyIGNsYXNzPSIi Pg0KcmVxdWlyZSBBRCBhcHByb3ZhbC4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTWls ZXN0b25lczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiogYWRvcHQgdGhlIGNvbnN0cmFp bmVkLXZvdWNoZXIvY29uc3RyYWluZWQtQlJTS0kgd29yayBmcm9tIEFOSU1BLjxiciBjbGFzcz0i Ij4NCiogYWRvcHQgdGhlIGR0c2VjdXJpdHktemVyby10b3VjaCB3b3JrIGZyb20gNnRpc2NoLCB3 aGljaCBjYW4gbm90IGZpbmlzaCBiZWZvcmUgYSBMQUtFIGZpbmlzaGVzLjxiciBjbGFzcz0iIj4N CiogY3JlYXRlIGEgbGlzdCBvZiBhIHNlcmllcyBvZiBNVUQgZXh0ZW5zaW9ucywgYW5kIHJldmlz ZSB0aGlzIG1pbGVzdG9uZTxiciBjbGFzcz0iIj4NCiogYWRvcHQgYSBjbG91ZC1sZXNzIChNQVNB LWxlc3MsIEFBQS1sZXNzKSBvbmJvYXJkaW5nIG1lY2hhbmlzbSAocG9zc2libHkgYSB2ZXJzaW9u IG9mIEVBUC1OT09CKSwgdGhhdCBjYW4gYmUgdXNlZCBhdCB0aGUgcmV0YWlsIGxldmVsLjxiciBj bGFzcz0iIj4NCiogbmVnb3RpYXRlIHdpdGggRU1VIFdHIG9uIGhvdyB0byBwcm9jZWVkIHdpdGgg VEVBUC1CUlNLSSwgYW5kIHJldmlzZSB0aGlzIG1pbGVzdG9uZS48YnIgY2xhc3M9IiI+DQoqIGFk b3B0IGEgY2xvdWQtZHJpdmVuIG9uYm9hcmRpbmcgbWVjaGFuaXNtIHRoYXQgY2FuIGJlIHVzZWQg aW4gY29tcGxldGVseSBvZmZsaW5lIHNpdHVhdGlvbnMgd2l0aG91dCByZXF1aXJpbmcgcmVuZXdh bHMgKHBlcmhhcHMgcmV2aXNpbmcgUkZDODM2NikuPGJyIGNsYXNzPSIiPg0KLi4uLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCi0tIDxiciBjbGFzcz0iIj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1jciYjNDM7SUVURkBzYW5kZWxtYW4uY2EiIGNsYXNzPSIiIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSI+bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4g U29mdHdhcmUgV29ya3M8YnIgY2xhc3M9IiI+DQotPSBJUHY2IElvVCBjb25zdWx0aW5nID0tPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K LS0gPGJyIGNsYXNzPSIiPg0KSW90LW9uYm9hcmRpbmcgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIi Pg0KPGEgaHJlZj0ibWFpbHRvOklvdC1vbmJvYXJkaW5nQGlldGYub3JnIiBjbGFzcz0iIiBtb3ot ZG8tbm90LXNlbmQ9InRydWUiPklvdC1vbmJvYXJkaW5nQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaW90LW9uYm9hcmRpbmciPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaW90LW9uYm9hcmRpbmc8L2E+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJyPg0K PGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4gPC9ibG9j a3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_bb757b7bdffc94944ae0a709d30445dfericssoncom_-- From nobody Thu Sep 12 08:08:42 2019 Return-Path: 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 DCDBC120271; Wed, 11 Sep 2019 13:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mvUyufJUYYu6; Wed, 11 Sep 2019 13:35:37 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45058120803; Wed, 11 Sep 2019 13:35:37 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id n4so12134277pgv.2; Wed, 11 Sep 2019 13:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=zKWZiE5Hun4lW7/yaa48cCoieFRsuAqBeZyImJJraNs=; b=XuqXKL9rYIh5hqARq3Yq7p+wC8qsJZ1UCEvVZq4kRnuXl40levshLIuIInWNZbs/bO pq+hnd+8Y5QHB0qWgVPI2ZDIZQgsdPVq53rXZezQscwhJzbVEAeK6Wue6moiFkjEgCP2 MzQBtReTizVIVzdDJQOoBR1PwJZjR00sngtwxKQuefFSHSBriW+Q4HlKlgTzLpBQfQ8U pJOQCk90ZLneuUaGp4QIJGvIcXAaVUGF6b2U8HXU0PLnFwhcWQfHGxZO/c81WieyYDV4 FNhG6dC1gvRHM73lG3AN8eCu94KRt+EFYuX564sR8jnH0VQdKi3XX0pU3NZXboIergmU Z4IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zKWZiE5Hun4lW7/yaa48cCoieFRsuAqBeZyImJJraNs=; b=fxZPLsAHZcdDUMWV50k474NqybBcO/Ntag/1bAInGNRfDB1qEil6oj/BXNcOQ80VPc RBrfpBGR6itHBacsbMVUWzsjm76cVgMr+Nu/cFih3WoZrXaDyeHDFTy+NRxu609oc83j YEaJZQc6KEr0PyNS/iQ7g4S/XwLLvQsBvOHbNgAbZ/LJ14AQz6eb/tRg7w0edjp5jvo9 nHq/zGp3GNx6h1fVRDFj6D3gGKPv46nu7P58OlzjwDx+i+F5dhUA5l2yNEOT1vBX9N3t 0hnEGfMn2l6JhF3wNNc5wmZ1ThkKLNKz2lNY+HfOhQW9GBfvWJEOsak9YbG7r/OP6up/ hlJw== X-Gm-Message-State: APjAAAUeYIJKSRLRGsWbN7Cnx0/kHJ+b4abo19MyjQE/R+36uXe5rm8j alo0MxNOJZSFHg/pZ5BTSydIyh0N X-Google-Smtp-Source: APXvYqw27NO1rh6fegtqL/P91o3zU+u1vMiKqcBvCdkCeih4AO0OFws3Pg+nu/KLfqXTty99VgTbfg== X-Received: by 2002:aa7:8d12:: with SMTP id j18mr45484804pfe.33.1568234136412; Wed, 11 Sep 2019 13:35:36 -0700 (PDT) Received: from [192.168.178.30] (82.206.69.111.dynamic.snap.net.nz. [111.69.206.82]) by smtp.gmail.com with ESMTPSA id j23sm8023356pfn.75.2019.09.11.13.35.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2019 13:35:35 -0700 (PDT) To: Mohit Sethi M , Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" References: <19176.1567583108@dooku.sandelman.ca> <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> From: Brian E Carpenter Message-ID: <8bc45173-4a00-8a00-35e9-1cad51c559ac@gmail.com> Date: Thu, 12 Sep 2019 08:35:32 +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: <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 12 Sep 2019 08:08:25 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 20:35:40 -0000 Hi Mohit, On 12-Sep-19 07:21, Mohit Sethi M wrote: > Hi Michael, >=20 > I wonder why a new working group is needed and why this work cannot be = pursued in some of the existing working groups? >=20 > I suppose ANIMA was recently re-chartered (and can be re-chartered agai= n).=20 We've been very insistent that ANIMA is scoped for professionally managed= networks. That is not, IMHO, a reasonable restriction for IoT; so the AN= IMA scope is narrower. Also, ANIMA is scoped for autonomic management, wi= th bootstrap and security being only part of the requirements; in that se= nse, the ANIMA scope is broader. > EMU is currently going over the re-charter text.=20 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 eco= system. The "Thinking through onboarding" thread scopes the wider problem= nicely. Regards Brian >=20 > Also, you write: >=20 >> adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possibl= y 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 a= ssociating it with a user account). The fact that it provides network-acc= ess credentials is a bonus. Please have a look at slides 3-10 here: https= ://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-nimb= le-out-of-band-authentication-for-eap-eap-noob-draft-aura-eap-noob-04-01 >=20 > You clearly see a AAA server in the figures. So calling it AAA-less doe= sn't make sense. >=20 > --Mohit >=20 > 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 em= ail. >> >> >> 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 wo= rking >> on a wide variety of protocols for use by machine to machine >> communication. This include CoAP, CBOR, 6TISCH, ROLL, SUIT, NETCONF SZ= TP, >> T2TRG, ANIMA's BRSKI onboarding protocol, and most recently RFC8520, t= he >> Manufacturer Usage Description.=20 >> >> The IETF has tried to focus on categories of what limited things can d= o, and >> this has resulted in a number of useful documents from the Light-Weigh= t >> Implementation Guide (LWIG). RFC7228 is a key product, having provided= >> terminology and scaling understanding to the entire industry. All of t= his has >> been about scaling the Internet technologies to small devices and cons= trained >> networks. In aggregate, these devices on small networks present a sign= ificant >> operational risk to the Internet as a whole, and even to individual >> Enterprise, simply due to their numbers, and lack of opportunity for r= egular >> human supervision.=20 >> >> IoT devices already exist today in vast numbers. Most devices that peo= ple 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 communicati= ons are >> colinizing new greenfield situations. The IETF notion of autonomous ne= tworks >> of devices is still a minority view compared to the market IoT industr= y of >> cloud-only connected devices, but the transition is occuring.=20 >> >> RFC8520 was created to bridge the gap between devices wholly controlle= d by a >> local operator (such as Enterprise IT), and devices which can not assu= me any >> infrastructure at all, and must rely entirely on cloud communications = for >> command and control.=20 >> >> This working group concerns itself with Operational Security of IoT sy= stems. >> >> 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 ver= sions >> * 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 extension= s to it. >> >> The WG is chartered to work on onboarding protocols, specifically incl= uding >> 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 r= ight, >> than to be too-complex jack of all trades.=20 >> >> The WG is expected to articulate clear applicability statements for ea= ch >> 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 doc= uments >> needn=E2=80=99t result in RFCs.=20 >> >> Neither the WG nor the IETF has exclusivity here, and an ideal documen= t would >> be one that the WG helps to start, but a specific industry alliance be= comes >> the lead editor for.=20 >> >> There will be coordination with many other WGs beyond the list above, = and >> this WG may accept applicability statement work from other WGs about s= pecific >> ways to deploy their protocols.=20 >> >> The WG will operate through a series of virtual interim meetings. This= is >> driven by a need to interact regularly with other industry grouops, an= d due >> to the variety of topics which will not always be able to get quorum a= s a >> committee of the whole.=20 >> >> {unusual, maybe not charter appropriate, but rather saag-like} >> During in-person meetings, the WG will deal with typical status and do= cument >> progress issues during one hour (or less) of the time, and during anot= her >> hour, will be open to slideware presentations and tutorials on current= IETF >> or other-SDO IoT efforts. The goal of these presentations is to quickl= y >> communicate current IoT systems state to the rest of the IETF. >> >> It is acknowledged that part of the value is in YouTube content, and s= ome >> content should be done at IAB tech plenaries rather than at the WG.=20 >> >> The initial set of work items is included below as milestones, which o= nly >> require AD approval.=20 >> >> Milestones >> >> * adopt the constrained-voucher/constrained-BRSKI work from ANIMA. >> * adopt the dtsecurity-zero-touch work from 6tisch, which can not fini= sh before a LAKE finishes. >> * create a list of a series of MUD extensions, and revise this milesto= ne >> * adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possi= bly 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 comple= tely offline situations without requiring renewals (perhaps revising RFC8= 366). >> .... >> >> >> >> >> >=20 From nobody Thu Sep 12 08:08:50 2019 Return-Path: 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 3FFEF1207FF; Wed, 11 Sep 2019 13:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zMzBbWWlsXz8; Wed, 11 Sep 2019 13:57:54 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257E6120289; Wed, 11 Sep 2019 13:57:54 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id d10so12146789pgo.5; Wed, 11 Sep 2019 13:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [192.168.178.30] (82.206.69.111.dynamic.snap.net.nz. [111.69.206.82]) by smtp.gmail.com with ESMTPSA id j7sm23048011pfi.96.2019.09.11.13.57.49 (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 , "mud@ietf.org" , "iot-onboarding@ietf.org" References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.com> 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: <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 12 Sep 2019 08:08:25 -0700 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 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 auto= nomic 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 https://tools.ietf.org/html/draft-ietf-anima-refere= nce-model). BRSKI may prove to have more generality than that, but it was= n't an explicit goal. We were always aware of SZTP while BRSKI was developed, and vice versa, b= ut it wasn't a competition. Regards Brian Carpenter On 12-Sep-19 08:30, Kent Watsen wrote: >=20 > Hi Mohit, >=20 >=20 >> Could you explain the high-level differences between BRSKI and SZTP fo= r those like me who are not extremely familiar.=C2=A0 >> >> I know there are probably many differences. For example, I see that th= e SZTP spec says that devices can receive initial bootstrap information o= ver DNS or from a bootstrap server. >> >> What I am trying to understand is what does a device start from (share= d-secret/ephemeral key pair/manufacturer certificate), and what does it e= nd with? Do we need both SZTP and BRSKI? >> > Top of mind. >=20 >=20 > Preconditions: > - SZTP: secure device identity certificate SHOULD (e.g., IDevID RECOMME= NDED), alternate credentials possible. =C2=A0Optional list of TA certs fo= r validating SZTP servers. =C2=A0Optional list of TA certs for validating= vouchers. > - BRSKI: IDevID MUST. =C2=A0List of TA certs for validating vouchers MU= ST. >=20 > Normal Operations: > - SZTP: many modes here, some doesn't require networking. =C2=A0Voucher= s only needed when TLS can't be used or trusted. =C2=A0 Vouchers, when us= ed, are primarily long-lived, but MAY be ephemeral (e.g., nonced). =C2=A0= Primarily with strong ownership verification, but weaker forms are possib= le. > - BRSKI: singular mode (pledge looks for a Registrar). =C2=A0Vouchers a= re always used and are primarily conceived to be ephemeral (nonced) with = a MASA that maintains a log; long-lived Vouchers and strong ownership-ver= ification are possible. >=20 > Postconditions: > - SZTP: a "payload" that could be as small as a script or as large as i= nstructions for updating the OS image + setting an initial configuration.= > - BRSKI: a domain certificate. =C2=A0Additional mechanisms needed to ge= t device into a managed state (this is what some of the other ANIMA draft= s are for) >=20 >=20 > I think I got the BRSKI parts right, but hope folks will chime in if an= ything is misrepresented or underrepresented. >=20 > Kent >=20 From nobody Thu Sep 12 08:08:58 2019 Return-Path: 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 6E444120833; Thu, 12 Sep 2019 04:05:12 -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 mMx2fCkX8QAx; Thu, 12 Sep 2019 04:05:10 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50087.outbound.protection.outlook.com [40.107.5.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A189A120845; Thu, 12 Sep 2019 04:05:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VZv6itaQqbfI10trWOgs/oaJMIXvPDjJtHw4MS88i63dCWdwUrJN9dwzgNLqLjVzoZctqwV5Almw1w0BDBSL71AGe2no3hQI6+g3QDURPPBkIRitSoxF9Cz0L+EdeB0+YmyShM24tAVUzmGfxbkx+R9J34gYHEOaD5FTObFbZW4z/OP1UqvyVjq1zFEZGKETnH+Dgy1RVHUlRPDKp7C0zjM6eA7XpXRqcfJTrOjPCVxqA4q7m0xAPQVO9OY1AqqTZw/yTdH5t+NzM3ggLYeBGfokcbnlrUyYvHSUBArOaMZpffbtnC592C0lQxIcTvENbF0ZFosxziO0aDetmrqpuA== 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=eB2gmmbmo8x39+D1pgUhdQt6WfLMQI3Ngt8x3IJBz80=; b=lKObBrZHlZdhCMOqUxXpsr+GBgGnyNMZbCXBPhUK9oHSIgPAznJ0c5x/RgunenfYku8ugou6ptye7Vq/3HPbrJL1mHsy5F+NcrgSDXfFGlJMKHt7o2TixXDZvj8FaWxVJxNuhrEj+9QnaaXU3JCH3bKTeJyWL6JSLrOnuo12cPx/BT6e2ueAXSrFYocTSHVfGuKotG2h+Y+wJH8xNNRCO+ASa5R3loSKKi+eaCBGblHl91degWjoeLcIwWJIys6pGfhA+mJoB/2XScR2+qepakPFtRgLKP7RVJmiOE34HeW91UlEAnM17xETwVk5b5YlUxv/rY2+hG4W/rqaZ3J8Fg== 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=eB2gmmbmo8x39+D1pgUhdQt6WfLMQI3Ngt8x3IJBz80=; b=lUIYY1p62S5IjhFYbFNUILOWP5r0BOa7xG4KNFGpxfyziE3ra1Ee3i07YPIW9eanvQfRAchxC4DUHIt6TaBVQWloyvD3cUjrhniNDdCs77c284PKWXEd36LjxpFPdoqrbK32R7ODtezL8VqBWfJlAltIPEC0rUx2tbaxI5jnMQw= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2633.eurprd07.prod.outlook.com (10.168.185.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.6; Thu, 12 Sep 2019 11:05:06 +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.2263.016; Thu, 12 Sep 2019 11:05:06 +0000 From: Mohit Sethi M To: Kent Watsen , Mohit Sethi M CC: Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG Thread-Index: AQHVaNbcpd2ivcpAw0yCVRFO+FMgJ6cm7cUAgAD0aoA= Date: Thu, 12 Sep 2019 11:05:06 +0000 Message-ID: <7143e57b-d3bd-8cd6-3fce-aba6dee56cfd@ericsson.com> References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.com> <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.com> In-Reply-To: <0100016d2205079e-f7bb82bf-7e5b-4e61-a938-bc49ac1c5f44-000000@email.amazonses.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: [87.93.24.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 612e1615-09fc-45bd-70f3-08d7377111f3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2633; x-ms-traffictypediagnostic: HE1PR0701MB2633:|HE1PR0701MB2633: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(396003)(136003)(376002)(199004)(189003)(8936002)(36756003)(99286004)(6512007)(478600001)(102836004)(6246003)(6506007)(86362001)(186003)(66556008)(31686004)(53546011)(66476007)(66446008)(64756008)(14454004)(66946007)(76176011)(26005)(71190400001)(71200400001)(31696002)(53936002)(256004)(14444005)(25786009)(6436002)(2616005)(66066001)(476003)(6486002)(54896002)(76116006)(316002)(65956001)(65806001)(4326008)(11346002)(3846002)(446003)(8676002)(110136005)(6116002)(81166006)(7736002)(81156014)(54906003)(15650500001)(2906002)(486006)(5660300002)(58126008)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2633; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: jBC8cEVaHhmzBYF2+Bfnzaz/yEN7HfciRfYVUCCE1n1hZ+gYygVLFpq/+1qskSx8AVrj5zVVC20WUskfLaLshVf/v2PHCmTBfzo4N4Yqv02Y9C2/MfrZEC7t4TS867UL4u3ATB6guGh/9aAAqRtMmxqAXhLuW3yuU8IYPybl8BeApAPeu6X9g0hSIUw21W/BXm1n0pu9Py1y4U7X6whHAyndHNCAYuYx/LzqkBypuJwM6c/lK8OJZZnNxs5gjoodrTfd8fE9rcY4LAbd5AOzAdfN6vd2bZEX5ptYeEgbKpjzDqGzqeYbeF0BxsfzCkGd+JAr/GJS73F2VSv5b5VAmgdBuaeQBTwnSbUNbgX+AV6S1FKbvL4P2w86K9QDV/KMBR8wCmfYpQAQ8ncAWuSmCymtQcvG1NEhIOgQtnWGqmg= Content-Type: multipart/alternative; boundary="_000_7143e57bd3bd8cd63fceaba6dee56cfdericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 612e1615-09fc-45bd-70f3-08d7377111f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 11:05:06.6064 (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: Txv/PLwVrBKFTEwrj9jb4PoM7pxo0Q1g3HaGm8iQ8gGJnd4/46jmkGt/g00wlzMn2OcqOYZVazXYsy8r+vL75NN+wvYYUDFewg2QTSgw1Dk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2633 Archived-At: X-Mailman-Approved-At: Thu, 12 Sep 2019 08:08:25 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 11:05:13 -0000 --_000_7143e57bd3bd8cd63fceaba6dee56cfdericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kent, Thanks for this. It is very helpful. I may still need some hand-holding to = understand all the aspects. There is quite a lot to digest here. You mention that SZTP can give a payload to the device that could be a scri= pt or more complex instructions. Can this payload be a certificate? I understand that people will have different opinions about their own work = and it can be hard to compare protocols. But are there use-cases that are a= ddressed by BRSKI but not by SZTP? Is it the case that BRSKI addresses some= scenarios more efficiently? --Mohit On 9/11/19 11:30 PM, Kent Watsen wrote: Hi Mohit, Could you explain the high-level differences between BRSKI and SZTP for tho= se like me who are not extremely familiar. I know there are probably many differences. For example, I see that the SZT= P 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-sec= ret/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 validatin= g 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 ne= eded when TLS can't be used or trusted. Vouchers, when used, are primaril= y long-lived, but MAY be ephemeral (e.g., nonced). Primarily with strong o= wnership 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 instr= uctions 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 anythi= ng is misrepresented or underrepresented. Kent --_000_7143e57bd3bd8cd63fceaba6dee56cfdericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Kent,

Thanks for this. It is very helpful. I may still need some hand-holding = to understand all the aspects. There is quite a lot to digest here.

You mention that SZTP can give a payload to the device that could be a s= cript or more complex instructions. Can this payload be a certificate?

I understand that people will have different opinions about their own wo= rk and it can be hard to compare protocols. But are there use-cases that ar= e addressed by BRSKI but not by SZTP? Is it the case that BRSKI addresses s= ome scenarios more efficiently?

--Mohit

On 9/11/19 11:30 PM, 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 se= e that the SZTP spec says that devices can receive initial bootstrap inform= ation over DNS or from a bootstrap server.

What I am trying to understand is what does a device start fr= om (shared-secret/ephemeral key pair/manufacturer certificate), and what do= es it end with? Do we need both SZTP and BRSKI?

Top of mind.


Preconditions:
- SZTP: secure device identity certificate SHOULD (e.g., IDevID RECOMM= ENDED), alternate credentials possible.  Optional list of TA certs for= validating SZTP servers.  Optional list of TA certs for validating vo= uchers.
- BRSKI: IDevID MUST.  List of TA certs for validating vouchers M= UST.

Normal Operations:
- SZTP: many modes here, some doesn't require networking.  Vouche= rs only needed when TLS can't be used or trusted.   Vouchers, when use= d, are primarily long-lived, but MAY be ephemeral (e.g., nonced).  Pri= marily 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-verifi= cation 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 c= onfiguration.
- BRSKI: a domain certificate.  Additional mechanisms needed to g= et 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 a= nything is misrepresented or underrepresented.

Kent

--_000_7143e57bd3bd8cd63fceaba6dee56cfdericssoncom_-- From nobody Thu Sep 12 08:09:05 2019 Return-Path: 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 DA8661200CD; Thu, 12 Sep 2019 04:33:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MqkUlRE-5Xtn; Thu, 12 Sep 2019 04:33:38 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150089.outbound.protection.outlook.com [40.107.15.89]) (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 D8E961200CC; Thu, 12 Sep 2019 04:33:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X/Ad/iUIBv9Y5mYt379APgZRzXrjitXKo40UCnGEMEblRDV6VMChcdCev5k1GqaakKn16buxhf9Zm1jCRMKls43jvHKbBlFbQpZAvT4jyx+nzeQdzqRPR6VER9+I9nTTOskEevvMxT+kepn7wGs3mWqhyr/4EM7pJ7zlng6C/Vgza5OgyC1UrnzcAeDefd87Tr8kpluGXDrVp0xOjBYSjlFFD8zPOslBVcbuLqw20RdxRvN4EMqN/O0U8p4gqWbsHvYEeVI/nmVTPTEHXWljz/fQ6hjY0ucczjszNFmtFpGZXiXNJ3yiQK/k6b+np1g2G/ThrlzAPrhyRyVz+IaCbA== 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=NqNJHCxJwh2hNwA8IfdycvbqrsJgy77i6pfyf4EvwDM=; b=F6dUac/vApqI6AsNgmixwAG7qmkoBAK09Eyv0x10mB0zFrSbV0aZhGOtC4WPQ//+ZRObKrdOxzbps8BiAfqDQ6vikaB5PPVjTC+ktUriU3U2ISLJLL2HTpTq7+B/YKgy0Jso1KD6XvXPYHumqX1ntUyFlQjlSD88EzeVQors2o0DgdsX7aB1I9Ms4lU9mxHapGzHmcX/9Rq0/gfSVITUhmU68eJagPK6Pa7ftSLll+RpgG4ZdRNo8bKPB305fNDnaHZho9/G+mbyTrX5/qle9u8Lyx3dSzkq/bOX84V4is78GTxd3SR2IuyuoP5SYvdNPQe4eVLivgx5dfAmV7a27w== 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=NqNJHCxJwh2hNwA8IfdycvbqrsJgy77i6pfyf4EvwDM=; b=ZZcuG7iJNMH2JgGUpfv85jJef0fqfj4FPjBD7Tt3M+roeVbQcLhafFuawU+MN7o9cPbBc/T+vxfJPbBG/jZLqllDM9lMgw4uPbedp4qAyRcMNvEWMFIKm/MgQ8t2c1Tctcz29+9eq0T8cyromn+S83pNaWBObUXLHROh1cj1WU4= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2282.eurprd07.prod.outlook.com (10.168.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.7; Thu, 12 Sep 2019 11:33:35 +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.2263.016; Thu, 12 Sep 2019 11:33:35 +0000 From: Mohit Sethi M To: Brian E Carpenter , Mohit Sethi M , Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG Thread-Index: AQHVaNYdpd2ivcpAw0yCVRFO+FMgJ6cm7z0AgAD66AA= Date: Thu, 12 Sep 2019 11:33:34 +0000 Message-ID: <1e9357be-a384-8663-3142-1b2dfe0a376f@ericsson.com> References: <19176.1567583108@dooku.sandelman.ca> <30e9de90-68b0-7b45-a94e-165bb6fabbb5@ericsson.com> <8bc45173-4a00-8a00-35e9-1cad51c559ac@gmail.com> In-Reply-To: <8bc45173-4a00-8a00-35e9-1cad51c559ac@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: [87.93.24.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98ea10b3-576a-4bd9-0ca0-08d737750c31 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2282; x-ms-traffictypediagnostic: HE1PR0701MB2282:|HE1PR0701MB2282: x-ms-exchange-purlcount: 2 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(366004)(39860400002)(199004)(189003)(25786009)(229853002)(6486002)(6436002)(15650500001)(3846002)(6116002)(6246003)(66066001)(65806001)(6506007)(76176011)(26005)(65956001)(66446008)(64756008)(186003)(66556008)(66476007)(76116006)(66946007)(53936002)(2501003)(446003)(11346002)(256004)(31686004)(6512007)(71190400001)(66574012)(6306002)(71200400001)(99286004)(486006)(14454004)(102836004)(53546011)(2616005)(8676002)(305945005)(58126008)(36756003)(476003)(316002)(966005)(8936002)(2906002)(81166006)(81156014)(14444005)(86362001)(5660300002)(110136005)(478600001)(7736002)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2282; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: iGc5nVuNBMdPldPF11uyhTVSXohPluZ8WWepcKwEiZMvP7Qxj+Fw7bx5OXmyxAL8Ou7yExBykoFHGE9viKdWln+PxLVOpfuYYvepS+9hX7hcttV2XdKgVGkKyKFsH5PHmf4tYhJkQhzkX5aPV7ujtlL2GxnoUUwfSRyKXM8kKdAPMNLozhRGAutzVw/NmEmZ0yNG5QCUHeNTZKw31bmUzrFUxzPe+LvXVoCTitq4UFxuemtYZrqkz7m55EBCxqW38vJCbZXhUIdZ8E3Jf3Ax5keXD7sAK2iKljgkwINryZvCo0Sn9cKIZlUptSiBscqTOi9bOpxWZ69wkz7a9kfBIOEUyfbCOWzpGjy7hyPW15Of1QiZJRkcMR0TgYp1/1HVyiJ/IRtuMiVPzlPsp327q/ac/SJnbrJcnD672J5/LgE= Content-Type: text/plain; charset="utf-8" Content-ID: <358196F431969747B497BCFF47C6340E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98ea10b3-576a-4bd9-0ca0-08d737750c31 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 11:33:35.0137 (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: NN8Slk/MQRkWypufuGWJO6bMa9Cx+OLVsx2i1uqsrgLEIuNYYHlqC5C15mHxTxoil78eomtAmyj1vweKJT5T259ngY9MfratkMyC4yzmkQQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2282 Archived-At: X-Mailman-Approved-At: Thu, 12 Sep 2019 08:08:25 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 11:33:42 -0000 SGkgQnJpYW4sDQoNCklFVEYgaXMgaW4gdGhlIGJ1c2luZXNzIG9mIGJ1aWxkaW5nIHRvb2xzIChp LmUuIG9wZW4gc3BlY2lmaWNhdGlvbnMgd2l0aCANCnJ1bm5pbmcgY29kZSkgZm9yIGRldmVsb3Bl cnMuIEFuZCB0aGVzZSB0b29scyBhcmUgYmVzdCBidWlsdCBpbiB3b3JraW5nIA0KZ3JvdXBzIHdo aWNoIGhhdmUgdGhlIGV4cGVydGlzZSBvbiB0aGVtLiBNb3N0IHBlb3BsZSBvdXRzaWRlIHRoZSBB TklNQSANCmNvbW11bml0eSB3b3VsZCBub3Qga25vdyB3aGF0IGlzIGEgTUFTQS4gU2ltaWxhcmx5 LCBtb3N0IHBlb3BsZSBvdXRzaWRlIA0KdGhlIEVNVSBjb21tdW5pdHkgd291bGQgbm90IGtub3cg dGhhdCBTZXNzaW9uLUlkcyBmb3IgZmFzdCANCnJlLWF1dGhlbnRpY2F0aW9uIG11c3QgYmUgZXhw b3J0ZWQgYnkgYWxsIEVBUCBtZXRob2RzLg0KDQpJIGFncmVlIHdpdGggZm9sa3MgdGhhdCB0aGVy ZSBtYXkgYmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgYXJlIA0KcmVsZXZhbnQgdG8gdGhlIGJv b3RzdHJhcHBpbmcgcHJvYmxlbS4gQnV0IGVhY2ggb2YgdGhvc2Ugc2hvdWxkIA0KZGV2ZWxvcGVk IGluIHdvcmtpbmcgZ3JvdXBzIHdoZXJlIHRoZSByZWxldmFudCBleHBlcnRpc2UgaXMgcHJlc2Vu dC4gT25lIA0KY291bGQgYXJndWUgdGhhdCB0aGF0IHdlIHdvdWxkIGVuZCB1cCBkZXZlbG9waW5n IGRpZmZlcmVudCBzb2x1dGlvbnMgZm9yIA0KdGhlIHNhbWUgcHJvYmxlbSBpbiBzaWxvcy4gSG93 ZXZlciB0aGlzIHdoeSB3ZSBoYXZlIHRoZSBJRVNHICx0aGUgDQpkaXJlY3RvcmF0ZXMsIGFuZCBs aWFpc29ucyB0byBvdGhlciBzdGFuZGFyZHMgYm9kaWVzLiBJdCBlbnN1cmVzIHRoYXQgd2UgDQph cmUgYXdhcmUgb2YgcmVsYXRlZCB3b3JrIG9uZ29pbmcgaW4gZGlmZmVyZW50IGZvcmEuIFdpdGgg bXkgbGltaXRlZCANCmV4cGVyaWVuY2Ugb2YgSUVURiwgSSBjZXJ0YWlubHkgZG9uJ3QgdGhpbmsg SUVURiBpcyBpbiB0aGUgYnVzaW5lc3Mgb2YgDQpidWlsZGluZyBlY29zeXN0ZW1zIChhbmQgbmVp dGhlciBzaG91bGQgaXQgYmUpLg0KDQotLU1vaGl0DQoNCk9uIDkvMTEvMTkgMTE6MzUgUE0sIEJy aWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KPiBIaSBNb2hpdCwNCj4NCj4gT24gMTItU2VwLTE5IDA3 OjIxLCBNb2hpdCBTZXRoaSBNIHdyb3RlOg0KPj4gSGkgTWljaGFlbCwNCj4+DQo+PiBJIHdvbmRl ciB3aHkgYSBuZXcgd29ya2luZyBncm91cCBpcyBuZWVkZWQgYW5kIHdoeSB0aGlzIHdvcmsgY2Fu bm90IGJlIHB1cnN1ZWQgaW4gc29tZSBvZiB0aGUgZXhpc3Rpbmcgd29ya2luZyBncm91cHM/DQo+ Pg0KPj4gSSBzdXBwb3NlIEFOSU1BIHdhcyByZWNlbnRseSByZS1jaGFydGVyZWQgKGFuZCBjYW4g YmUgcmUtY2hhcnRlcmVkIGFnYWluKS4NCj4gV2UndmUgYmVlbiB2ZXJ5IGluc2lzdGVudCB0aGF0 IEFOSU1BIGlzIHNjb3BlZCBmb3IgcHJvZmVzc2lvbmFsbHkgbWFuYWdlZCBuZXR3b3Jrcy4gVGhh dCBpcyBub3QsIElNSE8sIGEgcmVhc29uYWJsZSByZXN0cmljdGlvbiBmb3IgSW9UOyBzbyB0aGUg QU5JTUEgc2NvcGUgaXMgbmFycm93ZXIuIEFsc28sIEFOSU1BIGlzIHNjb3BlZCBmb3IgYXV0b25v bWljIG1hbmFnZW1lbnQsIHdpdGggYm9vdHN0cmFwIGFuZCBzZWN1cml0eSBiZWluZyBvbmx5IHBh cnQgb2YgdGhlIHJlcXVpcmVtZW50czsgaW4gdGhhdCBzZW5zZSwgdGhlIEFOSU1BIHNjb3BlIGlz IGJyb2FkZXIuDQo+DQo+PiBFTVUgaXMgY3VycmVudGx5IGdvaW5nIG92ZXIgdGhlIHJlLWNoYXJ0 ZXIgdGV4dC4NCj4gSSBrbm93IGxpdHRsZSBhYm91dCBFQVAsIGJ1dCBpdCBzZWVtcyB0byBtZSB0 aGF0IGFsdGhvdWdoIGl0IG1heSB3ZWxsIGJlIGEgcHJpbWFyeSB0b29sIGZvciBvbi1ib2FyZGlu ZywgaXQgaXMgb25seSBhIHRvb2wsIGFuZCBub3QgYSBjb21wbGV0ZSBlY29zeXN0ZW0uIFRoZSAi VGhpbmtpbmcgdGhyb3VnaCBvbmJvYXJkaW5nIiB0aHJlYWQgc2NvcGVzIHRoZSB3aWRlciBwcm9i bGVtIG5pY2VseS4NCj4NCj4gUmVnYXJkcw0KPiAgICAgQnJpYW4NCj4+IEFsc28sIHlvdSB3cml0 ZToNCj4+DQo+Pj4gYWRvcHQgYSBjbG91ZC1sZXNzIChNQVNBLWxlc3MsIEFBQS1sZXNzKSBvbmJv YXJkaW5nIG1lY2hhbmlzbSAocG9zc2libHkgYSB2ZXJzaW9uIG9mIEVBUC1OT09CKSwNCj4+IFRo ZXJlIGlzIGNsZWFybHkgc29tZSBtaXN1bmRlcnN0YW5kaW5nIGFib3V0IEVBUC1OT09CIGhlcmUu IEVBUC1OT09CIGlzIHNwZWNpZmljYWxseSBpbnRlbmRlZCBmb3IgcmVnaXN0ZXJpbmcgbmV3IElv VCBkZXZpY2VzIG9uIGEgc2VydmVyIChhbmQgYXNzb2NpYXRpbmcgaXQgd2l0aCBhIHVzZXIgYWNj b3VudCkuIFRoZSBmYWN0IHRoYXQgaXQgcHJvdmlkZXMgbmV0d29yay1hY2Nlc3MgY3JlZGVudGlh bHMgaXMgYSBib251cy4gUGxlYXNlIGhhdmUgYSBsb29rIGF0IHNsaWRlcyAzLTEwIGhlcmU6IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0x MDMtc2VjZGlzcGF0Y2gtbmltYmxlLW91dC1vZi1iYW5kLWF1dGhlbnRpY2F0aW9uLWZvci1lYXAt ZWFwLW5vb2ItZHJhZnQtYXVyYS1lYXAtbm9vYi0wNC0wMQ0KPj4NCj4+IFlvdSBjbGVhcmx5IHNl ZSBhIEFBQSBzZXJ2ZXIgaW4gdGhlIGZpZ3VyZXMuIFNvIGNhbGxpbmcgaXQgQUFBLWxlc3MgZG9l c24ndCBtYWtlIHNlbnNlLg0KPj4NCj4+IC0tTW9oaXQNCj4+DQo+PiBPbiA5LzQvMTkgMTA6NDUg QU0sIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCj4+PiBJIHdyb3RlIHRoaXMgbGFzdCB3ZWVr LCBhbmQgcGFzc2VkIGl0IGFyb3VuZCBmb3Igb2J2aW91cyBvYmplY3Rpb25zLg0KPj4+ICAgICBo dHRwczovL2dpdGh1Yi5jb20vbWNyL2lvdHdnLWNoYXJ0ZXIvYmxvYi9tYXN0ZXIvaW90d2ctY2hh cnRlci5tZA0KPj4+IFlvdSBjYW4gdXNlIHRoZSBjcmF5b24vZWRpdCBidXR0b24gb24gZ2l0aHVi IHRvIHN1Z2dlc3QgY2hhbmdlcywgb3IgZW1haWwuDQo+Pj4NCj4+Pg0KPj4+IENoYXJ0ZXIgZm9y IFdvcmtpbmcgR3JvdXANCj4+Pg0KPj4+IFRoZSB3b3JkcyAiSW50ZXJuZXQgb2YgVGhpbmdzIiBv ciBJb1QgaGF2ZSBjb21lIHRvIG1lYW4gYW55dGhpbmcgYW5kDQo+Pj4gZXZlcnl0aGluZyB0byBh IHdpZGUgZ3JvdXAgb2YgdGVjaG5vbG9neSBwbGF5ZXJzLiBUaGUgSUVURiBoYXMgYmVlbiB3b3Jr aW5nDQo+Pj4gb24gYSB3aWRlIHZhcmlldHkgb2YgcHJvdG9jb2xzIGZvciB1c2UgYnkgbWFjaGlu ZSB0byBtYWNoaW5lDQo+Pj4gY29tbXVuaWNhdGlvbi4gVGhpcyBpbmNsdWRlIENvQVAsIENCT1Is IDZUSVNDSCwgUk9MTCwgU1VJVCwgTkVUQ09ORiBTWlRQLA0KPj4+IFQyVFJHLCBBTklNQSdzIEJS U0tJIG9uYm9hcmRpbmcgcHJvdG9jb2wsIGFuZCBtb3N0IHJlY2VudGx5IFJGQzg1MjAsIHRoZQ0K Pj4+IE1hbnVmYWN0dXJlciBVc2FnZSBEZXNjcmlwdGlvbi4NCj4+Pg0KPj4+IFRoZSBJRVRGIGhh cyB0cmllZCB0byBmb2N1cyBvbiBjYXRlZ29yaWVzIG9mIHdoYXQgbGltaXRlZCB0aGluZ3MgY2Fu IGRvLCBhbmQNCj4+PiB0aGlzIGhhcyByZXN1bHRlZCBpbiBhIG51bWJlciBvZiB1c2VmdWwgZG9j dW1lbnRzIGZyb20gdGhlIExpZ2h0LVdlaWdodA0KPj4+IEltcGxlbWVudGF0aW9uIEd1aWRlIChM V0lHKS4gUkZDNzIyOCBpcyBhIGtleSBwcm9kdWN0LCBoYXZpbmcgcHJvdmlkZWQNCj4+PiB0ZXJt aW5vbG9neSBhbmQgc2NhbGluZyB1bmRlcnN0YW5kaW5nIHRvIHRoZSBlbnRpcmUgaW5kdXN0cnku IEFsbCBvZiB0aGlzIGhhcw0KPj4+IGJlZW4gYWJvdXQgc2NhbGluZyB0aGUgSW50ZXJuZXQgdGVj aG5vbG9naWVzIHRvIHNtYWxsIGRldmljZXMgYW5kIGNvbnN0cmFpbmVkDQo+Pj4gbmV0d29ya3Mu IEluIGFnZ3JlZ2F0ZSwgdGhlc2UgZGV2aWNlcyBvbiBzbWFsbCBuZXR3b3JrcyBwcmVzZW50IGEg c2lnbmlmaWNhbnQNCj4+PiBvcGVyYXRpb25hbCByaXNrIHRvIHRoZSBJbnRlcm5ldCBhcyBhIHdo b2xlLCBhbmQgZXZlbiB0byBpbmRpdmlkdWFsDQo+Pj4gRW50ZXJwcmlzZSwgc2ltcGx5IGR1ZSB0 byB0aGVpciBudW1iZXJzLCBhbmQgbGFjayBvZiBvcHBvcnR1bml0eSBmb3IgcmVndWxhcg0KPj4+ IGh1bWFuIHN1cGVydmlzaW9uLg0KPj4+DQo+Pj4gSW9UIGRldmljZXMgYWxyZWFkeSBleGlzdCB0 b2RheSBpbiB2YXN0IG51bWJlcnMuIE1vc3QgZGV2aWNlcyB0aGF0IHBlb3BsZSBhcmUNCj4+PiBw ZXJzb25hbGx5IGZhbWlsaWFyIHdpdGggYXJlIGluIHRoZSBCbHVlVG9vdGggQ29ubmVjdGVkIGRl dmljZXMsIG9yDQo+Pj4gV2ViLUNvbm5lY3RlZCBkZXZpY2VzIHRoYXQgdXNlIFdpRmkgdG8gcmVh Y2ggc2VydmVycyBvbiB0aGUgSW50ZXJuZXQgKCJ0aGUNCj4+PiBDbG91ZCIpLiBJbmNyZWFzaW5n bHksIHRoZSBJRVRGIHZpZXcgb2YgbWFjaGluZSB0byBtYWNoaW5lIGNvbW11bmljYXRpb25zIGFy ZQ0KPj4+IGNvbGluaXppbmcgbmV3IGdyZWVuZmllbGQgc2l0dWF0aW9ucy4gVGhlIElFVEYgbm90 aW9uIG9mIGF1dG9ub21vdXMgbmV0d29ya3MNCj4+PiBvZiBkZXZpY2VzIGlzIHN0aWxsIGEgbWlu b3JpdHkgdmlldyBjb21wYXJlZCB0byB0aGUgbWFya2V0IElvVCBpbmR1c3RyeSBvZg0KPj4+IGNs b3VkLW9ubHkgY29ubmVjdGVkIGRldmljZXMsIGJ1dCB0aGUgdHJhbnNpdGlvbiBpcyBvY2N1cmlu Zy4NCj4+Pg0KPj4+IFJGQzg1MjAgd2FzIGNyZWF0ZWQgdG8gYnJpZGdlIHRoZSBnYXAgYmV0d2Vl biBkZXZpY2VzIHdob2xseSBjb250cm9sbGVkIGJ5IGENCj4+PiBsb2NhbCBvcGVyYXRvciAoc3Vj aCBhcyBFbnRlcnByaXNlIElUKSwgYW5kIGRldmljZXMgd2hpY2ggY2FuIG5vdCBhc3N1bWUgYW55 DQo+Pj4gaW5mcmFzdHJ1Y3R1cmUgYXQgYWxsLCBhbmQgbXVzdCByZWx5IGVudGlyZWx5IG9uIGNs b3VkIGNvbW11bmljYXRpb25zIGZvcg0KPj4+IGNvbW1hbmQgYW5kIGNvbnRyb2wuDQo+Pj4NCj4+ PiBUaGlzIHdvcmtpbmcgZ3JvdXAgY29uY2VybnMgaXRzZWxmIHdpdGggT3BlcmF0aW9uYWwgU2Vj dXJpdHkgb2YgSW9UIHN5c3RlbXMuDQo+Pj4NCj4+PiBUaGlzIGluY2x1ZGVzOg0KPj4+DQo+Pj4g KiBmYWN0b3J5IHByb3Zpc2lvbmluZyBvZiBkZXZpY2VzDQo+Pj4gKiBvbmJvYXJkaW5nIG9mIGRl dmljZXMNCj4+PiAqIGFjY2VzcyBjb250cm9sIG9mIGRldmljZXMgdG8gbmV0d29yayByZXNvdXJj ZXMNCj4+PiAqIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wgb2YgZGV2aWNlcw0KPj4+ICogYXNzZXQg bWFuYWdlbWVudCBvZiBkZXZpY2VzLCBhcyBpdCBwZXJ0YWlucyB0byBzb2Z0d2FyZS9maXJtd2Fy ZSB2ZXJzaW9ucw0KPj4+ICogaXNvbGF0aW9uL3F1YXJhbnRpbmUgb2YgZGV2aWNlcw0KPj4+ICog cmVtZWRpYXRpb24gb2YgYnJva2VuIGRldmljZXMNCj4+PiAqIGVuZCBvZiBsaWZlIG1hbmFnZW1l bnQgb2YgZGV2aWNlcw0KPj4+DQo+Pj4gVGhlIFdHIGlzIGNoYXJ0ZXJlZCBleHBsaWNpdGVseSB0 byB3b3JrIG9uIE1VRCAoUkZDODUyMCkgYW5kIGV4dGVuc2lvbnMgdG8gaXQuDQo+Pj4NCj4+PiBU aGUgV0cgaXMgY2hhcnRlcmVkIHRvIHdvcmsgb24gb25ib2FyZGluZyBwcm90b2NvbHMsIHNwZWNp ZmljYWxseSBpbmNsdWRpbmcNCj4+PiBkZXJpdmF0aWVzIG9mIEJSU0tJIChSRkMtdGJkKSwgYnV0 IG5vdCBsaW1pdGVkIHRvIGp1c3QgdGhhdCBwcm90b2NvbC4NCj4+Pg0KPj4+IFRoZSBXRyBpcyBu b3QgZXhwZWN0ZWQgdG8gcGljayBhIHdpbm5lciwgYW5kIGlzIGVuY291cmFnZWQgdG8gd29yayBv biBhDQo+Pj4gbXVsdGl0dWRlIG9mIHVzZS1jYXNlIHNwZWNpZmljIHByb3RvY29sczogYmV0dGVy IHRvIGdldCBvbmUgdXNlIGNhc2UgcmlnaHQsDQo+Pj4gdGhhbiB0byBiZSB0b28tY29tcGxleCBq YWNrIG9mIGFsbCB0cmFkZXMuDQo+Pj4NCj4+PiBUaGUgV0cgaXMgZXhwZWN0ZWQgdG8gYXJ0aWN1 bGF0ZSBjbGVhciBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMgZm9yIGVhY2gNCj4+PiBwcm90b2Nv bC4gVGhlIFdHIGlzIGV4cGVjdGVkIHRvIHByb2R1Y2UgY29uY2lzZSBSb2FkbWFwIGRvY3VtZW50 cyB0aGF0DQo+Pj4gZXhwbGFpbiBob3cgYSB2YXJpZXR5IG9mIElFVEYgKGFuZCBvdGhlcikgcHJv dG9jb2xzIGNhbiB3b3JrIHRvZ2V0aGVyIHRvDQo+Pj4gc2F0aXNmeSB0aGUgT3BlcmF0aW9uYWwg bmVlZHMgb2Ygc3BlY2lmaWMgSW9UIGFyZWFzLiBUaGVzZSByb2FkbWFwIGRvY3VtZW50cw0KPj4+ IG5lZWRu4oCZdCByZXN1bHQgaW4gUkZDcy4NCj4+Pg0KPj4+IE5laXRoZXIgdGhlIFdHIG5vciB0 aGUgSUVURiBoYXMgZXhjbHVzaXZpdHkgaGVyZSwgYW5kIGFuIGlkZWFsIGRvY3VtZW50IHdvdWxk DQo+Pj4gYmUgb25lIHRoYXQgdGhlIFdHIGhlbHBzIHRvIHN0YXJ0LCBidXQgYSBzcGVjaWZpYyBp bmR1c3RyeSBhbGxpYW5jZSBiZWNvbWVzDQo+Pj4gdGhlIGxlYWQgZWRpdG9yIGZvci4NCj4+Pg0K Pj4+IFRoZXJlIHdpbGwgYmUgY29vcmRpbmF0aW9uIHdpdGggbWFueSBvdGhlciBXR3MgYmV5b25k IHRoZSBsaXN0IGFib3ZlLCBhbmQNCj4+PiB0aGlzIFdHIG1heSBhY2NlcHQgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQgd29yayBmcm9tIG90aGVyIFdHcyBhYm91dCBzcGVjaWZpYw0KPj4+IHdheXMg dG8gZGVwbG95IHRoZWlyIHByb3RvY29scy4NCj4+Pg0KPj4+IFRoZSBXRyB3aWxsIG9wZXJhdGUg dGhyb3VnaCBhIHNlcmllcyBvZiB2aXJ0dWFsIGludGVyaW0gbWVldGluZ3MuIFRoaXMgaXMNCj4+ PiBkcml2ZW4gYnkgYSBuZWVkIHRvIGludGVyYWN0IHJlZ3VsYXJseSB3aXRoIG90aGVyIGluZHVz dHJ5IGdyb3VvcHMsIGFuZCBkdWUNCj4+PiB0byB0aGUgdmFyaWV0eSBvZiB0b3BpY3Mgd2hpY2gg d2lsbCBub3QgYWx3YXlzIGJlIGFibGUgdG8gZ2V0IHF1b3J1bSBhcyBhDQo+Pj4gY29tbWl0dGVl IG9mIHRoZSB3aG9sZS4NCj4+Pg0KPj4+IHt1bnVzdWFsLCBtYXliZSBub3QgY2hhcnRlciBhcHBy b3ByaWF0ZSwgYnV0IHJhdGhlciBzYWFnLWxpa2V9DQo+Pj4gRHVyaW5nIGluLXBlcnNvbiBtZWV0 aW5ncywgdGhlIFdHIHdpbGwgZGVhbCB3aXRoIHR5cGljYWwgc3RhdHVzIGFuZCBkb2N1bWVudA0K Pj4+IHByb2dyZXNzIGlzc3VlcyBkdXJpbmcgb25lIGhvdXIgKG9yIGxlc3MpIG9mIHRoZSB0aW1l LCBhbmQgZHVyaW5nIGFub3RoZXINCj4+PiBob3VyLCB3aWxsIGJlIG9wZW4gdG8gc2xpZGV3YXJl IHByZXNlbnRhdGlvbnMgYW5kIHR1dG9yaWFscyBvbiBjdXJyZW50IElFVEYNCj4+PiBvciBvdGhl ci1TRE8gSW9UIGVmZm9ydHMuIFRoZSBnb2FsIG9mIHRoZXNlIHByZXNlbnRhdGlvbnMgaXMgdG8g cXVpY2tseQ0KPj4+IGNvbW11bmljYXRlIGN1cnJlbnQgSW9UIHN5c3RlbXMgc3RhdGUgdG8gdGhl IHJlc3Qgb2YgdGhlIElFVEYuDQo+Pj4NCj4+PiBJdCBpcyBhY2tub3dsZWRnZWQgdGhhdCBwYXJ0 IG9mIHRoZSB2YWx1ZSBpcyBpbiBZb3VUdWJlIGNvbnRlbnQsIGFuZCBzb21lDQo+Pj4gY29udGVu dCBzaG91bGQgYmUgZG9uZSBhdCBJQUIgdGVjaCBwbGVuYXJpZXMgcmF0aGVyIHRoYW4gYXQgdGhl IFdHLg0KPj4+DQo+Pj4gVGhlIGluaXRpYWwgc2V0IG9mIHdvcmsgaXRlbXMgaXMgaW5jbHVkZWQg YmVsb3cgYXMgbWlsZXN0b25lcywgd2hpY2ggb25seQ0KPj4+IHJlcXVpcmUgQUQgYXBwcm92YWwu DQo+Pj4NCj4+PiBNaWxlc3RvbmVzDQo+Pj4NCj4+PiAqIGFkb3B0IHRoZSBjb25zdHJhaW5lZC12 b3VjaGVyL2NvbnN0cmFpbmVkLUJSU0tJIHdvcmsgZnJvbSBBTklNQS4NCj4+PiAqIGFkb3B0IHRo ZSBkdHNlY3VyaXR5LXplcm8tdG91Y2ggd29yayBmcm9tIDZ0aXNjaCwgd2hpY2ggY2FuIG5vdCBm aW5pc2ggYmVmb3JlIGEgTEFLRSBmaW5pc2hlcy4NCj4+PiAqIGNyZWF0ZSBhIGxpc3Qgb2YgYSBz ZXJpZXMgb2YgTVVEIGV4dGVuc2lvbnMsIGFuZCByZXZpc2UgdGhpcyBtaWxlc3RvbmUNCj4+PiAq IGFkb3B0IGEgY2xvdWQtbGVzcyAoTUFTQS1sZXNzLCBBQUEtbGVzcykgb25ib2FyZGluZyBtZWNo YW5pc20gKHBvc3NpYmx5IGEgdmVyc2lvbiBvZiBFQVAtTk9PQiksIHRoYXQgY2FuIGJlIHVzZWQg YXQgdGhlIHJldGFpbCBsZXZlbC4NCj4+PiAqIG5lZ290aWF0ZSB3aXRoIEVNVSBXRyBvbiBob3cg dG8gcHJvY2VlZCB3aXRoIFRFQVAtQlJTS0ksIGFuZCByZXZpc2UgdGhpcyBtaWxlc3RvbmUuDQo+ Pj4gKiBhZG9wdCBhIGNsb3VkLWRyaXZlbiBvbmJvYXJkaW5nIG1lY2hhbmlzbSB0aGF0IGNhbiBi ZSB1c2VkIGluIGNvbXBsZXRlbHkgb2ZmbGluZSBzaXR1YXRpb25zIHdpdGhvdXQgcmVxdWlyaW5n IHJlbmV3YWxzIChwZXJoYXBzIHJldmlzaW5nIFJGQzgzNjYpLg0KPj4+IC4uLi4NCj4+Pg0KPj4+ DQo+Pj4NCj4+Pg0KPj4+DQo= From nobody Fri Sep 13 03:02:27 2019 Return-Path: <0100016d2683dc84-89da1701-908b-4b62-bdd6-fdef27fccc12-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 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 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" , "mud@ietf.org" To: Michael Richardson References: <19176.1567583108@dooku.sandelman.ca> <0100016cfc877287-c2198aee-ffe6-4c28-94a1-cb141b92741f-000000@email.amazonses.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: X-Mailman-Approved-At: Fri, 13 Sep 2019 03:02:25 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 17:27:29 -0000 --Apple-Mail=_7DFDE744-549B-4852-AFE1-A7698A030D5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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 --Apple-Mail=_7DFDE744-549B-4852-AFE1-A7698A030D5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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

= --Apple-Mail=_7DFDE744-549B-4852-AFE1-A7698A030D5B-- From nobody Fri Sep 13 03:02:33 2019 Return-Path: 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 9B88C1208C5; Thu, 12 Sep 2019 13:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 m2KtTVPHFtoo; Thu, 12 Sep 2019 13:28:15 -0700 (PDT) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E804912086A; Thu, 12 Sep 2019 13:28:14 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id s17so7349312plp.2; Thu, 12 Sep 2019 13:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=zUSUa+c86ENUOdQtQ3wQQ7ooyB88WH8sVr6a08pGJKM=; b=LVv8vadYoaloMhRjkSf94B+S55GYDDDaaAuYyLA4VoqjD//58pE2AfDU2Gf6v3jdtn Hp03zeVuOHCvbdVxNhIK9S9Mf3NOq7s8NXG5n9wyjCgX+RQOV5MvVDfRB11FP3B/V/Hv YUU1QtWIWQjO3Tz72oif+tSlNb5hfbwDPS16QWbMLX/5gDxmUemRXlBqmIhGgHr/8aoh l9zWm7ajJFMUj4rXOCizbMOsaUsO//g9fnM+yR9+Gx6jg7AM3MP+4fV5JbQstKjGDqB4 tMGUPT0w992SRCxNuZfRXHKBmB2V3PYJ4dMIZoCWABf6R/2cU70Opdl3WL8McwxEPSy9 cHcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zUSUa+c86ENUOdQtQ3wQQ7ooyB88WH8sVr6a08pGJKM=; b=N3kgqRFH9b/dAFibJitU0yJcYgoM3JC5/7wYn8wsHtL2BPRGKMZrRcAXJbOwYRf1d9 FoaICE3u9gM3BU9JjiUVAuAvVd2rnMmm078I5DB9jlGp252NHXYfMdNHfHQJKQC7W/9O KHUIumx4reK6aG9who53rikgkrodOoaiduACDh1wi4xCaq2TAz+SCq9OBMYfbZ/ruM5X nLkokHl7AR10sp1H1NwSVo4iT3g2cmlXu+Q2nKsW8/H1SpUte2TpYM+ywWheh+O8gURT B7l6CMRFFzI2/n1AOY1iqm236SQKry7C+hPfwoVz9Zdn179HGuJqqr9fqrDcGMjorIUe bt6Q== X-Gm-Message-State: APjAAAVS9coWIiRPFJHGIYeVw7PJ8Muv8c6VizgkPB4Hy497gb0EWJ3Y 9nuie7eBIgixENOwtUjHF9p+M77n X-Google-Smtp-Source: APXvYqwcWnQpXnIlWv9kvrKvROaK+aT3KjcRN1X3O6YIooFizzxO4Q6ku8lh1xWH2Vfeuq/0gjMZkg== X-Received: by 2002:a17:902:8a84:: with SMTP id p4mr3419948plo.36.1568320093965; Thu, 12 Sep 2019 13:28:13 -0700 (PDT) Received: from [192.168.178.30] (82.206.69.111.dynamic.snap.net.nz. [111.69.206.82]) by smtp.gmail.com with ESMTPSA id r185sm33698369pfr.68.2019.09.12.13.28.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Sep 2019 13:28:12 -0700 (PDT) To: Mohit Sethi M , Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" 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> From: Brian E Carpenter Message-ID: <86d7f560-eb45-fec1-c98d-91f92c0e1006@gmail.com> Date: Fri, 13 Sep 2019 08:28:10 +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: <1e9357be-a384-8663-3142-1b2dfe0a376f@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 13 Sep 2019 03:02:26 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 20:28:21 -0000 Hi Mohit, > With my limited=20 > 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 i= n 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 AN= IMA includes a reference model as well as specific standards. It encourages e= ach vendor to provide a MASA and encourages network operators to mix and matc= h products from multiple vendors. Whether the BRSKI/MASA model generalises beyond autonomic networks remain= s 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, >=20 > IETF is in the business of building tools (i.e. open specifications wit= h=20 > running code) for developers. And these tools are best built in working= =20 > groups which have the expertise on them. Most people outside the ANIMA = > community would not know what is a MASA. Similarly, most people outside= =20 > the EMU community would not know that Session-Ids for fast=20 > re-authentication must be exported by all EAP methods. >=20 > I agree with folks that there may be multiple solutions that are=20 > relevant to the bootstrapping problem. But each of those should=20 > developed in working groups where the relevant expertise is present. On= e=20 > could argue that that we would end up developing different solutions fo= r=20 > the same problem in silos. However this why we have the IESG ,the=20 > directorates, and liaisons to other standards bodies. It ensures that w= e=20 > are aware of related work ongoing in different fora. With my limited=20 > experience of IETF, I certainly don't think IETF is in the business of = > building ecosystems (and neither should it be). >=20 > --Mohit >=20 > 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 b= e pursued in some of the existing working groups? >>> >>> I suppose ANIMA was recently re-chartered (and can be re-chartered ag= ain). >> We've been very insistent that ANIMA is scoped for professionally mana= ged 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 prob= lem nicely. >> >> Regards >> Brian >>> Also, you write: >>> >>>> adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possi= bly 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-a= ccess credentials is a bonus. Please have a look at slides 3-10 here: htt= ps://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-ni= mble-out-of-band-authentication-for-eap-eap-noob-draft-aura-eap-noob-04-0= 1 >>> >>> You clearly see a AAA server in the figures. So calling it AAA-less d= oesn'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.m= d >>>> 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-Wei= ght >>>> Implementation Guide (LWIG). RFC7228 is a key product, having provid= ed >>>> terminology and scaling understanding to the entire industry. All of= this has >>>> been about scaling the Internet technologies to small devices and co= nstrained >>>> networks. In aggregate, these devices on small networks present a si= gnificant >>>> 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 p= eople 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 communica= tions are >>>> colinizing new greenfield situations. The IETF notion of autonomous = networks >>>> of devices is still a minority view compared to the market IoT indus= try of >>>> cloud-only connected devices, but the transition is occuring. >>>> >>>> RFC8520 was created to bridge the gap between devices wholly control= led by a >>>> local operator (such as Enterprise IT), and devices which can not as= sume any >>>> infrastructure at all, and must rely entirely on cloud communication= s 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 v= ersions >>>> * 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 extensi= ons to it. >>>> >>>> The WG is chartered to work on onboarding protocols, specifically in= cluding >>>> derivaties of BRSKI (RFC-tbd), but not limited to just that protocol= =2E >>>> >>>> The WG is not expected to pick a winner, and is encouraged to work o= n 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 th= at >>>> explain how a variety of IETF (and other) protocols can work togethe= r to >>>> satisfy the Operational needs of specific IoT areas. These roadmap d= ocuments >>>> needn=E2=80=99t result in RFCs. >>>> >>>> Neither the WG nor the IETF has exclusivity here, and an ideal docum= ent 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. Th= is 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 an= other >>>> hour, will be open to slideware presentations and tutorials on curre= nt IETF >>>> or other-SDO IoT efforts. The goal of these presentations is to quic= kly >>>> 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 fi= nish before a LAKE finishes. >>>> * create a list of a series of MUD extensions, and revise this miles= tone >>>> * adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (pos= sibly 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 revis= e this milestone. >>>> * adopt a cloud-driven onboarding mechanism that can be used in comp= letely offline situations without requiring renewals (perhaps revising RF= C8366). >>>> .... >>>> >>>> >>>> >>>> >>>> From nobody Mon Sep 16 04:16:44 2019 Return-Path: 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 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 To: Brian E Carpenter , Mohit Sethi M , Michael Richardson , "mud@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: 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: X-Mailman-Approved-At: Mon, 16 Sep 2019 04:16:43 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 09:20:02 -0000 --_000_202e4ac06bdb41401a84812390667b4dericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCkEgcHJvdG9jb2wgdGhhdCBoYXMgbWFueSBkZXBlbmRlbmNpZXMgKG9yIGdh cHMpIGlzIG5vdCBpZGVhbCBmcm9tIG15IHBlcnNwZWN0aXZlLiBBIHByb3RvY29sIHRoYXQgcmVx dWlyZXMgViBmcm9tIGNoaXAgdmVuZG9yLCBXIGZyb20gdGhlIGRldmljZSBtYW51ZmFjdHVyZXIs IFggZnJvbSBjZXJ0aWZpY2F0ZSBhdXRob3JpdGllcywgWSBmcm9tIHRoZSBuZXR3b3JrIGFkbWlu aXN0cmF0b3IsIGFuZCBaIGZyb20gdGhlIHVzZXIgaXMgbm90IGEgZ29vZCBwcm90b2NvbC4NCg0K Tm90ZSB0aGF0IHRoaXMgaXMgYSBoeXBvdGhldGljYWwgcHJvdG9jb2wgdGhhdCB0aGFua2Z1bGx5 IGRvZXNuJ3QgZXhpc3QuDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCB0aGF0IElFVEYg c2hvdWxkIG5vdCBwcm9kdWNlIHN0YW5kYXJkcyB3aXRoIGdhcHMuIEJ1dCB0aGUgc29sdXRpb24g aXMgbm90IHRvIGZpbGwgdGhvc2UgZ2Fwcy4gQSBiZXR0ZXIgc29sdXRpb24gaXMgdGhhdCBvdXIg cHJvdG9jb2xzIHNob3VsZG4ndCBoYXZlIHRvbyBtYW55IGRlcGVuZGVuY2llcyBpbiB0aGUgZmly c3QgcGxhY2UuDQoNCi0tTW9oaXQNCg0KT24gOS8xMi8xOSAxMToyOCBQTSwgQnJpYW4gRSBDYXJw ZW50ZXIgd3JvdGU6DQoNCkhpIE1vaGl0LA0KDQoNCg0KV2l0aCBteSBsaW1pdGVkDQpleHBlcmll bmNlIG9mIElFVEYsIEkgY2VydGFpbmx5IGRvbid0IHRoaW5rIElFVEYgaXMgaW4gdGhlIGJ1c2lu ZXNzIG9mDQpidWlsZGluZyBlY29zeXN0ZW1zDQoNCg0KDQpObywgYnV0IHRoZSBvcGVuIHNvdXJj ZSBjb21tdW5pdHkgdGhhdCB1c2VzIG91ciBzdGFuZGFyZHMgZGVmaW5pdGVseSBpcyBpbg0KdGhh dCBidXNpbmVzcywgc28gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZHMgbmVlZCB0byBoZWxwIHN1Y2gg d29yay4NCg0KDQoNCihhbmQgbmVpdGhlciBzaG91bGQgaXQgYmUpLg0KDQoNCg0KSG93ZXZlciwg dGhlIElFVEYgc2hvdWxkIG5vdCBwcm9kdWNlIHN0YW5kYXJkcyB3aXRoIGdhcHMgdGhhdCBlbmNv dXJhZ2UNCnByb3ByaWV0YXJ5IGVjb3N5c3RlbXMgdGhhdCBhbGxvdyBjdXN0b21lciBjYXB0dXJl LiBUaGF0J3MgZXhhY3RseSB3aHkgQU5JTUENCmluY2x1ZGVzIGEgcmVmZXJlbmNlIG1vZGVsIGFz IHdlbGwgYXMgc3BlY2lmaWMgc3RhbmRhcmRzLiBJdCBlbmNvdXJhZ2VzIGVhY2gNCnZlbmRvciB0 byBwcm92aWRlIGEgTUFTQSBhbmQgZW5jb3VyYWdlcyBuZXR3b3JrIG9wZXJhdG9ycyB0byBtaXgg YW5kIG1hdGNoDQpwcm9kdWN0cyBmcm9tIG11bHRpcGxlIHZlbmRvcnMuDQoNCldoZXRoZXIgdGhl IEJSU0tJL01BU0EgbW9kZWwgZ2VuZXJhbGlzZXMgYmV5b25kIGF1dG9ub21pYyBuZXR3b3JrcyBy ZW1haW5zIHRvDQpzZWVuLCBidXQgYWdhaW46IGl0IHdhcyBub3QgZGVzaWduZWQgZm9yIElvVC4N Cg0KUmVnYXJkcw0KICAgQnJpYW4gQ2FycGVudGVyDQoNCk9uIDEyLVNlcC0xOSAyMzozMywgTW9o aXQgU2V0aGkgTSB3cm90ZToNCg0KDQpIaSBCcmlhbiwNCg0KSUVURiBpcyBpbiB0aGUgYnVzaW5l c3Mgb2YgYnVpbGRpbmcgdG9vbHMgKGkuZS4gb3BlbiBzcGVjaWZpY2F0aW9ucyB3aXRoDQpydW5u aW5nIGNvZGUpIGZvciBkZXZlbG9wZXJzLiBBbmQgdGhlc2UgdG9vbHMgYXJlIGJlc3QgYnVpbHQg aW4gd29ya2luZw0KZ3JvdXBzIHdoaWNoIGhhdmUgdGhlIGV4cGVydGlzZSBvbiB0aGVtLiBNb3N0 IHBlb3BsZSBvdXRzaWRlIHRoZSBBTklNQQ0KY29tbXVuaXR5IHdvdWxkIG5vdCBrbm93IHdoYXQg aXMgYSBNQVNBLiBTaW1pbGFybHksIG1vc3QgcGVvcGxlIG91dHNpZGUNCnRoZSBFTVUgY29tbXVu aXR5IHdvdWxkIG5vdCBrbm93IHRoYXQgU2Vzc2lvbi1JZHMgZm9yIGZhc3QNCnJlLWF1dGhlbnRp Y2F0aW9uIG11c3QgYmUgZXhwb3J0ZWQgYnkgYWxsIEVBUCBtZXRob2RzLg0KDQpJIGFncmVlIHdp dGggZm9sa3MgdGhhdCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgYXJlDQpy ZWxldmFudCB0byB0aGUgYm9vdHN0cmFwcGluZyBwcm9ibGVtLiBCdXQgZWFjaCBvZiB0aG9zZSBz aG91bGQNCmRldmVsb3BlZCBpbiB3b3JraW5nIGdyb3VwcyB3aGVyZSB0aGUgcmVsZXZhbnQgZXhw ZXJ0aXNlIGlzIHByZXNlbnQuIE9uZQ0KY291bGQgYXJndWUgdGhhdCB0aGF0IHdlIHdvdWxkIGVu ZCB1cCBkZXZlbG9waW5nIGRpZmZlcmVudCBzb2x1dGlvbnMgZm9yDQp0aGUgc2FtZSBwcm9ibGVt IGluIHNpbG9zLiBIb3dldmVyIHRoaXMgd2h5IHdlIGhhdmUgdGhlIElFU0cgLHRoZQ0KZGlyZWN0 b3JhdGVzLCBhbmQgbGlhaXNvbnMgdG8gb3RoZXIgc3RhbmRhcmRzIGJvZGllcy4gSXQgZW5zdXJl cyB0aGF0IHdlDQphcmUgYXdhcmUgb2YgcmVsYXRlZCB3b3JrIG9uZ29pbmcgaW4gZGlmZmVyZW50 IGZvcmEuIFdpdGggbXkgbGltaXRlZA0KZXhwZXJpZW5jZSBvZiBJRVRGLCBJIGNlcnRhaW5seSBk b24ndCB0aGluayBJRVRGIGlzIGluIHRoZSBidXNpbmVzcyBvZg0KYnVpbGRpbmcgZWNvc3lzdGVt cyAoYW5kIG5laXRoZXIgc2hvdWxkIGl0IGJlKS4NCg0KLS1Nb2hpdA0KDQpPbiA5LzExLzE5IDEx OjM1IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCg0KDQpIaSBNb2hpdCwNCg0KT24gMTIt U2VwLTE5IDA3OjIxLCBNb2hpdCBTZXRoaSBNIHdyb3RlOg0KDQoNCkhpIE1pY2hhZWwsDQoNCkkg d29uZGVyIHdoeSBhIG5ldyB3b3JraW5nIGdyb3VwIGlzIG5lZWRlZCBhbmQgd2h5IHRoaXMgd29y ayBjYW5ub3QgYmUgcHVyc3VlZCBpbiBzb21lIG9mIHRoZSBleGlzdGluZyB3b3JraW5nIGdyb3Vw cz8NCg0KSSBzdXBwb3NlIEFOSU1BIHdhcyByZWNlbnRseSByZS1jaGFydGVyZWQgKGFuZCBjYW4g YmUgcmUtY2hhcnRlcmVkIGFnYWluKS4NCg0KDQpXZSd2ZSBiZWVuIHZlcnkgaW5zaXN0ZW50IHRo YXQgQU5JTUEgaXMgc2NvcGVkIGZvciBwcm9mZXNzaW9uYWxseSBtYW5hZ2VkIG5ldHdvcmtzLiBU aGF0IGlzIG5vdCwgSU1ITywgYSByZWFzb25hYmxlIHJlc3RyaWN0aW9uIGZvciBJb1Q7IHNvIHRo ZSBBTklNQSBzY29wZSBpcyBuYXJyb3dlci4gQWxzbywgQU5JTUEgaXMgc2NvcGVkIGZvciBhdXRv bm9taWMgbWFuYWdlbWVudCwgd2l0aCBib290c3RyYXAgYW5kIHNlY3VyaXR5IGJlaW5nIG9ubHkg cGFydCBvZiB0aGUgcmVxdWlyZW1lbnRzOyBpbiB0aGF0IHNlbnNlLCB0aGUgQU5JTUEgc2NvcGUg aXMgYnJvYWRlci4NCg0KDQoNCkVNVSBpcyBjdXJyZW50bHkgZ29pbmcgb3ZlciB0aGUgcmUtY2hh cnRlciB0ZXh0Lg0KDQoNCkkga25vdyBsaXR0bGUgYWJvdXQgRUFQLCBidXQgaXQgc2VlbXMgdG8g bWUgdGhhdCBhbHRob3VnaCBpdCBtYXkgd2VsbCBiZSBhIHByaW1hcnkgdG9vbCBmb3Igb24tYm9h cmRpbmcsIGl0IGlzIG9ubHkgYSB0b29sLCBhbmQgbm90IGEgY29tcGxldGUgZWNvc3lzdGVtLiBU aGUgIlRoaW5raW5nIHRocm91Z2ggb25ib2FyZGluZyIgdGhyZWFkIHNjb3BlcyB0aGUgd2lkZXIg cHJvYmxlbSBuaWNlbHkuDQoNClJlZ2FyZHMNCiAgICBCcmlhbg0KDQoNCkFsc28sIHlvdSB3cml0 ZToNCg0KDQoNCmFkb3B0IGEgY2xvdWQtbGVzcyAoTUFTQS1sZXNzLCBBQUEtbGVzcykgb25ib2Fy ZGluZyBtZWNoYW5pc20gKHBvc3NpYmx5IGEgdmVyc2lvbiBvZiBFQVAtTk9PQiksDQoNCg0KVGhl cmUgaXMgY2xlYXJseSBzb21lIG1pc3VuZGVyc3RhbmRpbmcgYWJvdXQgRUFQLU5PT0IgaGVyZS4g RUFQLU5PT0IgaXMgc3BlY2lmaWNhbGx5IGludGVuZGVkIGZvciByZWdpc3RlcmluZyBuZXcgSW9U IGRldmljZXMgb24gYSBzZXJ2ZXIgKGFuZCBhc3NvY2lhdGluZyBpdCB3aXRoIGEgdXNlciBhY2Nv dW50KS4gVGhlIGZhY3QgdGhhdCBpdCBwcm92aWRlcyBuZXR3b3JrLWFjY2VzcyBjcmVkZW50aWFs cyBpcyBhIGJvbnVzLiBQbGVhc2UgaGF2ZSBhIGxvb2sgYXQgc2xpZGVzIDMtMTAgaGVyZTogaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEw My1zZWNkaXNwYXRjaC1uaW1ibGUtb3V0LW9mLWJhbmQtYXV0aGVudGljYXRpb24tZm9yLWVhcC1l YXAtbm9vYi1kcmFmdC1hdXJhLWVhcC1ub29iLTA0LTAxDQoNCllvdSBjbGVhcmx5IHNlZSBhIEFB QSBzZXJ2ZXIgaW4gdGhlIGZpZ3VyZXMuIFNvIGNhbGxpbmcgaXQgQUFBLWxlc3MgZG9lc24ndCBt YWtlIHNlbnNlLg0KDQotLU1vaGl0DQoNCk9uIDkvNC8xOSAxMDo0NSBBTSwgTWljaGFlbCBSaWNo YXJkc29uIHdyb3RlOg0KDQoNCkkgd3JvdGUgdGhpcyBsYXN0IHdlZWssIGFuZCBwYXNzZWQgaXQg YXJvdW5kIGZvciBvYnZpb3VzIG9iamVjdGlvbnMuDQogICAgaHR0cHM6Ly9naXRodWIuY29tL21j ci9pb3R3Zy1jaGFydGVyL2Jsb2IvbWFzdGVyL2lvdHdnLWNoYXJ0ZXIubWQNCllvdSBjYW4gdXNl IHRoZSBjcmF5b24vZWRpdCBidXR0b24gb24gZ2l0aHViIHRvIHN1Z2dlc3QgY2hhbmdlcywgb3Ig ZW1haWwuDQoNCg0KQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cA0KDQpUaGUgd29yZHMgIkludGVy bmV0IG9mIFRoaW5ncyIgb3IgSW9UIGhhdmUgY29tZSB0byBtZWFuIGFueXRoaW5nIGFuZA0KZXZl cnl0aGluZyB0byBhIHdpZGUgZ3JvdXAgb2YgdGVjaG5vbG9neSBwbGF5ZXJzLiBUaGUgSUVURiBo YXMgYmVlbiB3b3JraW5nDQpvbiBhIHdpZGUgdmFyaWV0eSBvZiBwcm90b2NvbHMgZm9yIHVzZSBi eSBtYWNoaW5lIHRvIG1hY2hpbmUNCmNvbW11bmljYXRpb24uIFRoaXMgaW5jbHVkZSBDb0FQLCBD Qk9SLCA2VElTQ0gsIFJPTEwsIFNVSVQsIE5FVENPTkYgU1pUUCwNClQyVFJHLCBBTklNQSdzIEJS U0tJIG9uYm9hcmRpbmcgcHJvdG9jb2wsIGFuZCBtb3N0IHJlY2VudGx5IFJGQzg1MjAsIHRoZQ0K TWFudWZhY3R1cmVyIFVzYWdlIERlc2NyaXB0aW9uLg0KDQpUaGUgSUVURiBoYXMgdHJpZWQgdG8g Zm9jdXMgb24gY2F0ZWdvcmllcyBvZiB3aGF0IGxpbWl0ZWQgdGhpbmdzIGNhbiBkbywgYW5kDQp0 aGlzIGhhcyByZXN1bHRlZCBpbiBhIG51bWJlciBvZiB1c2VmdWwgZG9jdW1lbnRzIGZyb20gdGhl IExpZ2h0LVdlaWdodA0KSW1wbGVtZW50YXRpb24gR3VpZGUgKExXSUcpLiBSRkM3MjI4IGlzIGEg a2V5IHByb2R1Y3QsIGhhdmluZyBwcm92aWRlZA0KdGVybWlub2xvZ3kgYW5kIHNjYWxpbmcgdW5k ZXJzdGFuZGluZyB0byB0aGUgZW50aXJlIGluZHVzdHJ5LiBBbGwgb2YgdGhpcyBoYXMNCmJlZW4g YWJvdXQgc2NhbGluZyB0aGUgSW50ZXJuZXQgdGVjaG5vbG9naWVzIHRvIHNtYWxsIGRldmljZXMg YW5kIGNvbnN0cmFpbmVkDQpuZXR3b3Jrcy4gSW4gYWdncmVnYXRlLCB0aGVzZSBkZXZpY2VzIG9u IHNtYWxsIG5ldHdvcmtzIHByZXNlbnQgYSBzaWduaWZpY2FudA0Kb3BlcmF0aW9uYWwgcmlzayB0 byB0aGUgSW50ZXJuZXQgYXMgYSB3aG9sZSwgYW5kIGV2ZW4gdG8gaW5kaXZpZHVhbA0KRW50ZXJw cmlzZSwgc2ltcGx5IGR1ZSB0byB0aGVpciBudW1iZXJzLCBhbmQgbGFjayBvZiBvcHBvcnR1bml0 eSBmb3IgcmVndWxhcg0KaHVtYW4gc3VwZXJ2aXNpb24uDQoNCklvVCBkZXZpY2VzIGFscmVhZHkg ZXhpc3QgdG9kYXkgaW4gdmFzdCBudW1iZXJzLiBNb3N0IGRldmljZXMgdGhhdCBwZW9wbGUgYXJl DQpwZXJzb25hbGx5IGZhbWlsaWFyIHdpdGggYXJlIGluIHRoZSBCbHVlVG9vdGggQ29ubmVjdGVk IGRldmljZXMsIG9yDQpXZWItQ29ubmVjdGVkIGRldmljZXMgdGhhdCB1c2UgV2lGaSB0byByZWFj aCBzZXJ2ZXJzIG9uIHRoZSBJbnRlcm5ldCAoInRoZQ0KQ2xvdWQiKS4gSW5jcmVhc2luZ2x5LCB0 aGUgSUVURiB2aWV3IG9mIG1hY2hpbmUgdG8gbWFjaGluZSBjb21tdW5pY2F0aW9ucyBhcmUNCmNv bGluaXppbmcgbmV3IGdyZWVuZmllbGQgc2l0dWF0aW9ucy4gVGhlIElFVEYgbm90aW9uIG9mIGF1 dG9ub21vdXMgbmV0d29ya3MNCm9mIGRldmljZXMgaXMgc3RpbGwgYSBtaW5vcml0eSB2aWV3IGNv bXBhcmVkIHRvIHRoZSBtYXJrZXQgSW9UIGluZHVzdHJ5IG9mDQpjbG91ZC1vbmx5IGNvbm5lY3Rl ZCBkZXZpY2VzLCBidXQgdGhlIHRyYW5zaXRpb24gaXMgb2NjdXJpbmcuDQoNClJGQzg1MjAgd2Fz IGNyZWF0ZWQgdG8gYnJpZGdlIHRoZSBnYXAgYmV0d2VlbiBkZXZpY2VzIHdob2xseSBjb250cm9s bGVkIGJ5IGENCmxvY2FsIG9wZXJhdG9yIChzdWNoIGFzIEVudGVycHJpc2UgSVQpLCBhbmQgZGV2 aWNlcyB3aGljaCBjYW4gbm90IGFzc3VtZSBhbnkNCmluZnJhc3RydWN0dXJlIGF0IGFsbCwgYW5k IG11c3QgcmVseSBlbnRpcmVseSBvbiBjbG91ZCBjb21tdW5pY2F0aW9ucyBmb3INCmNvbW1hbmQg YW5kIGNvbnRyb2wuDQoNClRoaXMgd29ya2luZyBncm91cCBjb25jZXJucyBpdHNlbGYgd2l0aCBP cGVyYXRpb25hbCBTZWN1cml0eSBvZiBJb1Qgc3lzdGVtcy4NCg0KVGhpcyBpbmNsdWRlczoNCg0K KiBmYWN0b3J5IHByb3Zpc2lvbmluZyBvZiBkZXZpY2VzDQoqIG9uYm9hcmRpbmcgb2YgZGV2aWNl cw0KKiBhY2Nlc3MgY29udHJvbCBvZiBkZXZpY2VzIHRvIG5ldHdvcmsgcmVzb3VyY2VzDQoqIGFk bWluaXN0cmF0aXZlIGNvbnRyb2wgb2YgZGV2aWNlcw0KKiBhc3NldCBtYW5hZ2VtZW50IG9mIGRl dmljZXMsIGFzIGl0IHBlcnRhaW5zIHRvIHNvZnR3YXJlL2Zpcm13YXJlIHZlcnNpb25zDQoqIGlz b2xhdGlvbi9xdWFyYW50aW5lIG9mIGRldmljZXMNCiogcmVtZWRpYXRpb24gb2YgYnJva2VuIGRl dmljZXMNCiogZW5kIG9mIGxpZmUgbWFuYWdlbWVudCBvZiBkZXZpY2VzDQoNClRoZSBXRyBpcyBj aGFydGVyZWQgZXhwbGljaXRlbHkgdG8gd29yayBvbiBNVUQgKFJGQzg1MjApIGFuZCBleHRlbnNp b25zIHRvIGl0Lg0KDQpUaGUgV0cgaXMgY2hhcnRlcmVkIHRvIHdvcmsgb24gb25ib2FyZGluZyBw cm90b2NvbHMsIHNwZWNpZmljYWxseSBpbmNsdWRpbmcNCmRlcml2YXRpZXMgb2YgQlJTS0kgKFJG Qy10YmQpLCBidXQgbm90IGxpbWl0ZWQgdG8ganVzdCB0aGF0IHByb3RvY29sLg0KDQpUaGUgV0cg aXMgbm90IGV4cGVjdGVkIHRvIHBpY2sgYSB3aW5uZXIsIGFuZCBpcyBlbmNvdXJhZ2VkIHRvIHdv cmsgb24gYQ0KbXVsdGl0dWRlIG9mIHVzZS1jYXNlIHNwZWNpZmljIHByb3RvY29sczogYmV0dGVy IHRvIGdldCBvbmUgdXNlIGNhc2UgcmlnaHQsDQp0aGFuIHRvIGJlIHRvby1jb21wbGV4IGphY2sg b2YgYWxsIHRyYWRlcy4NCg0KVGhlIFdHIGlzIGV4cGVjdGVkIHRvIGFydGljdWxhdGUgY2xlYXIg YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnRzIGZvciBlYWNoDQpwcm90b2NvbC4gVGhlIFdHIGlzIGV4 cGVjdGVkIHRvIHByb2R1Y2UgY29uY2lzZSBSb2FkbWFwIGRvY3VtZW50cyB0aGF0DQpleHBsYWlu IGhvdyBhIHZhcmlldHkgb2YgSUVURiAoYW5kIG90aGVyKSBwcm90b2NvbHMgY2FuIHdvcmsgdG9n ZXRoZXIgdG8NCnNhdGlzZnkgdGhlIE9wZXJhdGlvbmFsIG5lZWRzIG9mIHNwZWNpZmljIElvVCBh cmVhcy4gVGhlc2Ugcm9hZG1hcCBkb2N1bWVudHMNCm5lZWRu4oCZdCByZXN1bHQgaW4gUkZDcy4N Cg0KTmVpdGhlciB0aGUgV0cgbm9yIHRoZSBJRVRGIGhhcyBleGNsdXNpdml0eSBoZXJlLCBhbmQg YW4gaWRlYWwgZG9jdW1lbnQgd291bGQNCmJlIG9uZSB0aGF0IHRoZSBXRyBoZWxwcyB0byBzdGFy dCwgYnV0IGEgc3BlY2lmaWMgaW5kdXN0cnkgYWxsaWFuY2UgYmVjb21lcw0KdGhlIGxlYWQgZWRp dG9yIGZvci4NCg0KVGhlcmUgd2lsbCBiZSBjb29yZGluYXRpb24gd2l0aCBtYW55IG90aGVyIFdH cyBiZXlvbmQgdGhlIGxpc3QgYWJvdmUsIGFuZA0KdGhpcyBXRyBtYXkgYWNjZXB0IGFwcGxpY2Fi aWxpdHkgc3RhdGVtZW50IHdvcmsgZnJvbSBvdGhlciBXR3MgYWJvdXQgc3BlY2lmaWMNCndheXMg dG8gZGVwbG95IHRoZWlyIHByb3RvY29scy4NCg0KVGhlIFdHIHdpbGwgb3BlcmF0ZSB0aHJvdWdo IGEgc2VyaWVzIG9mIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5ncy4gVGhpcyBpcw0KZHJpdmVuIGJ5 IGEgbmVlZCB0byBpbnRlcmFjdCByZWd1bGFybHkgd2l0aCBvdGhlciBpbmR1c3RyeSBncm91b3Bz LCBhbmQgZHVlDQp0byB0aGUgdmFyaWV0eSBvZiB0b3BpY3Mgd2hpY2ggd2lsbCBub3QgYWx3YXlz IGJlIGFibGUgdG8gZ2V0IHF1b3J1bSBhcyBhDQpjb21taXR0ZWUgb2YgdGhlIHdob2xlLg0KDQp7 dW51c3VhbCwgbWF5YmUgbm90IGNoYXJ0ZXIgYXBwcm9wcmlhdGUsIGJ1dCByYXRoZXIgc2FhZy1s aWtlfQ0KRHVyaW5nIGluLXBlcnNvbiBtZWV0aW5ncywgdGhlIFdHIHdpbGwgZGVhbCB3aXRoIHR5 cGljYWwgc3RhdHVzIGFuZCBkb2N1bWVudA0KcHJvZ3Jlc3MgaXNzdWVzIGR1cmluZyBvbmUgaG91 ciAob3IgbGVzcykgb2YgdGhlIHRpbWUsIGFuZCBkdXJpbmcgYW5vdGhlcg0KaG91ciwgd2lsbCBi ZSBvcGVuIHRvIHNsaWRld2FyZSBwcmVzZW50YXRpb25zIGFuZCB0dXRvcmlhbHMgb24gY3VycmVu dCBJRVRGDQpvciBvdGhlci1TRE8gSW9UIGVmZm9ydHMuIFRoZSBnb2FsIG9mIHRoZXNlIHByZXNl bnRhdGlvbnMgaXMgdG8gcXVpY2tseQ0KY29tbXVuaWNhdGUgY3VycmVudCBJb1Qgc3lzdGVtcyBz dGF0ZSB0byB0aGUgcmVzdCBvZiB0aGUgSUVURi4NCg0KSXQgaXMgYWNrbm93bGVkZ2VkIHRoYXQg cGFydCBvZiB0aGUgdmFsdWUgaXMgaW4gWW91VHViZSBjb250ZW50LCBhbmQgc29tZQ0KY29udGVu dCBzaG91bGQgYmUgZG9uZSBhdCBJQUIgdGVjaCBwbGVuYXJpZXMgcmF0aGVyIHRoYW4gYXQgdGhl IFdHLg0KDQpUaGUgaW5pdGlhbCBzZXQgb2Ygd29yayBpdGVtcyBpcyBpbmNsdWRlZCBiZWxvdyBh cyBtaWxlc3RvbmVzLCB3aGljaCBvbmx5DQpyZXF1aXJlIEFEIGFwcHJvdmFsLg0KDQpNaWxlc3Rv bmVzDQoNCiogYWRvcHQgdGhlIGNvbnN0cmFpbmVkLXZvdWNoZXIvY29uc3RyYWluZWQtQlJTS0kg d29yayBmcm9tIEFOSU1BLg0KKiBhZG9wdCB0aGUgZHRzZWN1cml0eS16ZXJvLXRvdWNoIHdvcmsg ZnJvbSA2dGlzY2gsIHdoaWNoIGNhbiBub3QgZmluaXNoIGJlZm9yZSBhIExBS0UgZmluaXNoZXMu DQoqIGNyZWF0ZSBhIGxpc3Qgb2YgYSBzZXJpZXMgb2YgTVVEIGV4dGVuc2lvbnMsIGFuZCByZXZp c2UgdGhpcyBtaWxlc3RvbmUNCiogYWRvcHQgYSBjbG91ZC1sZXNzIChNQVNBLWxlc3MsIEFBQS1s ZXNzKSBvbmJvYXJkaW5nIG1lY2hhbmlzbSAocG9zc2libHkgYSB2ZXJzaW9uIG9mIEVBUC1OT09C KSwgdGhhdCBjYW4gYmUgdXNlZCBhdCB0aGUgcmV0YWlsIGxldmVsLg0KKiBuZWdvdGlhdGUgd2l0 aCBFTVUgV0cgb24gaG93IHRvIHByb2NlZWQgd2l0aCBURUFQLUJSU0tJLCBhbmQgcmV2aXNlIHRo aXMgbWlsZXN0b25lLg0KKiBhZG9wdCBhIGNsb3VkLWRyaXZlbiBvbmJvYXJkaW5nIG1lY2hhbmlz bSB0aGF0IGNhbiBiZSB1c2VkIGluIGNvbXBsZXRlbHkgb2ZmbGluZSBzaXR1YXRpb25zIHdpdGhv dXQgcmVxdWlyaW5nIHJlbmV3YWxzIChwZXJoYXBzIHJldmlzaW5nIFJGQzgzNjYpLg0KLi4uLg0K DQoNCg0KDQoNCg0KDQoNCg0K --_000_202e4ac06bdb41401a84812390667b4dericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <39F77BF2E0AF6B4FA36D063DC20C9393@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgQnJpYW4sPC9wPg0KPHA+QSBwcm90b2NvbCB0aGF0 IGhhcyBtYW55IGRlcGVuZGVuY2llcyAob3IgZ2FwcykgaXMgbm90IGlkZWFsIGZyb20gbXkgcGVy c3BlY3RpdmUuIEEgcHJvdG9jb2wgdGhhdCByZXF1aXJlcw0KPGI+VjwvYj4gZnJvbSBjaGlwIHZl bmRvciwgPGI+VzwvYj48Yj4gPC9iPmZyb20gdGhlIGRldmljZSBtYW51ZmFjdHVyZXIsIDxiPlg8 L2I+IGZyb20gY2VydGlmaWNhdGUgYXV0aG9yaXRpZXMsDQo8Yj5ZPC9iPiBmcm9tIHRoZSBuZXR3 b3JrIGFkbWluaXN0cmF0b3IsIGFuZCA8Yj5aIDwvYj5mcm9tIHRoZSB1c2VyIGlzIG5vdCBhIGdv b2QgcHJvdG9jb2wuJm5ic3A7DQo8YnI+DQo8L3A+DQo8cD5Ob3RlIHRoYXQgdGhpcyBpcyBhIGh5 cG90aGV0aWNhbCBwcm90b2NvbCB0aGF0IHRoYW5rZnVsbHkgZG9lc24ndCBleGlzdC4gPGJyPg0K PC9wPg0KPHA+SSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IHRoYXQgSUVURiBzaG91bGQgbm90 IHByb2R1Y2Ugc3RhbmRhcmRzIHdpdGggZ2Fwcy4gQnV0IHRoZSBzb2x1dGlvbiBpcyBub3QgdG8g ZmlsbCB0aG9zZSBnYXBzLiBBIGJldHRlciBzb2x1dGlvbiBpcyB0aGF0IG91ciBwcm90b2NvbHMg c2hvdWxkbid0IGhhdmUgdG9vIG1hbnkgZGVwZW5kZW5jaWVzIGluIHRoZSBmaXJzdCBwbGFjZS4N Cjxicj4NCjwvcD4NCjxwPi0tTW9oaXQ8YnI+DQo8L3A+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w cmVmaXgiPk9uIDkvMTIvMTkgMTE6MjggUE0sIEJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjg2ZDdmNTYwLWViNDUt ZmVjMS1jOThkLTkxZjkyYzBlMTAwNkBnbWFpbC5jb20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3Rl LXByZSIgd3JhcD0iIj5IaSBNb2hpdCwNCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+V2l0aCBteSBsaW1pdGVkIA0K ZXhwZXJpZW5jZSBvZiBJRVRGLCBJIGNlcnRhaW5seSBkb24ndCB0aGluayBJRVRGIGlzIGluIHRo ZSBidXNpbmVzcyBvZiANCmJ1aWxkaW5nIGVjb3N5c3RlbXMNCjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4NCk5vLCBidXQgdGhlIG9wZW4g c291cmNlIGNvbW11bml0eSB0aGF0IHVzZXMgb3VyIHN0YW5kYXJkcyBkZWZpbml0ZWx5IGlzIGlu DQp0aGF0IGJ1c2luZXNzLCBzbyBpbnRlcm9wZXJhYmxlIHN0YW5kYXJkcyBuZWVkIHRvIGhlbHAg c3VjaCB3b3JrLg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFz cz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4oYW5kIG5laXRoZXIgc2hvdWxkIGl0IGJlKS4NCjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4N Ckhvd2V2ZXIsIHRoZSBJRVRGIHNob3VsZCBub3QgcHJvZHVjZSBzdGFuZGFyZHMgd2l0aCBnYXBz IHRoYXQgZW5jb3VyYWdlDQpwcm9wcmlldGFyeSBlY29zeXN0ZW1zIHRoYXQgYWxsb3cgY3VzdG9t ZXIgY2FwdHVyZS4gVGhhdCdzIGV4YWN0bHkgd2h5IEFOSU1BDQppbmNsdWRlcyBhIHJlZmVyZW5j ZSBtb2RlbCBhcyB3ZWxsIGFzIHNwZWNpZmljIHN0YW5kYXJkcy4gSXQgZW5jb3VyYWdlcyBlYWNo DQp2ZW5kb3IgdG8gcHJvdmlkZSBhIE1BU0EgYW5kIGVuY291cmFnZXMgbmV0d29yayBvcGVyYXRv cnMgdG8gbWl4IGFuZCBtYXRjaA0KcHJvZHVjdHMgZnJvbSBtdWx0aXBsZSB2ZW5kb3JzLg0KDQpX aGV0aGVyIHRoZSBCUlNLSS9NQVNBIG1vZGVsIGdlbmVyYWxpc2VzIGJleW9uZCBhdXRvbm9taWMg bmV0d29ya3MgcmVtYWlucyB0bw0Kc2VlbiwgYnV0IGFnYWluOiBpdCB3YXMgbm90IGRlc2lnbmVk IGZvciBJb1QuDQoNClJlZ2FyZHMNCiAgIEJyaWFuIENhcnBlbnRlcg0KDQpPbiAxMi1TZXAtMTkg MjM6MzMsIE1vaGl0IFNldGhpIE0gd3JvdGU6DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5IaSBCcmlhbiwNCg0KSUVU RiBpcyBpbiB0aGUgYnVzaW5lc3Mgb2YgYnVpbGRpbmcgdG9vbHMgKGkuZS4gb3BlbiBzcGVjaWZp Y2F0aW9ucyB3aXRoIA0KcnVubmluZyBjb2RlKSBmb3IgZGV2ZWxvcGVycy4gQW5kIHRoZXNlIHRv b2xzIGFyZSBiZXN0IGJ1aWx0IGluIHdvcmtpbmcgDQpncm91cHMgd2hpY2ggaGF2ZSB0aGUgZXhw ZXJ0aXNlIG9uIHRoZW0uIE1vc3QgcGVvcGxlIG91dHNpZGUgdGhlIEFOSU1BIA0KY29tbXVuaXR5 IHdvdWxkIG5vdCBrbm93IHdoYXQgaXMgYSBNQVNBLiBTaW1pbGFybHksIG1vc3QgcGVvcGxlIG91 dHNpZGUgDQp0aGUgRU1VIGNvbW11bml0eSB3b3VsZCBub3Qga25vdyB0aGF0IFNlc3Npb24tSWRz IGZvciBmYXN0IA0KcmUtYXV0aGVudGljYXRpb24gbXVzdCBiZSBleHBvcnRlZCBieSBhbGwgRUFQ IG1ldGhvZHMuDQoNCkkgYWdyZWUgd2l0aCBmb2xrcyB0aGF0IHRoZXJlIG1heSBiZSBtdWx0aXBs ZSBzb2x1dGlvbnMgdGhhdCBhcmUgDQpyZWxldmFudCB0byB0aGUgYm9vdHN0cmFwcGluZyBwcm9i bGVtLiBCdXQgZWFjaCBvZiB0aG9zZSBzaG91bGQgDQpkZXZlbG9wZWQgaW4gd29ya2luZyBncm91 cHMgd2hlcmUgdGhlIHJlbGV2YW50IGV4cGVydGlzZSBpcyBwcmVzZW50LiBPbmUgDQpjb3VsZCBh cmd1ZSB0aGF0IHRoYXQgd2Ugd291bGQgZW5kIHVwIGRldmVsb3BpbmcgZGlmZmVyZW50IHNvbHV0 aW9ucyBmb3IgDQp0aGUgc2FtZSBwcm9ibGVtIGluIHNpbG9zLiBIb3dldmVyIHRoaXMgd2h5IHdl IGhhdmUgdGhlIElFU0cgLHRoZSANCmRpcmVjdG9yYXRlcywgYW5kIGxpYWlzb25zIHRvIG90aGVy IHN0YW5kYXJkcyBib2RpZXMuIEl0IGVuc3VyZXMgdGhhdCB3ZSANCmFyZSBhd2FyZSBvZiByZWxh dGVkIHdvcmsgb25nb2luZyBpbiBkaWZmZXJlbnQgZm9yYS4gV2l0aCBteSBsaW1pdGVkIA0KZXhw ZXJpZW5jZSBvZiBJRVRGLCBJIGNlcnRhaW5seSBkb24ndCB0aGluayBJRVRGIGlzIGluIHRoZSBi dXNpbmVzcyBvZiANCmJ1aWxkaW5nIGVjb3N5c3RlbXMgKGFuZCBuZWl0aGVyIHNob3VsZCBpdCBi ZSkuDQoNCi0tTW9oaXQNCg0KT24gOS8xMS8xOSAxMTozNSBQTSwgQnJpYW4gRSBDYXJwZW50ZXIg d3JvdGU6DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96 LXF1b3RlLXByZSIgd3JhcD0iIj5IaSBNb2hpdCwNCg0KT24gMTItU2VwLTE5IDA3OjIxLCBNb2hp dCBTZXRoaSBNIHdyb3RlOg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUg Y2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+SGkgTWljaGFlbCwNCg0KSSB3b25kZXIgd2h5 IGEgbmV3IHdvcmtpbmcgZ3JvdXAgaXMgbmVlZGVkIGFuZCB3aHkgdGhpcyB3b3JrIGNhbm5vdCBi ZSBwdXJzdWVkIGluIHNvbWUgb2YgdGhlIGV4aXN0aW5nIHdvcmtpbmcgZ3JvdXBzPw0KDQpJIHN1 cHBvc2UgQU5JTUEgd2FzIHJlY2VudGx5IHJlLWNoYXJ0ZXJlZCAoYW5kIGNhbiBiZSByZS1jaGFy dGVyZWQgYWdhaW4pLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVv dGUtcHJlIiB3cmFwPSIiPldlJ3ZlIGJlZW4gdmVyeSBpbnNpc3RlbnQgdGhhdCBBTklNQSBpcyBz Y29wZWQgZm9yIHByb2Zlc3Npb25hbGx5IG1hbmFnZWQgbmV0d29ya3MuIFRoYXQgaXMgbm90LCBJ TUhPLCBhIHJlYXNvbmFibGUgcmVzdHJpY3Rpb24gZm9yIElvVDsgc28gdGhlIEFOSU1BIHNjb3Bl IGlzIG5hcnJvd2VyLiBBbHNvLCBBTklNQSBpcyBzY29wZWQgZm9yIGF1dG9ub21pYyBtYW5hZ2Vt ZW50LCB3aXRoIGJvb3RzdHJhcCBhbmQgc2VjdXJpdHkgYmVpbmcgb25seSBwYXJ0IG9mIHRoZSBy ZXF1aXJlbWVudHM7IGluIHRoYXQgc2Vuc2UsIHRoZSBBTklNQSBzY29wZSBpcyBicm9hZGVyLg0K DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3Rl LXByZSIgd3JhcD0iIj5FTVUgaXMgY3VycmVudGx5IGdvaW5nIG92ZXIgdGhlIHJlLWNoYXJ0ZXIg dGV4dC4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIg d3JhcD0iIj5JIGtub3cgbGl0dGxlIGFib3V0IEVBUCwgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQg YWx0aG91Z2ggaXQgbWF5IHdlbGwgYmUgYSBwcmltYXJ5IHRvb2wgZm9yIG9uLWJvYXJkaW5nLCBp dCBpcyBvbmx5IGEgdG9vbCwgYW5kIG5vdCBhIGNvbXBsZXRlIGVjb3N5c3RlbS4gVGhlICZxdW90 O1RoaW5raW5nIHRocm91Z2ggb25ib2FyZGluZyZxdW90OyB0aHJlYWQgc2NvcGVzIHRoZSB3aWRl ciBwcm9ibGVtIG5pY2VseS4NCg0KUmVnYXJkcw0KICAgIEJyaWFuDQo8L3ByZT4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5BbHNv LCB5b3Ugd3JpdGU6DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIGNs YXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPmFkb3B0IGEgY2xvdWQtbGVzcyAoTUFTQS1sZXNz LCBBQUEtbGVzcykgb25ib2FyZGluZyBtZWNoYW5pc20gKHBvc3NpYmx5IGEgdmVyc2lvbiBvZiBF QVAtTk9PQiksDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1w cmUiIHdyYXA9IiI+VGhlcmUgaXMgY2xlYXJseSBzb21lIG1pc3VuZGVyc3RhbmRpbmcgYWJvdXQg RUFQLU5PT0IgaGVyZS4gRUFQLU5PT0IgaXMgc3BlY2lmaWNhbGx5IGludGVuZGVkIGZvciByZWdp c3RlcmluZyBuZXcgSW9UIGRldmljZXMgb24gYSBzZXJ2ZXIgKGFuZCBhc3NvY2lhdGluZyBpdCB3 aXRoIGEgdXNlciBhY2NvdW50KS4gVGhlIGZhY3QgdGhhdCBpdCBwcm92aWRlcyBuZXR3b3JrLWFj Y2VzcyBjcmVkZW50aWFscyBpcyBhIGJvbnVzLiBQbGVhc2UgaGF2ZSBhIGxvb2sgYXQgc2xpZGVz IDMtMTAgaGVyZTogPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1z ZWNkaXNwYXRjaC1uaW1ibGUtb3V0LW9mLWJhbmQtYXV0aGVudGljYXRpb24tZm9yLWVhcC1lYXAt bm9vYi1kcmFmdC1hdXJhLWVhcC1ub29iLTA0LTAxIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLXNlY2Rpc3BhdGNoLW5pbWJsZS1v dXQtb2YtYmFuZC1hdXRoZW50aWNhdGlvbi1mb3ItZWFwLWVhcC1ub29iLWRyYWZ0LWF1cmEtZWFw LW5vb2ItMDQtMDE8L2E+DQoNCllvdSBjbGVhcmx5IHNlZSBhIEFBQSBzZXJ2ZXIgaW4gdGhlIGZp Z3VyZXMuIFNvIGNhbGxpbmcgaXQgQUFBLWxlc3MgZG9lc24ndCBtYWtlIHNlbnNlLg0KDQotLU1v aGl0DQoNCk9uIDkvNC8xOSAxMDo0NSBBTSwgTWljaGFlbCBSaWNoYXJkc29uIHdyb3RlOg0KPC9w cmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUi IHdyYXA9IiI+SSB3cm90ZSB0aGlzIGxhc3Qgd2VlaywgYW5kIHBhc3NlZCBpdCBhcm91bmQgZm9y IG9idmlvdXMgb2JqZWN0aW9ucy4NCiAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0 IiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWNyL2lvdHdnLWNoYXJ0ZXIvYmxvYi9tYXN0ZXIv aW90d2ctY2hhcnRlci5tZCI+aHR0cHM6Ly9naXRodWIuY29tL21jci9pb3R3Zy1jaGFydGVyL2Js b2IvbWFzdGVyL2lvdHdnLWNoYXJ0ZXIubWQ8L2E+DQpZb3UgY2FuIHVzZSB0aGUgY3JheW9uL2Vk aXQgYnV0dG9uIG9uIGdpdGh1YiB0byBzdWdnZXN0IGNoYW5nZXMsIG9yIGVtYWlsLg0KDQoNCkNo YXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXANCg0KVGhlIHdvcmRzICZxdW90O0ludGVybmV0IG9mIFRo aW5ncyZxdW90OyBvciBJb1QgaGF2ZSBjb21lIHRvIG1lYW4gYW55dGhpbmcgYW5kDQpldmVyeXRo aW5nIHRvIGEgd2lkZSBncm91cCBvZiB0ZWNobm9sb2d5IHBsYXllcnMuIFRoZSBJRVRGIGhhcyBi ZWVuIHdvcmtpbmcNCm9uIGEgd2lkZSB2YXJpZXR5IG9mIHByb3RvY29scyBmb3IgdXNlIGJ5IG1h Y2hpbmUgdG8gbWFjaGluZQ0KY29tbXVuaWNhdGlvbi4gVGhpcyBpbmNsdWRlIENvQVAsIENCT1Is IDZUSVNDSCwgUk9MTCwgU1VJVCwgTkVUQ09ORiBTWlRQLA0KVDJUUkcsIEFOSU1BJ3MgQlJTS0kg b25ib2FyZGluZyBwcm90b2NvbCwgYW5kIG1vc3QgcmVjZW50bHkgUkZDODUyMCwgdGhlDQpNYW51 ZmFjdHVyZXIgVXNhZ2UgRGVzY3JpcHRpb24uDQoNClRoZSBJRVRGIGhhcyB0cmllZCB0byBmb2N1 cyBvbiBjYXRlZ29yaWVzIG9mIHdoYXQgbGltaXRlZCB0aGluZ3MgY2FuIGRvLCBhbmQNCnRoaXMg aGFzIHJlc3VsdGVkIGluIGEgbnVtYmVyIG9mIHVzZWZ1bCBkb2N1bWVudHMgZnJvbSB0aGUgTGln aHQtV2VpZ2h0DQpJbXBsZW1lbnRhdGlvbiBHdWlkZSAoTFdJRykuIFJGQzcyMjggaXMgYSBrZXkg cHJvZHVjdCwgaGF2aW5nIHByb3ZpZGVkDQp0ZXJtaW5vbG9neSBhbmQgc2NhbGluZyB1bmRlcnN0 YW5kaW5nIHRvIHRoZSBlbnRpcmUgaW5kdXN0cnkuIEFsbCBvZiB0aGlzIGhhcw0KYmVlbiBhYm91 dCBzY2FsaW5nIHRoZSBJbnRlcm5ldCB0ZWNobm9sb2dpZXMgdG8gc21hbGwgZGV2aWNlcyBhbmQg Y29uc3RyYWluZWQNCm5ldHdvcmtzLiBJbiBhZ2dyZWdhdGUsIHRoZXNlIGRldmljZXMgb24gc21h bGwgbmV0d29ya3MgcHJlc2VudCBhIHNpZ25pZmljYW50DQpvcGVyYXRpb25hbCByaXNrIHRvIHRo ZSBJbnRlcm5ldCBhcyBhIHdob2xlLCBhbmQgZXZlbiB0byBpbmRpdmlkdWFsDQpFbnRlcnByaXNl LCBzaW1wbHkgZHVlIHRvIHRoZWlyIG51bWJlcnMsIGFuZCBsYWNrIG9mIG9wcG9ydHVuaXR5IGZv ciByZWd1bGFyDQpodW1hbiBzdXBlcnZpc2lvbi4NCg0KSW9UIGRldmljZXMgYWxyZWFkeSBleGlz dCB0b2RheSBpbiB2YXN0IG51bWJlcnMuIE1vc3QgZGV2aWNlcyB0aGF0IHBlb3BsZSBhcmUNCnBl cnNvbmFsbHkgZmFtaWxpYXIgd2l0aCBhcmUgaW4gdGhlIEJsdWVUb290aCBDb25uZWN0ZWQgZGV2 aWNlcywgb3INCldlYi1Db25uZWN0ZWQgZGV2aWNlcyB0aGF0IHVzZSBXaUZpIHRvIHJlYWNoIHNl cnZlcnMgb24gdGhlIEludGVybmV0ICgmcXVvdDt0aGUNCkNsb3VkJnF1b3Q7KS4gSW5jcmVhc2lu Z2x5LCB0aGUgSUVURiB2aWV3IG9mIG1hY2hpbmUgdG8gbWFjaGluZSBjb21tdW5pY2F0aW9ucyBh cmUNCmNvbGluaXppbmcgbmV3IGdyZWVuZmllbGQgc2l0dWF0aW9ucy4gVGhlIElFVEYgbm90aW9u IG9mIGF1dG9ub21vdXMgbmV0d29ya3MNCm9mIGRldmljZXMgaXMgc3RpbGwgYSBtaW5vcml0eSB2 aWV3IGNvbXBhcmVkIHRvIHRoZSBtYXJrZXQgSW9UIGluZHVzdHJ5IG9mDQpjbG91ZC1vbmx5IGNv bm5lY3RlZCBkZXZpY2VzLCBidXQgdGhlIHRyYW5zaXRpb24gaXMgb2NjdXJpbmcuDQoNClJGQzg1 MjAgd2FzIGNyZWF0ZWQgdG8gYnJpZGdlIHRoZSBnYXAgYmV0d2VlbiBkZXZpY2VzIHdob2xseSBj b250cm9sbGVkIGJ5IGENCmxvY2FsIG9wZXJhdG9yIChzdWNoIGFzIEVudGVycHJpc2UgSVQpLCBh bmQgZGV2aWNlcyB3aGljaCBjYW4gbm90IGFzc3VtZSBhbnkNCmluZnJhc3RydWN0dXJlIGF0IGFs bCwgYW5kIG11c3QgcmVseSBlbnRpcmVseSBvbiBjbG91ZCBjb21tdW5pY2F0aW9ucyBmb3INCmNv bW1hbmQgYW5kIGNvbnRyb2wuDQoNClRoaXMgd29ya2luZyBncm91cCBjb25jZXJucyBpdHNlbGYg d2l0aCBPcGVyYXRpb25hbCBTZWN1cml0eSBvZiBJb1Qgc3lzdGVtcy4NCg0KVGhpcyBpbmNsdWRl czoNCg0KKiBmYWN0b3J5IHByb3Zpc2lvbmluZyBvZiBkZXZpY2VzDQoqIG9uYm9hcmRpbmcgb2Yg ZGV2aWNlcw0KKiBhY2Nlc3MgY29udHJvbCBvZiBkZXZpY2VzIHRvIG5ldHdvcmsgcmVzb3VyY2Vz DQoqIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wgb2YgZGV2aWNlcw0KKiBhc3NldCBtYW5hZ2VtZW50 IG9mIGRldmljZXMsIGFzIGl0IHBlcnRhaW5zIHRvIHNvZnR3YXJlL2Zpcm13YXJlIHZlcnNpb25z DQoqIGlzb2xhdGlvbi9xdWFyYW50aW5lIG9mIGRldmljZXMNCiogcmVtZWRpYXRpb24gb2YgYnJv a2VuIGRldmljZXMNCiogZW5kIG9mIGxpZmUgbWFuYWdlbWVudCBvZiBkZXZpY2VzDQoNClRoZSBX RyBpcyBjaGFydGVyZWQgZXhwbGljaXRlbHkgdG8gd29yayBvbiBNVUQgKFJGQzg1MjApIGFuZCBl eHRlbnNpb25zIHRvIGl0Lg0KDQpUaGUgV0cgaXMgY2hhcnRlcmVkIHRvIHdvcmsgb24gb25ib2Fy ZGluZyBwcm90b2NvbHMsIHNwZWNpZmljYWxseSBpbmNsdWRpbmcNCmRlcml2YXRpZXMgb2YgQlJT S0kgKFJGQy10YmQpLCBidXQgbm90IGxpbWl0ZWQgdG8ganVzdCB0aGF0IHByb3RvY29sLg0KDQpU aGUgV0cgaXMgbm90IGV4cGVjdGVkIHRvIHBpY2sgYSB3aW5uZXIsIGFuZCBpcyBlbmNvdXJhZ2Vk IHRvIHdvcmsgb24gYQ0KbXVsdGl0dWRlIG9mIHVzZS1jYXNlIHNwZWNpZmljIHByb3RvY29sczog YmV0dGVyIHRvIGdldCBvbmUgdXNlIGNhc2UgcmlnaHQsDQp0aGFuIHRvIGJlIHRvby1jb21wbGV4 IGphY2sgb2YgYWxsIHRyYWRlcy4NCg0KVGhlIFdHIGlzIGV4cGVjdGVkIHRvIGFydGljdWxhdGUg Y2xlYXIgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnRzIGZvciBlYWNoDQpwcm90b2NvbC4gVGhlIFdH IGlzIGV4cGVjdGVkIHRvIHByb2R1Y2UgY29uY2lzZSBSb2FkbWFwIGRvY3VtZW50cyB0aGF0DQpl eHBsYWluIGhvdyBhIHZhcmlldHkgb2YgSUVURiAoYW5kIG90aGVyKSBwcm90b2NvbHMgY2FuIHdv cmsgdG9nZXRoZXIgdG8NCnNhdGlzZnkgdGhlIE9wZXJhdGlvbmFsIG5lZWRzIG9mIHNwZWNpZmlj IElvVCBhcmVhcy4gVGhlc2Ugcm9hZG1hcCBkb2N1bWVudHMNCm5lZWRu4oCZdCByZXN1bHQgaW4g UkZDcy4NCg0KTmVpdGhlciB0aGUgV0cgbm9yIHRoZSBJRVRGIGhhcyBleGNsdXNpdml0eSBoZXJl LCBhbmQgYW4gaWRlYWwgZG9jdW1lbnQgd291bGQNCmJlIG9uZSB0aGF0IHRoZSBXRyBoZWxwcyB0 byBzdGFydCwgYnV0IGEgc3BlY2lmaWMgaW5kdXN0cnkgYWxsaWFuY2UgYmVjb21lcw0KdGhlIGxl YWQgZWRpdG9yIGZvci4NCg0KVGhlcmUgd2lsbCBiZSBjb29yZGluYXRpb24gd2l0aCBtYW55IG90 aGVyIFdHcyBiZXlvbmQgdGhlIGxpc3QgYWJvdmUsIGFuZA0KdGhpcyBXRyBtYXkgYWNjZXB0IGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50IHdvcmsgZnJvbSBvdGhlciBXR3MgYWJvdXQgc3BlY2lmaWMN CndheXMgdG8gZGVwbG95IHRoZWlyIHByb3RvY29scy4NCg0KVGhlIFdHIHdpbGwgb3BlcmF0ZSB0 aHJvdWdoIGEgc2VyaWVzIG9mIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5ncy4gVGhpcyBpcw0KZHJp dmVuIGJ5IGEgbmVlZCB0byBpbnRlcmFjdCByZWd1bGFybHkgd2l0aCBvdGhlciBpbmR1c3RyeSBn cm91b3BzLCBhbmQgZHVlDQp0byB0aGUgdmFyaWV0eSBvZiB0b3BpY3Mgd2hpY2ggd2lsbCBub3Qg YWx3YXlzIGJlIGFibGUgdG8gZ2V0IHF1b3J1bSBhcyBhDQpjb21taXR0ZWUgb2YgdGhlIHdob2xl Lg0KDQp7dW51c3VhbCwgbWF5YmUgbm90IGNoYXJ0ZXIgYXBwcm9wcmlhdGUsIGJ1dCByYXRoZXIg c2FhZy1saWtlfQ0KRHVyaW5nIGluLXBlcnNvbiBtZWV0aW5ncywgdGhlIFdHIHdpbGwgZGVhbCB3 aXRoIHR5cGljYWwgc3RhdHVzIGFuZCBkb2N1bWVudA0KcHJvZ3Jlc3MgaXNzdWVzIGR1cmluZyBv bmUgaG91ciAob3IgbGVzcykgb2YgdGhlIHRpbWUsIGFuZCBkdXJpbmcgYW5vdGhlcg0KaG91ciwg d2lsbCBiZSBvcGVuIHRvIHNsaWRld2FyZSBwcmVzZW50YXRpb25zIGFuZCB0dXRvcmlhbHMgb24g Y3VycmVudCBJRVRGDQpvciBvdGhlci1TRE8gSW9UIGVmZm9ydHMuIFRoZSBnb2FsIG9mIHRoZXNl IHByZXNlbnRhdGlvbnMgaXMgdG8gcXVpY2tseQ0KY29tbXVuaWNhdGUgY3VycmVudCBJb1Qgc3lz dGVtcyBzdGF0ZSB0byB0aGUgcmVzdCBvZiB0aGUgSUVURi4NCg0KSXQgaXMgYWNrbm93bGVkZ2Vk IHRoYXQgcGFydCBvZiB0aGUgdmFsdWUgaXMgaW4gWW91VHViZSBjb250ZW50LCBhbmQgc29tZQ0K Y29udGVudCBzaG91bGQgYmUgZG9uZSBhdCBJQUIgdGVjaCBwbGVuYXJpZXMgcmF0aGVyIHRoYW4g YXQgdGhlIFdHLg0KDQpUaGUgaW5pdGlhbCBzZXQgb2Ygd29yayBpdGVtcyBpcyBpbmNsdWRlZCBi ZWxvdyBhcyBtaWxlc3RvbmVzLCB3aGljaCBvbmx5DQpyZXF1aXJlIEFEIGFwcHJvdmFsLg0KDQpN aWxlc3RvbmVzDQoNCiogYWRvcHQgdGhlIGNvbnN0cmFpbmVkLXZvdWNoZXIvY29uc3RyYWluZWQt QlJTS0kgd29yayBmcm9tIEFOSU1BLg0KKiBhZG9wdCB0aGUgZHRzZWN1cml0eS16ZXJvLXRvdWNo IHdvcmsgZnJvbSA2dGlzY2gsIHdoaWNoIGNhbiBub3QgZmluaXNoIGJlZm9yZSBhIExBS0UgZmlu aXNoZXMuDQoqIGNyZWF0ZSBhIGxpc3Qgb2YgYSBzZXJpZXMgb2YgTVVEIGV4dGVuc2lvbnMsIGFu ZCByZXZpc2UgdGhpcyBtaWxlc3RvbmUNCiogYWRvcHQgYSBjbG91ZC1sZXNzIChNQVNBLWxlc3Ms IEFBQS1sZXNzKSBvbmJvYXJkaW5nIG1lY2hhbmlzbSAocG9zc2libHkgYSB2ZXJzaW9uIG9mIEVB UC1OT09CKSwgdGhhdCBjYW4gYmUgdXNlZCBhdCB0aGUgcmV0YWlsIGxldmVsLg0KKiBuZWdvdGlh dGUgd2l0aCBFTVUgV0cgb24gaG93IHRvIHByb2NlZWQgd2l0aCBURUFQLUJSU0tJLCBhbmQgcmV2 aXNlIHRoaXMgbWlsZXN0b25lLg0KKiBhZG9wdCBhIGNsb3VkLWRyaXZlbiBvbmJvYXJkaW5nIG1l Y2hhbmlzbSB0aGF0IGNhbiBiZSB1c2VkIGluIGNvbXBsZXRlbHkgb2ZmbGluZSBzaXR1YXRpb25z IHdpdGhvdXQgcmVxdWlyaW5nIHJlbmV3YWxzIChwZXJoYXBzIHJldmlzaW5nIFJGQzgzNjYpLg0K Li4uLg0KDQoNCg0KDQoNCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3Jh cD0iIj4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_202e4ac06bdb41401a84812390667b4dericssoncom_-- From nobody Mon Sep 16 04:26:05 2019 Return-Path: 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 552B4120019; Mon, 16 Sep 2019 04:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WdbpA9qSlm4F; Mon, 16 Sep 2019 04:26:00 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632B9120837; Mon, 16 Sep 2019 04:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28012; q=dns/txt; s=iport; t=1568633159; x=1569842759; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=tix3KOgNYl6HFxtOAkmhBx5rgQQ/QNNOIbtwIOXwPpc=; b=FVfSEasDRbZHYLxL7e1h8TneStRqUZkP7EAv8p+tlKqEeN5eLDRU8Bcg T+h511OSKl8ULvpea4qWD+w/SOkehiNe8y9CaIDl1iPVUpXqdnoUCduWM VcQkSMHyBCUnSl+jWurc0btHMhOHZElRP9E7jcufdWJ4f8J0xlWN4n4G5 E=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAABocH9d/xbLJq1gBhoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgWeBaQWBF1MgEiqEIYh8iBl+mDWBYwQCBwEBAQkDAQEYAQU?= =?us-ascii?q?RAQGBS4J0AoMSOBMCAwkBAQQBAQECAQUEbYUuDIVKAQEBAQIBAQEYCUgDCwU?= =?us-ascii?q?LCxIGFRUCAiciDgYTFAUCgwcBgXsPD6oJgUqBMh+EGAEDAgEBDw9vhGoKBoE?= =?us-ascii?q?0gVGKP4F/gREnH4FOSQcuPoJhAQECAYEZCQkBCwcBCQhNgkwygiYEf4t+Cg8?= =?us-ascii?q?DiFiWeYIsgi6BE4NEjXsbgjWHR4N+ix+KEYwEjWWDEQIEBgUCFYFpIWdxMxo?= =?us-ascii?q?IGxU7KgGCQT6CCzFvAQmCQYUUhUE+AzABAQGOHw8Xgi4BAQ?= X-IronPort-AV: E=Sophos;i="5.64,512,1559520000"; d="asc'?scan'208,217";a="16861838" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Sep 2019 11:25:56 +0000 Received: from [10.61.225.65] ([10.61.225.65]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8GBPtCI027680 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Sep 2019 11:25:56 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7B7D88EC-12BC-464B-B4F5-7FE078960488"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 13:25:54 +0200 In-Reply-To: <202e4ac0-6bdb-4140-1a84-812390667b4d@ericsson.com> Cc: Brian E Carpenter , Mohit Sethi M , Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" To: Mohit Sethi M 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> <202e4ac0-6bdb-4140-1a84-812390667b4d@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.225.65, [10.61.225.65] X-Outbound-Node: aer-core-4.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 11:26:03 -0000 --Apple-Mail=_7B7D88EC-12BC-464B-B4F5-7FE078960488 Content-Type: multipart/alternative; boundary="Apple-Mail=_71DA0F41-CD9C-4BF9-8429-A05E5453450E" --Apple-Mail=_71DA0F41-CD9C-4BF9-8429-A05E5453450E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Sep 2019, at 11:19, Mohit Sethi M = wrote: >=20 > Hi Brian, >=20 > 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. >=20 To a point I agree, depending on what V, W, X, Y, and Z are. If they = are things that are at all painful for any player to provide, the &ing = of those conditions make success highly unlikely. > Note that this is a hypothetical protocol that thankfully doesn't = exist. >=20 > 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. >=20 To me I think we are still in early days, all of us, on this problem. = Protocols like SZTP or BRSKI or the TEAP extensions we are doing = probably require a bit of reconciliation. What is key, at least for = cloud-based provisioning, is the voucher. What is also key, it seems to = me, is an interface like EST. What we heard in our call with Randy, for instance, was that in that = vertical, we have to take into account lengthy SI chains, and we have to = do so without client interactions. One way to address this from an = onboarding perspective is to really drive an architecture document such = that the components can be shown to fit well together, in a bit of a = plug and play mode. That discussion, it seems to me, could easily drown out all other = discussions and seems quite disparate from MUD in particular, which = leads me to wonder again if we are being too broad. Eliot > --Mohit >=20 > On 9/12/19 11:28 PM, Brian E Carpenter wrote: >> Hi Mohit, >>=20 >>> 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. >>=20 >>> (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. >>=20 >> Whether the BRSKI/MASA model generalises beyond autonomic networks = remains to >> seen, but again: it was not designed for IoT. >>=20 >> Regards >> Brian Carpenter >>=20 >> On 12-Sep-19 23:33, Mohit Sethi M wrote: >>> Hi Brian, >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> --Mohit >>>=20 >>> On 9/11/19 11:35 PM, Brian E Carpenter wrote: >>>> Hi Mohit, >>>>=20 >>>> On 12-Sep-19 07:21, Mohit Sethi M wrote: >>>>> Hi Michael, >>>>>=20 >>>>> I wonder why a new working group is needed and why this work = cannot be pursued in some of the existing working groups? >>>>>=20 >>>>> 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. >>>>=20 >>>>> 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. >>>>=20 >>>> Regards >>>> Brian >>>>> Also, you write: >>>>>=20 >>>>>> 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 = >>>>>=20 >>>>> You clearly see a AAA server in the figures. So calling it = AAA-less doesn't make sense. >>>>>=20 >>>>> --Mohit >>>>>=20 >>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>> Charter for Working Group >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> This working group concerns itself with Operational Security of = IoT systems. >>>>>>=20 >>>>>> This includes: >>>>>>=20 >>>>>> * 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 >>>>>>=20 >>>>>> The WG is chartered explicitely to work on MUD (RFC8520) and = extensions to it. >>>>>>=20 >>>>>> The WG is chartered to work on onboarding protocols, specifically = including >>>>>> derivaties of BRSKI (RFC-tbd), but not limited to just that = protocol. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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=E2=80=99t result in RFCs. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> {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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> The initial set of work items is included below as milestones, = which only >>>>>> require AD approval. >>>>>>=20 >>>>>> Milestones >>>>>>=20 >>>>>> * 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). >>>>>> .... >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding --Apple-Mail=_71DA0F41-CD9C-4BF9-8429-A05E5453450E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16 Sep 2019, at 11:19, Mohit Sethi M <mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> = wrote:

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. 


To = a point I agree, depending on what V, W, X, Y, and Z are.  If they = are things that are at all painful for any player to provide, the = &ing of those conditions make success highly unlikely. 

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.


To = me I think we are still in early days, all of us, on this problem. = Protocols like SZTP or BRSKI or the TEAP extensions we are doing = probably require a bit of reconciliation.  What is key, at least = for cloud-based provisioning, is the voucher.  What is also key, it = seems to me, is an interface like EST.

What we heard in our call with Randy, for = instance, was that in that vertical, we have to take into account = lengthy SI chains, and we have to do so without client interactions. =  One way to address this from an onboarding perspective is to = really drive an architecture document such that the components can be = shown to fit well together, in a bit of a plug and play = mode.

That discussion, it seems to = me, could easily drown out all other discussions and seems quite = disparate from MUD in particular, which leads me to wonder again if we = are being too broad.

Eliot

--Mohit

On 9/12/19 11:28 PM, Brian E Carpenter = wrote:
Hi Mohit,


With my limited=20
experience of IETF, I certainly don't think IETF is in the business of=20=

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=20=

running code) for developers. And these tools are best built in working=20=

groups which have the expertise on them. Most people outside the ANIMA=20=

community would not know what is a MASA. Similarly, most people outside=20=

the EMU community would not know that Session-Ids for fast=20
re-authentication must be exported by all EAP methods.

I agree with folks that there may be multiple solutions that are=20
relevant to the bootstrapping problem. But each of those should=20
developed in working groups where the relevant expertise is present. One=20=

could argue that that we would end up developing different solutions for=20=

the same problem in silos. However this why we have the IESG ,the=20
directorates, and liaisons to other standards bodies. It ensures that we=20=

are aware of related work ongoing in different fora. With my limited=20
experience of IETF, I certainly don't think IETF is in the business of=20=

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=E2=80=99t 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 mailing list
Iot-onboarding@ietf.org
https://www.ietf.org/mailman/listinfo/iot-onboarding

=

--Apple-Mail=_71DA0F41-CD9C-4BF9-8429-A05E5453450E--

--Apple-Mail=_7B7D88EC-12BC-464B-B4F5-7FE078960488
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl1/cUIACgkQh7ZrRtnS
ejN2Sgf/Zf3MdiHLEqAdRAa6qaJL8JtjAt4WeWe05U3pbXdZhIrhd21W3sz1tXh+
4Ru7TiUuLGPHpvM0LObT0K7gokEqAofvAIVf1LGmdIvz1sgf4s8IfzNFZNGY2gBv
9YyeCh23TApIgj3bmdWtoKebvDm8003z0O4adjlCY68KJArCmt6Auq605EvF1IKv
3uSfcLoG4Afn3COE+WLiXmU+ECHNrGrbub14xHW4NKYxItZhD0cOV9tX01wR+/N/
U7te2tfph0sdTVuPerzdXHwUwiHF7aB5dkUT35FQij1yX3SPbSvsFG7JlMLeEMod
BLXH0ZZJeQqBzVyp6PdbNakeIW+Hew==
=PMVH
-----END PGP SIGNATURE-----

--Apple-Mail=_7B7D88EC-12BC-464B-B4F5-7FE078960488--


From nobody Wed Sep 18 02:28:44 2019
Return-Path: 
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 B6996120170; Wed, 18 Sep 2019 02:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Iasa0eKKeCnq; Wed, 18 Sep 2019 02:28:41 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7C4120168; Wed, 18 Sep 2019 02:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8329; q=dns/txt; s=iport; t=1568798920; x=1570008520; h=from:mime-version:subject:message-id:references:to:date; bh=+XweeLmNMoYi48d+JPYmUizyJdeXqqfp9Ti7nL2wGs8=; b=akvp4YFjZK4tv0PFu+lJRWST+oIAKiJeEn9zmZ3rfTfuDn+VuiLcmKYg txepTvEYnrGAKzoH7uC/pEDsPvUMdiU943uIOkwQV+0ZRPn3As4AeF1Lp QHoXFA2nQM6MtP2Xp73Y/Fz3Y6JQh1suXHnVOcPLC36OUZ9CE4/GamPcJ E=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAA1+IFd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVQIBAQEBAQsBgwRTIBIqhCKIfIghfpIYhguBewIHAQE?= =?us-ascii?q?BCQMBASMMAQGEPwKDJTYHDgIDCQEBBAEBAQIBBQRthS0MhUoBAQQBI1sLHAM?= =?us-ascii?q?BAisCAkYHAggHEoMiAYF7Dw+wQoEyhDcBAwGFcQoGgTQBgVCKUIF/gREnH4I?= =?us-ascii?q?XNT6BBIFdAoIBgmsygiYEjFuJH5Z+giyCLoETg0SNfhuCNodLg36LIY4PgTm?= =?us-ascii?q?GVY1qgxECBAYFAhWBWAExgVgzGggbFTsqAYINAQEyPoIciG6FQT4DMJB2AQE?=
X-IronPort-AV: E=Sophos;i="5.64,520,1559520000";  d="asc'?scan'208,217";a="16901127"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2019 09:28:36 +0000
Received: from [10.61.223.208] ([10.61.223.208]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8I9SZwt017767 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Sep 2019 09:28:36 GMT
From: Eliot Lear 
Content-Type: multipart/signed; boundary="Apple-Mail=_7B5A9083-C42F-4450-8095-145E221C51F9"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <9C16D937-ECD9-4D0D-9C2F-86DFBAE0EA3A@cisco.com>
References: <2EDDCF70-D90E-4378-A337-86C507E7C43B@cisco.com>
To: mud@ietf.org, iot-onboarding@ietf.org
Date: Wed, 18 Sep 2019 11:28:34 +0200
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.223.208, [10.61.223.208]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: [Mud] Fwd: IETF 106 Hackathon
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2019 09:28:43 -0000

--Apple-Mail=_7B5A9083-C42F-4450-8095-145E221C51F9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_523E7148-EEE1-4B7F-8EC3-957F79A01897"


--Apple-Mail=_523E7148-EEE1-4B7F-8EC3-957F79A01897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Should we all get together again?  If so, what work?  We=E2=80=99ll have =
a TEAP implementation to play with, as well as plenty more mud work to =
do.

> Begin forwarded message:
>=20
> From: "Charles Eckel (eckelcu)" 
> Subject: IETF 106 Hackathon
> Date: 17 September 2019 at 21:25:32 CEST
> To: "hackathon@ietf.org" 
> Cc: IETF chairs 
>=20
> Hi Folks,
>=20
> If you have not already, now is a good time to start making your plans =
for the hackathon.
> Registration is free but required, and it is separate from registering =
for the IETF meeting.
> More info and links to register here =
https://www.ietf.org/how/runningcode/hackathons/106-hackathon/.
>=20
> You can check the wiki for a growing list of projects. We welcome and =
encourage champions for new projects, too.
> https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon
>=20
> Champions should:
> - Before the Hackathon:
>   - Update wiki with details about their project
>   - Share ideas and any preparation materials or requirements with =
potential attendees via the hackathon list
>   - Recruit participants from associated working groups, open source =
projects, etc.
> - At the Hackathon:
>   - Make themselves available to answer questions and help others
>   - Hack on things themselves in their copious free time
>   - Champions will have table signs on their table identifying their =
project (paper and pens are provided with plastic table top signs). =
Optionally, champions may create and display posters on flip charts with =
additional information on their project.
>=20
> In addition to adding your project to the wiki, please send a note to =
hackathon@ietf.org and related IETF working groups, etc., where people =
might be interested.
>=20
> Cheers,
> Charles
>=20
> =EF=BB=BF
>=20


--Apple-Mail=_523E7148-EEE1-4B7F-8EC3-957F79A01897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Should we all get together again?  If so, what work? =
 We=E2=80=99ll have a TEAP implementation to play with, as well as =
plenty more mud work to do.

Begin forwarded =
message:

From: =
"Charles Eckel (eckelcu)" =
<eckelcu@cisco.com>
Subject: =
IETF 106 =
Hackathon
Date: =
17 September 2019 at 21:25:32 =
CEST
To: =
"hackathon@ietf.org" =
<hackathon@ietf.org>
Cc: IETF chairs <wgchairs@ietf.org>

Hi =
Folks,

If you have not already, now is a =
good time to start making your plans for the hackathon.
Registration is free but required, and it is separate from =
registering for the IETF meeting.
More info and links to =
register here https://www.ietf.org/how/runningcode/hackathons/106-hackathon/<=
/a>.

You can check the wiki for a growing =
list of projects. We welcome and encourage champions for new projects, =
too.
https://trac.ietf.org/trac/ietf/meeting/wiki/106hackathon
Champions should:
- Before the =
Hackathon:
   - Update wiki with details about =
their project
   - Share ideas and any =
preparation materials or requirements with potential attendees via the =
hackathon list
   - Recruit participants from =
associated working groups, open source projects, etc.
- At =
the Hackathon: 
   - Make themselves available =
to answer questions and help others
   - Hack on =
things themselves in their copious free time
 =
  - Champions will have table signs on their table identifying =
their project (paper and pens are provided with plastic table top =
signs). Optionally, champions may create and display posters on flip =
charts with additional information on their project.

In addition to adding your project to the wiki, please send a =
note to hackathon@ietf.org and related IETF working groups, etc., where =
people might be interested.

Cheers,
Charles

=EF=BB=BF


=

--Apple-Mail=_523E7148-EEE1-4B7F-8EC3-957F79A01897--

--Apple-Mail=_7B5A9083-C42F-4450-8095-145E221C51F9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2B+MIACgkQh7ZrRtnS
ejMJWAgAoIpgEjX17qyq9AXFFmznpDD1nTGV/6BcE/bseqQZXVaDoqMnhRnS4B0x
/cPyadCX1C25EQkyhxIY0KPeUH4O73x2mDBmDHYPt2v+E9jMo9CuLfpQ1d6nPOLX
rYUJPmkyE1DPlBboVevNDWLtBGTTq7L3GxCI2HCVFmpebcI9EKcpFG+creN8t7CJ
Zl+1db3X7MA6494SdetNES1z1yVMJbFUQ94omyRKfWUvPsK0Tzaqtfqaz6KXPAyy
mtqhWT8haqP3ANhSALIpdBVqIcp6uXc78590loVV34R6/bR0CHUqp5p6QmTrrdfE
wiSnLIEb/zH+9e9zpe5gO/nQU+XNRg==
=d5uq
-----END PGP SIGNATURE-----

--Apple-Mail=_7B5A9083-C42F-4450-8095-145E221C51F9--


From nobody Wed Sep 18 07:53:07 2019
Return-Path: 
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 4F9E812002E; Wed, 18 Sep 2019 07:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 USWN23sKY9SI; Wed, 18 Sep 2019 07:52:56 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DADF12081E; Wed, 18 Sep 2019 07:52:56 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BF513897C; Wed, 18 Sep 2019 10:51:14 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 52F63560; Wed, 18 Sep 2019 10:52:55 -0400 (EDT)
From: Michael Richardson 
To: Eliot Lear 
cc: mud@ietf.org, iot-onboarding@ietf.org
In-Reply-To: <9C16D937-ECD9-4D0D-9C2F-86DFBAE0EA3A@cisco.com>
References: <2EDDCF70-D90E-4378-A337-86C507E7C43B@cisco.com> <9C16D937-ECD9-4D0D-9C2F-86DFBAE0EA3A@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Subject: Re: [Mud] [Iot-onboarding] Fwd: IETF 106 Hackathon
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2019 14:52:59 -0000

Eliot Lear  wrote:
    > Should we all get together again?  If so, what work?  We=E2=80=99ll h=
ave a TEAP
    > implementation to play with, as well as plenty more mud work to do.

Pick one or the other.
Since I think that few of the NIST/NCCoE people will make IETF106, I suggest
TEAP-BRSKI rather than MUD.

--
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        |    IoT architect =
  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [



From nobody Fri Sep 20 10:18:57 2019
Return-Path: 
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 6D4CD120099 for ; Fri, 20 Sep 2019 10:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 u3RbnnIoBTFK for ; Fri, 20 Sep 2019 10:18:53 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA2D120130 for ; Fri, 20 Sep 2019 10:18:53 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0887B3897B for ; Fri, 20 Sep 2019 13:17:08 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4F361F5 for ; Fri, 20 Sep 2019 13:18:52 -0400 (EDT)
From: Michael Richardson 
To: mud@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Subject: [Mud] MUD file for DNS probes, avoiding non-public address space
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2019 17:18:55 -0000

--=-=-=
Content-Type: text/plain


The RIPE Atlas probes do distributed DNS monitoring.
There is a lot that a MUD file could do to restrict other unwanted traffic,
even if we have to write an ACL allowing traffic to 0.0.0.0/0 port 53.

In IPv6, it's more properly 2000::/3 port 53, which nicely rules out
DNS traffic to ULAs, link-locals, multicast, mapped IPv4 and default NAT64
space, etc.
{If 4000::/3 gets deployed by IANA, I think we'll have decades of notice}

Maybe 0.0.0.0/0 should really read:
  0.0.0.0/5     (0.0.0.0 -> 7.255.255.255)
  8.0.0.0/7     (8.0.0.0 -> 9.255.255.255)
                omitted 10.0.0.0/8
  11.0.0.0/8
  12.0.0.0/6
  16.0.0.0/4
  32.0.0.0/3
  64.0.0.0/3    (64.0.0.1 - 95.255.255.254)
  96.0.0.0/6    ... you get the idea.

quite annoyance.

So, what we want is to whitelist 0.0.0.0/0 and then blacklist RFC1918 and
100.64.0.0/10, and class D space.  (maybe not class E space)
I have to back to the document to remember if we can actually do plus and
minus, etc.

Maybe there should be a macro for this?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2FCfwACgkQgItw+93Q
3WVEiwf/QL1KQBWqNGs+aIz6O1mn8xxCIhGM1vE5N6bGOaw5DHSJxBRaOEffRrFG
jFxY16Pf2zsVXL7n2KAioPpmiiP84XftAFoisyqLTsP+AC86cs1NqT8DjiIF4dKy
PtfTN5fUBG4O47YvwYdX3qr8W8ZkC522GerjCnFf2I4MSyNObvN0KABUwPYhQLh5
sCpfX6X24ci6psAcu+unfQp9pGaO2Wu841wCxylRhuICrYSJZyY2OdZTuyEzZsNt
U8RH40/ZzFLBELo0SB1UaUXRQD27TrjyFLlublngH6WipHtVr7NzXd665mZGufcT
slybFR+5VI4Ch1oefLQSoFEKbH3Z2A==
=ssGZ
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Sep 23 08:06:23 2019
Return-Path: 
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 5E7E21200B4 for ; Mon, 23 Sep 2019 07:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GnfyphQh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HTQpzh15
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 H6rYBDC1aPKh for ; Mon, 23 Sep 2019 07:41:05 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F3412006D for ; Mon, 23 Sep 2019 07:41:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1569249665; x=1570459265; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=rD25oLAkzsAsQ6lI8g8eTPH0QMWhW9+9s8ijXlIXum8=; b=GnfyphQh1VbhLDesvindfYikhpbs5bYQdybiH0f1m0eI7kPrpb64QwVq oGpF4hCjCzOIvjJu0XfUy7TrJRKoaSW117tOd7CmuMwNtC7cNdP0P47lf 8kuKSE76L0LDCIz/2Z9sHIN00tcNXNuCgsnpIvS65aXPUkNi3nZcR0UsY 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3AJ2V9yx0pOGhkTyc6smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQC0b/JeTpYgQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYJQBq2Ihd/49dJa1lHgEGEoMyUAO?= =?us-ascii?q?BQyAECyoKhBiDRwOKdk2BapgZglIDVAkBAQEMAQEtAgEBhFiCfyM4EwIDAQM?= =?us-ascii?q?CAwEBBAEBAQIBBQRthS0BC4VjEREMAQE4EQEiAiYCBDAVEgQnBweDAIFrAx0?= =?us-ascii?q?BAqFeAoE4iGFzgTKCfQEBBYJIgj0YghcJgQwojAkYgUA/gTgME4pZMoImiTa?= =?us-ascii?q?GJJ02CoIiA5AxhFYbmSWOGpkVAgQCBAUCDgEBBYFpIYFYcBVlAYJBUBAUgU6?= =?us-ascii?q?DcopTc4EpilwBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,540,1559520000"; d="scan'208";a="343265706"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2019 14:41:04 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8NEf4uU019793 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 Sep 2019 14:41:04 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 23 Sep 2019 09:41:04 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 23 Sep 2019 10:41:02 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 23 Sep 2019 09:41:02 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RnXpo2729+2GNyP0pkn+591BHHrsClrWv9mlXMvKaJb4Di+qFCe6IlnI1TfHDggH6rhUi4tEiXu/9njXamm5iJZjWPEkdZh72NQoUllRWz8HIhxlCEB8xFbCAnzspO9XeawD7qx0V4fedDP1MCAcTEnmaVQD7uYvuFtw1ylEMVj+4mVUdMoRHXGt/5UaX91nlqfYEnleekw5/2NE4QYybREY26LFEHfCKDGl2NZBUfDJ3tP9dZ1S/SlcEZN/8uQiRC1f01LsXAQQ4gyJ//WhTLbFRkPcaIqp89oQc8+e3NiAqlRwY5v0uZICWkOdCbfvZClre1iJ1D0mYSHdS/kAgw==
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=rD25oLAkzsAsQ6lI8g8eTPH0QMWhW9+9s8ijXlIXum8=; b=jdtJNxEMRiuA69bhp1rIOBc1yAHaXadBf47dHBmNlIDSgLUGqEpCNjbFSHZdRkVW3GtsmXcHHHSkaawsnz+O4ci9nFr6iwkTYtDfGZerHcQIhBuhwCrkNhr1KS1Jy/d8z8sytCxNMWaXW328o6jKx1MZ9Mkd4CWSVM/DWylNPh/fwajCCLIjVu69kP+BOpqqeAxiWGD53tg74AD9+Z0ikrVrMfPAZ8DMUkiWzA+ft3JoLmPWe7oWka0orsgsPWZN2fb7jL/DHS+XzfADEm4lxxN16VBcdZDUGuRwKj8kjgm+S+WEfUF5Cfr3pZfhZDKsE5+7Ns1EZ3EqIJEvhl9Law==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rD25oLAkzsAsQ6lI8g8eTPH0QMWhW9+9s8ijXlIXum8=; b=HTQpzh15om4yH7GLyVTuJlFmHFDx+kfDGzUR1+Io/yrorSJtfSc/TqD05e6xfj6QKH4kCks3AlY2gGocLZkDZylayW5C/sz75+RCLGD/ml9bngRmnMsxVckKQzpFTS/aNORRgSV3d7wkbQLJ3DZv1Tkg/eBpiUpEEDgcZ+YVCic=
Received: from DM6PR11MB3418.namprd11.prod.outlook.com (20.177.219.223) by DM6PR11MB3210.namprd11.prod.outlook.com (20.176.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.26; Mon, 23 Sep 2019 14:41:01 +0000
Received: from DM6PR11MB3418.namprd11.prod.outlook.com ([fe80::d5b1:26ac:7343:94a5]) by DM6PR11MB3418.namprd11.prod.outlook.com ([fe80::d5b1:26ac:7343:94a5%7]) with mapi id 15.20.2284.023; Mon, 23 Sep 2019 14:41:01 +0000
From: "Joe Clarke (jclarke)" 
To: "mud@ietf.org" 
Thread-Topic: Thoughts on Michael's draft charter
Thread-Index: AQHVchzrBBoeICW6hEygpgIjh2Kl9A==
Date: Mon, 23 Sep 2019 14:41:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jclarke@cisco.com; 
x-originating-ip: [70.231.19.155]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 008a3864-5944-46e0-d503-08d740340e02
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB3210; 
x-ms-traffictypediagnostic: DM6PR11MB3210:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0169092318
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(199004)(189003)(33656002)(6116002)(25786009)(2501003)(316002)(36756003)(8936002)(486006)(6506007)(26005)(1730700003)(81156014)(81166006)(476003)(256004)(102836004)(2616005)(8676002)(6916009)(186003)(2351001)(5640700003)(6436002)(6512007)(6486002)(71200400001)(99286004)(2906002)(4744005)(14454004)(71190400001)(66066001)(66946007)(478600001)(76116006)(91956017)(66476007)(66556008)(66446008)(64756008)(305945005)(86362001)(7736002)(3846002)(5660300002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3210; H:DM6PR11MB3418.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Okm2+21xTm4tlyrAdtgRiKAimS6XJqbklcEGdvkTUdQHqHbBNZ1k5AidxqYoVvTinTIImMpi1JTjGcMdi22+3NibDi78qhlyNHXEMnZ/Bjw9+Muj98ykzbMIXeEM7feVIHdvCSn+e1uA8HyZ8eGaPay1CJCBqxTaZT4qB/vnV/JLrx/fZXLYCUtQ7lp4Mus7Z3hj30AdkBnzKbZTT9vXXhsVOentqqxs/a5Czt4okhgJpS/Di/x9yctzE3c0ArzTcyptgNRlBjxforY6u4omj8JSdPdm7oNOwdVHpykUhHpnvE9cBLvzlzIIqfuyGULsVImKgCVT47oE6s3XJWt5bpLd4XzGkQdDVGrcqnVAy2iwqnlrQxmwBQ2u6uXOp+yutfc6IYXH3uybauvZ+vtcuSvN/6C/2gGhAQx6WZkw05s=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2E335A814A4EC443B31BFB640C8F7891@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 008a3864-5944-46e0-d503-08d740340e02
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2019 14:41:01.2458 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NABXSAPaNPHsYrI/VRz2uHmD5P/Dqs9SVLsEQsYTc/olf77LOLpiU7o3CA9IvW5Ac6KN/E9ZrZ2/DOGGDt+giA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3210
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: 
X-Mailman-Approved-At: Mon, 23 Sep 2019 08:06:22 -0700
Subject: [Mud] Thoughts on Michael's draft charter
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2019 14:41:08 -0000

SSBtZWFudCB0byBzZW5kIHRoaXMgYSB3aGlsZSBhZ28uICBNaWNoYWVsIGFza2VkIG1lIHRvIGNv
bW1lbnQgaGVyZSBhYm91dCBoaXMgZHJhZnQgY2hhcnRlciBmb3IgYSBNVUQgKG9yIGxhcmdlcikg
V0cuDQoNClRoZSBjaGFydGVyIGlzIGRlZmluaXRlbHkgYnJvYWRlciB0aGFuIE1VRC4gIEl0IGNv
dmVycyB0aGUgZ2VuZXJhbCBvbi1ib2FyZGluZyBwcm9ibGVtIHRoYXQgY29tYmluZXMgd29yayBm
cm9tIG11bHRpcGxlIGdyb3Vwcy4gIFRoaXMgbWF5IGJlIHdoYXQgdGhlIGNvbW11bml0eSBhY3R1
YWxseSByZXF1aXJlcyB0byBwcm92aWRlIGEgaG9saXN0aWMgc29sdXRpb24gZm9yIHZlbmRvcnMg
d2hpbGUgbWFraW5nIGl0IGVhc2llciBmb3Igb3BlcmF0b3JzIChhbmQgZW5kIHVzZXJzKSB0byB1
c2UgVGhpbmdzIHNlY3VyZWx5Lg0KDQpBbm90aGVyIHF1ZXN0aW9uIEVsaW90IGhhZCBhc2tlZCB3
YXMgaW50ZXJlc3QgaW4gY28tY2hhaXJpbmcuICBJIGRvbuKAmXQgdGhpbmsgSeKAmWQgYmUgYXMg
Y29tZm9ydGFibGUgYmVpbmcgYSBjby1jaGFpciBvZiB0aGlzIGJyb2FkZXIgZ3JvdXAgdGhhbiBz
b21ldGhpbmcgc2NvcGVkIHNwZWNpZmljYWxseSB0byBNVUQgYW5kIGl0cyBleHRlbnNpb25zLiAg
SeKAmXZlIHdhdGNoZWQgTVVEIGdyb3cgZnJvbSBhIGNlcnRhaW4gcGVyc3BlY3RpdmUsIGFuZCBp
dOKAmXMgY2xlYXIgKGVzcGVjaWFsbHkgZ2l2ZW4gdGhlIHNpZGUgbWVldGluZ3MgYW5kIHRoaXMg
YWxpYXMpIHRoYXQgTVVEIG5lZWRzIG1vcmUgYXR0ZW50aW9uIChhbmQgaGFzIHF1aXRlIHRoZSBm
b2xsb3dpbmcpLiAgSSB3b3VsZCB3b3JyeSB0aGF0IHdoaWxlIGEgZ2VuZXJhbCBvbi1ib2FyZGlu
ZyBncm91cCBtYXkgYmUgcmVxdWlyZWQsIHRoZSB1c2VmdWxuZXNzIGFuZCBlZmZlY3RpdmVuZXNz
IG9mIE1VRCBtYXkgZ2V0IChwYXJkb24gdGhlIHB1bikgbXVkZGxlZC4NCg0KSm9l