[smartpowerdir] A view on Zigbee Security Energy Profile 1.x

Fred Baker <fredbakersba@gmail.com> Tue, 29 March 2011 12:41 UTC

Return-Path: <fredbakersba@gmail.com>
X-Original-To: smartpowerdir@core3.amsl.com
Delivered-To: smartpowerdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id B82D23A67DB; Tue, 29 Mar 2011 05:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id rVx0LNAYZnZT; Tue, 29 Mar 2011 05:41:54 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id B6BF23A63CA; Tue, 29 Mar 2011 05:41:53 -0700 (PDT)
Received: by wyb29 with SMTP id 29so118948wyb.31 for <multiple recipients>; Tue, 29 Mar 2011 05:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=6Sq8xKT/z2FA1FRAh5r2LePxz/HA9GDKfUsrbfYGTqo=; b=T2vQMZ7gVFp7CKFLnSjZr4u3aRT7w8Wv5Oz1H9NDDWZ1x8vd7pElgFffFZoCYn0IOq BNaYMLyPTxRqxLnE4w1DvZr131FGXeKcHFs+14kH0sVccY7IUntZj/fwRtmEpbNW0pVq APyy05FtMADPtLcKSfk5Z7sTpmLnpKvgyNSqc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=KWVbvd3aua7wUMcW38kd5rPIL8/IjdckYGLvKOuGjeQdJW51BslCpnMKnywpte1y9C nyTuaIidNSwM99oz2rfPA6cdb13km0QORn9OUTtvf5Mmk1R78ALzzdNi6KEkL78mQct8 hltAuynl3DwuqxNRK/+nv0rLhPVaoXI9TfAxc=
Received: by with SMTP id g56mr4990510wej.5.1301402611004; Tue, 29 Mar 2011 05:43:31 -0700 (PDT)
Received: from [] (64-103-25-233.cisco.com []) by mx.google.com with ESMTPS id r80sm1912624wei.15.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 05:43:29 -0700 (PDT)
From: Fred Baker <fredbakersba@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Mar 2011 14:43:19 +0200
Message-Id: <D808FCD7-BA58-491B-9954-B59557919492@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Thu, 07 Apr 2011 00:54:31 -0700
Cc: chair@ietf.org, chair@iab.org, IETF SmartPower Directorate <smartpowerdir@ietf.org>
Subject: [smartpowerdir] A view on Zigbee Security Energy Profile 1.x
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2011 12:41:55 -0000

I want to be very careful in identifying myself in sending this; I have not vetted this statement with anyone, so I can't say "this is the IETF's viewpoint". That said, I speak from an IETF perspective, and would be very surprised if anyone in the IETF significantly disagreed. I am the chairman of the IETF's Smart Power Directorate, and the IETF's liaison to the SGIP. http://en.wikipedia.org/wiki/Fred_Baker_(IETF_chair)

The IETF has spent the past 25 years building protocols that numerous operators have used to build a global network that interoperates very effectively. The result has been a significant benefit to business and to national GDP, and has spawned numerous businesses that can add interesting capabilities to a world-wide market. The principles on which the Internet Architecture and its protocols are based include openness of specification, interoperable implementation among multiple vendors, support of competitive business, and an absence of market capture.

To give an idea of how we implement that, let me mention the development of OSPF, a routing protocol commonly used in the Internet. We had leadership from a small group of developers, but a relatively large community that interacted with them to ensure that it met their needs. It considered the needs of government networks, service provider networks, and networks on the Internet edge. The documentation that was presented before it was approved included a publicly readable protocol specification (RFC 1247, which has since been updated), an analysis of its capabilities (RFC 1245), a publicly documented interoperability test that included 23 independent implementations of the complete protocol (RFC 1246), and the capabilities required to manage the protocol (RFC 1253). It is an example of what we consider a well documented open specification.

In addition, while we specified mutual cryptographic authentication between neighboring routers, we didn't specify the company from which certificates had to be obtained, or the type of cryptography involved. There were two reasons: we wanted to avoid market capture by a single organization, with the abuses attendant in such a thing, and we wanted to provide for technological change, which is one of the few constants in the Internet. Security is specified in terms of what is done, not in terms of whose technology is used. Should an issue arise, such as has happened in Stuxnet, it is possible to update operationally without changing the specifics of the protocol.

In reviewing any protocol or protocol suite, the IETF would similarly look at how it is specified, its scalability (for which reason we strongly recommend the use of IP generally, and more specifically IPv6), the publicly available documentation of its testing, security issues, and the business impacts. The IETF would generally recommend that the protocol suite used in the Smart Grid similarly promote an openly specified, widely and interoperable implemented, secure, and scalable network that is designed for business and technological growth and adaptation in time.

From what is publicly known about SEP 1.x, I don't believe that it meets these concerns.

Fred Baker

1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT=26160,
     PS=33546, PDF=31723 bytes) (Also RFC1247, RFC1246) (Status:

1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format:
     TXT=70441, PS=141924, PDF=84633 bytes) (Also RFC1247, RFC1245)
     (Status: INFORMATIONAL)

1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT=433332,
     PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by
     RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status: DRAFT

1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun.
     August 1991. (Format: TXT=74453 bytes) (Obsoletes RFC1252) (Obsoleted
     by RFC1850) (Also RFC1247, RFC1245, RFC1246) (Status: PROPOSED