Re: [6tisch-security] [Anima] Scope question [was: autonomic bootstrap: gap analysis]
"Michael Behringer (mbehring)" <mbehring@cisco.com> Tue, 17 June 2014 06:59 UTC
Return-Path: <mbehring@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 C7E0D1A0299; Mon, 16 Jun 2014 23:59:05 -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 JIsampmaXL4O; Mon, 16 Jun 2014 23:59:02 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D601A0286; Mon, 16 Jun 2014 23:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6259; q=dns/txt; s=iport; t=1402988342; x=1404197942; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lpx2Qh+KDOEsZq+O9kCh+wXvbLgCKl+OUojMHFbZc3Q=; b=Wj5nU8VpoyNKungDPulc2qIrPH4C1HDmT2o8FGT4YLFMwpI2X8W4ak2Z L+35PvAnS/eLwNLiZoI2a5o5LxIu1cUGYmKvuGil/R6eMgK9EX7VTvmRO zcV0kHDz4GwF3BgySUbeV670vRhyktK8YH3PpyhwhnP06svSae5sV9flC Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AukGAFTmn1OtJV2T/2dsb2JhbABagw1SWql3AQEBAQEBBQGRaYc9AYEOFnWEAwEBAQMBAQEBNy0HCwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIEQKIHwgNyywXhWOIYjEHBoMngRYEnAaSFYNAgjA
X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="53642551"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 17 Jun 2014 06:59:01 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5H6x1bV004389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 06:59:01 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 01:59:01 -0500
From: "Michael Behringer (mbehring)" <mbehring@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] Scope question [was: autonomic bootstrap: gap analysis]
Thread-Index: AQHPibbWdqAxK5GJ0ECGIzHVDHkcBZt03Xfg
Date: Tue, 17 Jun 2014 06:59:00 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com>
References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com>
In-Reply-To: <539F771A.3000008@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.238.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ZCZOum2qNQLHTKhMg9gqMpVb-3U
Cc: 6tisch-security <6tisch-security@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 06:59:06 -0000
> -----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] 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)