Re: [6tisch-security] [Anima] Scope question [was: autonomic bootstrap: gap analysis]
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 17 June 2014 07:21 UTC
Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0EA1A02BC; Tue, 17 Jun 2014 00:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 A6QCEBsgBmtx; Tue, 17 Jun 2014 00:21:06 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DAE1A02BF; Tue, 17 Jun 2014 00:21:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7311; q=dns/txt; s=iport; t=1402989666; x=1404199266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NDRPzcfQ7RQq8/EVAw3NODrk/VsfoqYGb7QendTFadU=; b=iTpYHrD1RB9Un0fsIxR5W80FSJvuJC6o0R6uQg6d4ARsSI86/htqVK5m KMs5OC8W1aF37GutRaozv9RBIRXOHg6HRRi57M6KZXEFk+8gJy7cOs8YH ESZ/SD4kMQw2orTUh1A//B60aM5rVAatWm3Pa1D4MDNrEbr/Ute71GfuH k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AloGAO/rn1OtJV2Q/2dsb2JhbABagw1STaoEAQEBAQEHkWmGbFEBgQ4WdYQDAQEBBAEBAWQHCwwEAgEIEQQBAQEnBycLFAkIAgQOBRkCiCcNyzIXhWOFdAGCazMHBoMngRYEigWQPoFDkhWBfoFC
X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="53643757"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 17 Jun 2014 07:21:05 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5H7L4So014818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 07:21:04 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.126]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 02:21:04 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>
Thread-Topic: [6tisch-security] [Anima] Scope question [was: autonomic bootstrap: gap analysis]
Thread-Index: AQHPibbWdqAxK5GJ0ECGIzHVDHkcBZt03XfggAAIgAY=
Date: Tue, 17 Jun 2014 07:21:03 +0000
Message-ID: <C49BA7DC-96AC-4B63-81D7-9009664F432D@cisco.com>
References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com>, <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/pQxxPsqKgyhcaZl4LdIuRikpcT4
Cc: 6tisch-security <6tisch-security@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [6tisch-security] [Anima] Scope question [was: autonomic bootstrap: gap analysis]
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 07:21:08 -0000
I agree with Michael, As IT and more specifically IEEE/IETF technology is getting pervasive, we need to simplify commissioning and deployment in a fundamental manner. There are no CCIEs in an oil field or a deep mine in Alaska and still growing amounts of IP and Ethernet devices get deployed in all sorts of places, homes, curbs, factory floors, you name it, with a renewed interest in wireless monitoring. 6TiSCH targets at some of those environments and it clearly requires AN for use cases with huge scalability or ease-of-deployment constraints. And certainly, the lack of CCIEs is more pervasive than just the WSN/6TiSCH... Pascal Le 17 juin 2014 à 08:59, "Michael Behringer (mbehring)" <mbehring@cisco.com> a écrit : >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 17 June 2014 01:01 >> To: anima@ietf.org >> Cc: 6tisch-security >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] >> >> Michael's message is very interesting. For present purposes, i.e. getting >> ready for the UCAN BOF, do we need to add some points to the relevant use >> case draft (http://tools.ietf.org/html/draft-behringer-autonomic- >> bootstrap)? >> >> More generally - I think the AN protagonists have been thinking of the >> scope of AN being carrier, enterprise, and home networks. >> Should we add IoT to the scope? I think it's an important question, because >> it would put new meanings on "simple" and "available resources". It seems >> obvious that IoT networks need to be completely autonomic, but is it the >> *same* autonomic? > > Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. > > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. > > To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. > > So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. > > Michael > > >> Regards >> Brian >> >>> On 17/06/2014 08:13, Michael Richardson wrote: >>> I recognize that bootstrap is only one of the autonomic mechanisms >>> that are relevant to this group. I have much reading on the other >>> aspects which I hope to get done. >>> >>> The 6tisch security design team has been working on a "zero-touch" >>> mechanism that would permit constrained devices to join a >> Lowpower/Loss Network (LLN) >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has >>> done), or turning the WirelessHART (IEC62591) packet flow into >>> something more IPv6-like. While there are significant bits of design >>> space to explore while trying to optimize packet count, size and total >>> energy risk of the join protocol; the idea that there should be a set >>> of authorization tokens From the device vendor which would permit the >>> network and new nodes to recognize each other has been central to all >> discussions. >>> >>> while draft-pritikin-bootstrapping-keyinfrastructures and >>> draft-behringer-autonomic-bootstrap-00 >>> >>> have proposed valid high level concepts, I believe that specification >>> of the authz token is critical for the IoT space. A great concern >>> that is that the LLNs created remain operational for decades at a >>> time, and that the components can individually and also in aggregate >>> be both (re-)sold, and/or the service provider operating the network be >> replaced. >>> >>> (There are real life examples where a part of a 100 square mile >>> refinery is actually sold to a competitor; obviously it doesn't get >>> moved. On the other side, one has the very real risk that you bought >>> your sensor network From a "Nortel") >>> >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is >>> about an API between a (constrained) device and it's cryptographic >> hardware >>> module/TPM. It profiles a number of IETF PKIX specifications in a useful >>> way, but there is little there in terms of actual protocol. When it >>> comes to what does an *DevID look like, in it's section 7.2.8, saying >>> that the DN should contain a "serialNumber" attribute: >>> >>> The formatting of this field shall contain a unique X.500 >>> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer >>> or any other suitable unique DN value that the issuer prefers. >>> >>> What I have observed is that there needs to be a way to clearly >>> delegate from >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to >>> SERVICE-PROVIDER. It would significantly reduce the number of >> certificates >>> in (non-constrained device) databases for some levels of this >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 >>> came to mind, which deals with delegation of Autonomous Systems >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and >> Enterprises. >>> RFC3779: X.509 Extensions for IP Addresses and AS >>> Identifiers >>> >>> I created: >>> X509.v3 certificate extension for authorization of device ownership >>> draft-richardson-6tisch-idevid-cert-00 >>> >>> which cribbed together via nroff2xml and a search and replace. >>> >>> The Pritikin and Behringer documents seem to assume that the ultimate >>> goal of the trusted enrollment process is to create a path in which >>> "EST"= Enrollment over Secure Transport could operate that would >>> permit a new locally significant certificate to be loaded into the new >> device. >>> I agree with that goal. >>> >>> There is the question of how that trust circuit is created, and in >>> discussion it seemed that it involve some kind of leap-of-faith TLS >>> setup which would be authenticated by the "authz" tokens later on. I >>> disagree; I think that with appropriate evaluation of path constraints >>> that the authentication can occur within the TLS protocol. (Even >>> easier if done in IKEv2) >>> >>> -- >>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software >> Works >>> -= IPv6 IoT consulting =- >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security
- [6tisch-security] autonomic bootstrap: gap analys… Michael Richardson
- [6tisch-security] Scope question [was: autonomic … Brian E Carpenter
- Re: [6tisch-security] [Anima] Scope question [was… Michael Behringer (mbehring)
- Re: [6tisch-security] [Anima] Scope question [was… Pascal Thubert (pthubert)
- Re: [6tisch-security] [Anima] Scope question [was… Michael Behringer (mbehring)
- Re: [6tisch-security] [Anima] Scope question [was… Balazs Lengyel
- Re: [6tisch-security] [Anima] Scope question [was… Sheng Jiang
- Re: [6tisch-security] [Anima] Scope question [was… Laurent Ciavaglia
- Re: [6tisch-security] [Anima] Scope question [was… Brian E Carpenter
- Re: [6tisch-security] [Anima] autonomic bootstrap… Behcet Sarikaya
- Re: [6tisch-security] [Anima] autonomic bootstrap… Michael Behringer (mbehring)