Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis]
Balazs Lengyel <balazs.lengyel@ericsson.com> Tue, 17 June 2014 08:17 UTC
Return-Path: <balazs.lengyel@ericsson.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 505D51A030A; Tue, 17 Jun 2014 01:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aA_l88SZxUPa; Tue, 17 Jun 2014 01:17:53 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4551A029F; Tue, 17 Jun 2014 01:17:52 -0700 (PDT)
X-AuditID: c1b4fb3a-f79746d000006fe2-74-539ff9ae3014
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.A5.28642.EA9FF935; Tue, 17 Jun 2014 10:17:50 +0200 (CEST)
Received: from [159.107.197.187] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.174.1; Tue, 17 Jun 2014 10:17:48 +0200
Message-ID: <539FF9AC.5000304@ericsson.com>
Date: Tue, 17 Jun 2014 10:17:48 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima@ietf.org" <anima@ietf.org>
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="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje66n/ODDSbfVLJoXrmI3eLhoutM Fm0X9zFZXJt3kdmBxWPK742sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpMJ/AWzTCvO XepnbmBs0O5i5OSQEDCRODlrLiOELSZx4d56ti5GLg4hgaOMEkv/7IVy1jJK7Jx1Esjh4OAV 0Ja43JUG0sAioCrR/e43WDObgJHE1P7zLCC2qECUxK6+X+wgNq+AoMTJmU9YQOaICPQySrSv u8UGkmAW0JOY8RVis7CAj8TZx5vA4kICnYwS765KgticAr4Sk883s0LU20pcmHOdBcKWl9j+ dg4zRL2GxMMLf1knMArOQrJvFpKWWUhaFjAyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQI DOaDW35b7WA8+NzxEKMAB6MSD+8Cg/nBQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBsbTLK+l/Tkjpjq4DG7xeXjicrNPSznx+9gOZbZ//HFJ0bN1S37TZ 72Fv1JW32TlGnIGxmaeXX3n7v3nmp3++9W8PJupGVW2S+y+d8utdSd3bZpkNjV//HX1aUWt0 MKpOxuP7pMedUgL1B3sXBwUF//NdaHauVSrxiJ6vcM3EPxsnLGH8LMU7S4mlOCPRUIu5qDgR AOupTohHAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/WG5LIHW0Bc6CX1VxbKPAP9UGI8o
Cc: 6tisch-security <6tisch-security@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 08:17:58 -0000
When speaking about bootstraping, does this have much in common with the http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 draft? regards balazs On 2014-06-17 08: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. > > 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 mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
- [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