Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis]
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 17 June 2014 19:52 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896891A00B7; Tue, 17 Jun 2014 12:52:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 b-Xc3WRc3oo8; Tue, 17 Jun 2014 12:52:19 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48BE1A0163; Tue, 17 Jun 2014 12:52:18 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id bj1so4230134pad.23 for <multiple recipients>; Tue, 17 Jun 2014 12:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OkLFEFPr64z3Kz8FHY/gBmGv7o1D/2m6FrbtKA2b3No=; b=U6CNw/OaaHovA3G6b2WaI71YOfvafC0vX/NFYKD0bPEdmm99iEGT3oKT0X77pv+y2X jvMav0nKykegY7JOT2inkEapa4npbFKpjFcF5tkqUUiFlIHyDYGKedwOl1/uqDHZX59T /jQfNZ09F6YVFTn7YZpS4uM1CZHRSf97Tc5x5fYdakHW64owBm3JoVVVQSi8fD0cfuo4 sTPn/L8iLqpC6nKUZauZxzat6w55YGKIzjyYP5onFM8v2GGPizGo/AMLWIrK05AON6Xq /beHnErGIAW6++3Xu8mSQAxU5u8gPNJPxtcH/LxSt9JpdgGU3bbFQEqc9zF0V8NsghW6 tgyw==
X-Received: by 10.68.189.68 with SMTP id gg4mr35275232pbc.42.1403034738600; Tue, 17 Jun 2014 12:52:18 -0700 (PDT)
Received: from [192.168.178.23] (171.198.69.111.dynamic.snap.net.nz. [111.69.198.171]) by mx.google.com with ESMTPSA id ao4sm25349736pbc.51.2014.06.17.12.52.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 12:52:18 -0700 (PDT)
Message-ID: <53A09C73.2060309@gmail.com>
Date: Wed, 18 Jun 2014 07:52:19 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Michael Behringer (mbehring)" <mbehring@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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Yoj8_VidrOpQCVb_en7UsoiaBxw
Cc: 6tisch-security <6tisch-security@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis]
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 19:52:21 -0000
On 17/06/2014 18:59, Michael Behringer (mbehring) wrote: >> -----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. Fully agree. But when I see people asking whether we will use YANG, I find myself wondering about low-end devices in an IoT context. Brian > 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 > . >
- [Anima] autonomic bootstrap: gap analysis Michael Richardson
- [Anima] Scope question [was: autonomic bootstrap:… Brian E Carpenter
- Re: [Anima] Scope question [was: autonomic bootst… Sheng Jiang
- Re: [Anima] Scope question [was: autonomic bootst… Michael Behringer (mbehring)
- Re: [Anima] [6tisch-security] Scope question [was… Pascal Thubert (pthubert)
- Re: [Anima] Scope question [was: autonomic bootst… Laurent Ciavaglia
- Re: [Anima] Scope question [was: autonomic bootst… Balazs Lengyel
- Re: [Anima] Scope question [was: autonomic bootst… Michael Behringer (mbehring)
- Re: [Anima] Scope question [was: autonomic bootst… Brian E Carpenter
- Re: [Anima] autonomic bootstrap: gap analysis Behcet Sarikaya
- Re: [Anima] autonomic bootstrap: gap analysis Michael Behringer (mbehring)
- Re: [Anima] Scope question [was: autonomic bootst… Pascal Thubert (pthubert)
- Re: [Anima] Scope question [was: autonomic bootst… Brian E Carpenter